Курсовая? Точно? Я помню как устроился на работу, где 3 человека аж одну дипломную работу делали, так там качество работы даже на курсовую одного с натяжкой тянуло. А здесь всё же поболее курсовой будет.
Не во время печати, а после. PLA начинает деформироваться при 60 градусах. ABS при такой температуре начнет давать непередоваемый аромат сладости на языке от стирола.
Вот реально, чего глючного в Unity? UE опробуйте, движок прям впечатляет, чуть ли не любая ошибка в C++ приводит к крэшу редактора UE, да, очень удобно, очень безглючно. А учитывая «качество» документации UE, эти ошибки будут прям на регулярной основе. А если взять blueprint, да, тут с ошибками лучше, но когда оно не умеет работать по ссылкам, нет, увольтес, что-то адекватное сделать уже куда сложнее чем на том же Unity. А если брать бесплатные, опенсорсные, то ситуация с глючностью ещё лучше, они такие безглючные, что некоторые тупо падают вообще без внешних разражителей.
300й есть, пользовался им по началу, а учитывая, что надо в общем-то только дома. Ушёл на флешки. А так 300й шикарный девайс с одним гигантским недостатком, не запоминает выбранный образ, не всегда возможно резко поменять образ, чтобы накатить ось.
Ответ в общем дан. При этом компилятор может поглядеть, что функция используется 1 раз и встроить её независимо от размера. Опять же компилятор может вообще всегда встраивать функции с малым размером, с одним выражением и т.д., это зависит ещё от указанного уровня оптимизации. В C++ при работе с шаблонной магией, когда прям вот compile-time не получится использовать, где-нить к примеру на последнем этапе или работа с runtime инфой, то компилятор без указания inlne почти всегда функции встраивал. В общем да, inline не показатель сейчас, вообще. А так же в догонку, компилятор может и циклы развернуть и рекурсию в цикл превратить и т.д. И ничего для этого говорить ему не надо.
Не можете — так и не берите. Есть вещи даже проще голого реакта, что уж говорить про попытке собрать стейт-менеджер из всего, что только под руку попало.
Ээээ, тут только одна State-magament либа и это Redux. А всё остальное, это лишь необходимость для исправления архитектурных проблем этого самого Redux. Ну и контексты реакта, спасибо, не надо, для калькулятора хватит, а вот посерьёзнее проект не переживёт, особенно если хочется к примеру Redu/Undo добавить.
Вы не удосужились ознакомиться с дорожной картой реализации WA.
Я в курсе что такое WA и как оно работает. И WA так или иначе родная для браузеров технология, тут уже какое-то словоблудие начинается.
Использование WA в других контекстах — связано с солидным объемом проблем. В первую очередь с большими блобами, которые к тому же не дают никакого преимущества по скорости работы страницы.
Как бы часто неподконтрольные перерисовки, а и часто ненужные перерисовки со стороны React как бы не даёт никакого преимущества по скорости работы.
Ну и хватит кормить тролля. Уже все ваши доводы скатились до уровня Страуструпа, когда он был против тех или иных пропосалов в новые стандарты C++. «А это ведь можно вот так сделать» и выдаёт раз в 5-10 больше кода. Да, можно, но зачем? Если можно сделать проще, если можно не заботиться о проблемах, если уже есть готовые решения. Зачем страдать? Но вот все ваши доводы уже скатились до уровня: Можно ведь и пострадать. Развитие ЯП сводится не к удовлетворению вашего эго, а к снижению трудозатрат. И blazor это может дать. А если уж у разработчиков не хватит ума-разума, чтобы это понять, это не вина платформы, увы.
И вы, конечно, почему-то считаете это чем-то плохим. Непонятно только, почему.
Циклические зависимости, такой беды как это в JS, C, C++ и т.д. тут нет, если в C и C++ это можно решить, то в JS это даже решить адекватно нельзя, ну никак. Вторым пунктом тут идёт снижение объёмов бойлерплейт кода.
В TS не хуже. Я бы вообще сказал, что «лучше», но это вкусовщина, поэтому не буду.
Я бы сказал, что хуже. В TS стогая типизация, но если хочется, то будет не строгая. В C# так сделать нельзя, да, там есть тип dynamic, но он не лежит в основе языка, при этом же код даже под dynamic идёт довольно строг. Опять же к системе типов, в JS в общем примерно как и в Java value-type идут только для примитивных типов и никак иначе, в C# этим можно управлять.
Когда вы сами себе злобный буратина, и не имеете тестов, но зато имеете отличную привычку обновлять версии ваших зависимостей просто потому, что вам так захотелось?
Тесты, окей. В JS и даже TS нет адекватной реализации DI и IoC, если в TS хоть какой-то костыль есть, то тут всё плохо, а в содружестве с отсутствием модулей, приходится мокать не просто передаваемые объекты внутрь кода, а приходится мокать импорты, приходится мокать хуки и т.д., что по факту убивает идею юнит-тестов и тестирования чёрного ящика, ибо надо знать внутреннюю реализацию тестируемого кода.
А обновление зависимостей временами требуется как бы, новый функционал, фиксы багов, которых обычно ой как не мало. И что уж делать, если я на пршлой неделе сделал новый проект используя create-react-app и получил десятки ворнингов несоответствия версий. В C# за весь мой опыт такого отстойного отношения к коду я ещё не видел.
Вы еще давайте расскажите, как в C# нельзя выстрелить себе в ногу, чтоб мы тут дружно почитали и посмеялись.
Не отрицаю, в C# есть ад зависимостей, но не настолько гигантский как в JS, в .net core при этом ад стал ещё меньше.
Если вы не умеете создавать сорсмапы — честное слово, это не проблема сорсмапов. Это настолько не rocket science, что утверждать, что там всё плохо — это ну очень грустно.
Ага, не хочешь по 5-10 минут собирать проект, делаешь послабше сорсмапы, ах да, тут дебаггер не может трейсить код, переключаешься опять на дотошные сорсмапы, ах да, тут понадобилось подрубить css, ой, все стильники в index.js, идёшь, опять меняешь сорсмап и т.д. Это типа всё окей?
Да нет, не «как». Большинство новых фич языка полифиллится, то есть, таки в итоге работает в старых браузерах. С web assembly всё просто: нет браузерной поддержки? Идите лесом, точка.
Web Assembly — этот как бы что-то похожее на ассемблер. Я не говорил про поддержку DOM, новых стандартов CSS, я тупо говорил про какие-нить функции для работы с данными. startsWith, includes и т.д.
Да, пропустил и не заметил. Хвалиться «внедрением зависимостей» — это что-то из серии «а в нашем крутом инструменте можно сделать цикл со счётчиком!». DI тривиально делается в любом приличном языке (и нетривиально, но всё равно делается — в любом тьюринг-полном).
Ну давайте покажите пример тестов вашего кода. И мы уже оценим, реально ли это в рамках JS или не особо. Особенно в условиях, когда JS сейчас тупой и процедурный и даже его крайне костыльные объектная-ориентированность не используется кучей разработчиков, чего стоят хуки реакта. Я уж лучше сделаю сервис, который мне будет IoC контейнер подсовывать сам и я не буду париться, а в тестах я сделаю простой мок. А не буду париться с попытками мокнуть импорт в Jest с кучей проблем.
Вот давайте предметно: что такого вы архитектурно можете реализовать на C#, и не можете на JS?
Ну давайте. React+Redux+Deox+Saga и это только самый базовый набор библиотек. Все подразумевают работу в своём уникальном стиле, у всех сайд эффекты поддерживаются по своему, этим пользоваться можно, но искать код, который нужен в большом проекте задачка уже становится совсем нетривиальной. Приходится использовать кучу разных механизмов, вместо одного.
Нет, я не фанат JS. Я просто на нем (да и даже не на нем, а на TS) пишу, и поэтому к высасываемым из пальца аргументам «за Blazor» отношусь очень пренебрежительно. Потому что реальный аргумент тут ровно один: «вы можете сбацать SPA, не вылезая из уютного C#».
Ну тут видны консервативные взгляды, тут ключевой момент не C#, а Web Assembly, родная технология для браузеров и вам грустно становится от того, что теперь на C#, который скомпилится в Web Assembly, можно писать родной код для браузеров. И вам обидно, прям как фанатам PS, когда их эксклюзивы уходят на ПК.
1400 баксов за видяху? (А у нас так вообще 1800). Это из-за дешёвого рубля? Все консоли нового поколения можно будет купить и ещё останется на игры. А графика как обычно в 3х играх может и будет как-то требовать данную видяху, остальные же как обычно будут ориентироваться на консоли. У 3090 TDP — 350, я не знаю когда и в каких условиях это измерено. У меня к примеру i9 9900K, у него по бумажке аж 95TDP (и дописка, без учёта AVX), а с AVX что используется повально всеми играми за 200 с лишним взлетает. Да и видимо ради 350Вт решили сделать новый аж 12 пиновый разьём питания, да, я охотно верю.
«Приятно удивил», это сарказм у вас такой? Цена просто космос, за цену видяхи можно обмазаться консолями нового поколения. А этой видяхе нужен плюсом ещё топовой проц. тут же надо ещё идти в соседний автосервис и сваривать кожух из арматуры, эта видяха просто изогнётся сама и изогнёт мать, что в общем-то без проблем приведёт к выходу из строя. Ну и плюсом надо отрубать центральное отопление, иначе дома будет пекло.
Только вот уровень языков очень разный. Даже TypeScript не сможет соревноваться с платформой .NET. В данном случае C# из коробки работает полноценно с модулями, и не требуется уписываться import'ами, чуть более что-то серьёзное и десятки и более строк импортов с кучей функций и компонентов. Опять же шикарная строгая типизация. Да и колосальный фреймворк, а не тот ад, что творится в JS, тысячи библиотек в зависимостях. Одну обновили и добавили баг и потом можно неделями искать эту проблему.
При разработке на JS можно выполнять полноценную отладку JS. Опять же, чудо чудное, да?
Как? Имея кучу гемороя с сорсмапами, когда одни работают в одних условиях, другие в других, при этом скорость компиляции знатно начинает страдать.
Ну да, работает везде, кроме тех браузеров, где не работает ;-)
В общем как и JS. Внедрение новых возможностей до сих пор хромает, приходится использовать постоянно колосальное кол-во полифилов, чтобы работало в старых бразуерах, эх, мечта, иметь новые возможности, а пользоваться только старыми.
Ну прям как c Node.js несколько лет назад, ага.
Вот не стоит путать возможности и инфраструктуру Node.js с .NET, тут опять же не требуется этот колосальный ад из тысяч бибилиотек, чтобы всё работало.
А чего так просто забыли процитировать внедрение зависимостей? Или просто сказать нечего? В том же Angular увы это костыль, а ни как не полноценное внедрение зависимостей. И это то, чего мне не хватает в JS, очень сложно построить внятную архитектуру приложения на JS. Вплоть до того, что не так давно сделал некую альтернативу для нашего проекта, да, стало проще, но всё не получается реализовать все возможности в рамках JS.
Я конечно понимаю, вы фанат JS, но не стоит плевать со своей колокольни, если на другой никогда не были.
Я работал и с .NET и с JS и могу сказать одно, я терпеть не могу JS из-за его низкого порога вхождения, это приводит к появлению кучи низкокачественного кода, им завалено всё, ад из мелких библиотек. Если смотреть на фреймворки типа Angular, даже они крайне слабы в сравнении с платформой .NET, да, я не буду отрицать, что Blazor в начале пути и пока что он не подойдёт для полноценных проектов, но потенциала у него куда больше чем у JS.
Управление со смарта, это то ещё извращение. Держать 2 коробки рядом, чтобы вывести на экран, тоже шик. По цене малинки и переходника можно было взять готовый девайс на али и не париться так. В общем троллейбус из хлеба.
Это не просто кусок кода, это сатира на современных JS разработчиков. Увы, чего только не увидишь ныне. И с учётом снижения порога входа и увеличением популярности станет только хуже.
Не во время печати, а после. PLA начинает деформироваться при 60 градусах. ABS при такой температуре начнет давать непередоваемый аромат сладости на языке от стирола.
Ээээ, тут только одна State-magament либа и это Redux. А всё остальное, это лишь необходимость для исправления архитектурных проблем этого самого Redux. Ну и контексты реакта, спасибо, не надо, для калькулятора хватит, а вот посерьёзнее проект не переживёт, особенно если хочется к примеру Redu/Undo добавить.
Я в курсе что такое WA и как оно работает. И WA так или иначе родная для браузеров технология, тут уже какое-то словоблудие начинается.
Как бы часто неподконтрольные перерисовки, а и часто ненужные перерисовки со стороны React как бы не даёт никакого преимущества по скорости работы.
Ну и хватит кормить тролля. Уже все ваши доводы скатились до уровня Страуструпа, когда он был против тех или иных пропосалов в новые стандарты C++. «А это ведь можно вот так сделать» и выдаёт раз в 5-10 больше кода. Да, можно, но зачем? Если можно сделать проще, если можно не заботиться о проблемах, если уже есть готовые решения. Зачем страдать? Но вот все ваши доводы уже скатились до уровня: Можно ведь и пострадать. Развитие ЯП сводится не к удовлетворению вашего эго, а к снижению трудозатрат. И blazor это может дать. А если уж у разработчиков не хватит ума-разума, чтобы это понять, это не вина платформы, увы.
Циклические зависимости, такой беды как это в JS, C, C++ и т.д. тут нет, если в C и C++ это можно решить, то в JS это даже решить адекватно нельзя, ну никак. Вторым пунктом тут идёт снижение объёмов бойлерплейт кода.
Я бы сказал, что хуже. В TS стогая типизация, но если хочется, то будет не строгая. В C# так сделать нельзя, да, там есть тип dynamic, но он не лежит в основе языка, при этом же код даже под dynamic идёт довольно строг. Опять же к системе типов, в JS в общем примерно как и в Java value-type идут только для примитивных типов и никак иначе, в C# этим можно управлять.
Тесты, окей. В JS и даже TS нет адекватной реализации DI и IoC, если в TS хоть какой-то костыль есть, то тут всё плохо, а в содружестве с отсутствием модулей, приходится мокать не просто передаваемые объекты внутрь кода, а приходится мокать импорты, приходится мокать хуки и т.д., что по факту убивает идею юнит-тестов и тестирования чёрного ящика, ибо надо знать внутреннюю реализацию тестируемого кода.
А обновление зависимостей временами требуется как бы, новый функционал, фиксы багов, которых обычно ой как не мало. И что уж делать, если я на пршлой неделе сделал новый проект используя create-react-app и получил десятки ворнингов несоответствия версий. В C# за весь мой опыт такого отстойного отношения к коду я ещё не видел.
Не отрицаю, в C# есть ад зависимостей, но не настолько гигантский как в JS, в .net core при этом ад стал ещё меньше.
Ага, не хочешь по 5-10 минут собирать проект, делаешь послабше сорсмапы, ах да, тут дебаггер не может трейсить код, переключаешься опять на дотошные сорсмапы, ах да, тут понадобилось подрубить css, ой, все стильники в index.js, идёшь, опять меняешь сорсмап и т.д. Это типа всё окей?
Web Assembly — этот как бы что-то похожее на ассемблер. Я не говорил про поддержку DOM, новых стандартов CSS, я тупо говорил про какие-нить функции для работы с данными. startsWith, includes и т.д.
Ну давайте покажите пример тестов вашего кода. И мы уже оценим, реально ли это в рамках JS или не особо. Особенно в условиях, когда JS сейчас тупой и процедурный и даже его крайне костыльные объектная-ориентированность не используется кучей разработчиков, чего стоят хуки реакта. Я уж лучше сделаю сервис, который мне будет IoC контейнер подсовывать сам и я не буду париться, а в тестах я сделаю простой мок. А не буду париться с попытками мокнуть импорт в Jest с кучей проблем.
Ну давайте. React+Redux+Deox+Saga и это только самый базовый набор библиотек. Все подразумевают работу в своём уникальном стиле, у всех сайд эффекты поддерживаются по своему, этим пользоваться можно, но искать код, который нужен в большом проекте задачка уже становится совсем нетривиальной. Приходится использовать кучу разных механизмов, вместо одного.
Ну тут видны консервативные взгляды, тут ключевой момент не C#, а Web Assembly, родная технология для браузеров и вам грустно становится от того, что теперь на C#, который скомпилится в Web Assembly, можно писать родной код для браузеров. И вам обидно, прям как фанатам PS, когда их эксклюзивы уходят на ПК.
Только вот уровень языков очень разный. Даже TypeScript не сможет соревноваться с платформой .NET. В данном случае C# из коробки работает полноценно с модулями, и не требуется уписываться import'ами, чуть более что-то серьёзное и десятки и более строк импортов с кучей функций и компонентов. Опять же шикарная строгая типизация. Да и колосальный фреймворк, а не тот ад, что творится в JS, тысячи библиотек в зависимостях. Одну обновили и добавили баг и потом можно неделями искать эту проблему.
Как? Имея кучу гемороя с сорсмапами, когда одни работают в одних условиях, другие в других, при этом скорость компиляции знатно начинает страдать.
В общем как и JS. Внедрение новых возможностей до сих пор хромает, приходится использовать постоянно колосальное кол-во полифилов, чтобы работало в старых бразуерах, эх, мечта, иметь новые возможности, а пользоваться только старыми.
Вот не стоит путать возможности и инфраструктуру Node.js с .NET, тут опять же не требуется этот колосальный ад из тысяч бибилиотек, чтобы всё работало.
А чего так просто забыли процитировать внедрение зависимостей? Или просто сказать нечего? В том же Angular увы это костыль, а ни как не полноценное внедрение зависимостей. И это то, чего мне не хватает в JS, очень сложно построить внятную архитектуру приложения на JS. Вплоть до того, что не так давно сделал некую альтернативу для нашего проекта, да, стало проще, но всё не получается реализовать все возможности в рамках JS.
Я конечно понимаю, вы фанат JS, но не стоит плевать со своей колокольни, если на другой никогда не были.
Я работал и с .NET и с JS и могу сказать одно, я терпеть не могу JS из-за его низкого порога вхождения, это приводит к появлению кучи низкокачественного кода, им завалено всё, ад из мелких библиотек. Если смотреть на фреймворки типа Angular, даже они крайне слабы в сравнении с платформой .NET, да, я не буду отрицать, что Blazor в начале пути и пока что он не подойдёт для полноценных проектов, но потенциала у него куда больше чем у JS.