Поправка: это конечно не к динамической типизации относится, это плюс языков с гарбадж-коллектором. Но в контексте противопоставления C++ / «другие языки» не принципиально, да и плюсы динамической типизации сводятся в основном к тому же самому «писать меньше кода».
Если приложение не сильно затратное по ресурсам в целом, то абсолютно нормальный подход. Где требуется производительность/экономия памяти, там плюсы рулят, так с этим я как раз и не спорю.
А по поводу памяти: если сохранять инкапсуляцию и придерживаться правила «написал код выделения памяти — сразу же напиши код для ее освобождения»
То есть надо писать больше кода, так? Вот это и есть пример превосходства динамической типизации над статической. Меньше писать, меньше потом поддерживать.
Собственно, это примерно как сказать: «на Ruby я разрабатываю более производительные приложения, чем на C++». Так не бывает. Ну то есть бывает, но понятно в каком случае.
А минусующим умникам и обличителям студентоты хочу сказать, что C++ прекрасно знаю (слово «прекрасно» следует читать так, как оно написано, реально очень много в своё время на нём писал и знаю очень хорошо, собственно это был первый язык, с которого я начал свою профессиональную деятельность), но вот сейчас мне в голову не придёт что-то на нём писать без серьёзной необходимости. Основной плюс — да, производительность (про стабильность поспорил бы). Минус — разработка занимает значительно больше времени, чем на языках с динамической типизацией. Ну только для этого надо хорошо выучить один из последних, вместо того чтобы ругаться, что кто-то там C++ не осилил.
Ну так понятно, что сварганить цель сборки можно при желании подо что угодно, вопрос-то в основном в том, насколько хорошо работают уже готовые. Поскольку ну мало кому придёт в голову дополнительно к разработке приложения ещё и разрабатывать/допиливать цель для Qt, что с учётом всех тонкостей платформы может занять больше времени, чем написать нативное приложение.
Нет, я понимаю, проектов-то много может быть. Я тогда тоже «портировал», но вот в этом слове немного и загвоздка. «Кроссплатформенность» предполагает, что портирование должно вообще-то сводиться к перекомпилированию.
А что, правда всё так радостно с кроссплатформенностью нынче? Я последний раз на Qt кодил во времена версий 4.что-то-там, и слово «кроссплатформенность» было тогда такой шуткой для своих. Но вообще Qt мне всегда нравился несмотря на. Кто последнее время собирал на нём что-то серьёзное под несколько платформ, не поделитесь, какая сейчас ситуация?
Не знаю как у вас, а у меня в intelliJ любая строка интеллектуально(с учетом окружения) комментируется по ctrl+/
Не знаю, как там комментирует IntelliJ, но скажем у вас три приведённых переменных, вам надо закомментировать вторую. А потом раскомментировать. Мы получим в итоге 3 исходных строки? Честно сказать, не верю, с комментированием всё более-менее понятно, а в момент раскомментирования будет неоднозначность, это неформализуемая процедура в общем случае.
И потом, получается стандарт привязывает к определённой IDE? В общем, более чем сомнительный момент.
Да, многие используют одинарные кавычки в JS именно по этой причине. В своё время тоже так делал.
Была такая система: в PHP (когда ещё писал на PHP) использовал двойные кавычки, в джаваскрипте одинарные, в HTML двойные. В итоге, можно было в PHP без проблем генерировать блоки на JS, а в JS на HTML (проблемы только в случае двойной вложенности — т.е. HTML внутри JS внутри PHP).
Но дело в том, что такой стиль — это уже немного прошлое десятилетие. Во времена повсеместного использования шаблонизаторов писать HTML-блок внутри строки — дурной тон. Поэтому уже года два использую только двойные кавычки везде, для унификации.
Кстати, если на то пошло, то никто не мешает использовать в HTML одинарные кавычки (это допускается стандартом и прекрасно понимается всеми браузерами), т.е. пример на самом деле легко переворачивается.
Зря от монетизации отказываетесь. По опыту: не очень доверяю абсолютно бесплатным приложениям, особенно тем, которые даже в перспективе не планируется монетизировтаь. Они рано или поздно забрасываются.
Ладно сервера, положим это не так дорого. А следующая версия Android/iOS, новый размер экрана для iPhone и т.д. — это всё вы как планируете поддерживать? Нельзя просто один раз выпустить приложение и забыть о его существовании, оно требует поддержки и постоянных затрат.
Да, это мой личный интерес. А ваши глобальные вещи — это гоголевское «докуда колесо докатится». Вы лично планируете в ближайшее время переезжать в Кремниевую Долину? Я так думаю, нет. Я тоже. И большинство читающих этот тред не планируют.
Я говорю о личном опыте, а вы конструируете себе какого-то виртуального работника, готового завтра рвануть в Кремниевую Долину.
Менеджер — это именно карьерный рост. На отсутствие возможности которого и жаловался человек выше. А профессиональному росту удалёнка никак мешать не может.
Так любая оптимизация обычно не от хорошей жизни. Зачем что-то оптимизировать, если и так всё хорошо? И перевод на удалёнку — один из способов. Но вы что-то выше говорили про большие компании, нет?
То есть надо писать больше кода, так? Вот это и есть пример превосходства динамической типизации над статической. Меньше писать, меньше потом поддерживать.
Ну вот это видимо ключевой момент.
Не знаю, как там комментирует IntelliJ, но скажем у вас три приведённых переменных, вам надо закомментировать вторую. А потом раскомментировать. Мы получим в итоге 3 исходных строки? Честно сказать, не верю, с комментированием всё более-менее понятно, а в момент раскомментирования будет неоднозначность, это неформализуемая процедура в общем случае.
И потом, получается стандарт привязывает к определённой IDE? В общем, более чем сомнительный момент.
Да, многие используют одинарные кавычки в JS именно по этой причине. В своё время тоже так делал.
Была такая система: в PHP (когда ещё писал на PHP) использовал двойные кавычки, в джаваскрипте одинарные, в HTML двойные. В итоге, можно было в PHP без проблем генерировать блоки на JS, а в JS на HTML (проблемы только в случае двойной вложенности — т.е. HTML внутри JS внутри PHP).
Но дело в том, что такой стиль — это уже немного прошлое десятилетие. Во времена повсеместного использования шаблонизаторов писать HTML-блок внутри строки — дурной тон. Поэтому уже года два использую только двойные кавычки везде, для унификации.
Кстати, если на то пошло, то никто не мешает использовать в HTML одинарные кавычки (это допускается стандартом и прекрасно понимается всеми браузерами), т.е. пример на самом деле легко переворачивается.
Ладно сервера, положим это не так дорого. А следующая версия Android/iOS, новый размер экрана для iPhone и т.д. — это всё вы как планируете поддерживать? Нельзя просто один раз выпустить приложение и забыть о его существовании, оно требует поддержки и постоянных затрат.
Я говорю о личном опыте, а вы конструируете себе какого-то виртуального работника, готового завтра рвануть в Кремниевую Долину.