Смотри. Тут очень много аспектов, моментов и нюансов. Попробую по порядку:
1. С точки зрения себя и своих умений, надо пробовать всё. Т.е. устанавливаешь и реально пробуешь что-то на этом сделать!
2. Если встаёт вопрос об анализе самой технологии, то надо иметь достаточный опыт, надо владеть хоть какими-то другими технологиями, чтобы иметь возможность сравнивать лично. Потому, что в каждом языке и в каждой среде есть 100500 нюансов и рекламщики тебе совершенно точно не расскажут про недостатки и подводные камни, с которыми ты будешь ебаться, если начнешь на (любой) новой для себя технологии работать. А косяки и проблемы, как говорит мой личный опыт, есть в любых технологиях: я пока ещё не видел ни одного языка программирования без ошибок в его проектировании (кроме brainfuck).
3. Есть такое понятие, как взрослость технологии. Насколько она стабильна для реальных проектов, особенно для крупных и долгоживущих (в том числе, не умрет ли язык и его поддержка через 3-5 лет), насколько полноценно там поддерживаются разные возможности платформ, куда этот язык собирается. Насколько много к этому языку готовых библиотек и фрэймвёрков. Насколько стабильно и наскллько одинаково оно работает на разных платформах и устройствах? Многим языкам/технологиям потребовались годы и даже десятилетия прежде, чем они стали "взрослыми". А что на какой-либо новой/малоизвестной хернюшке сбацали что-то крутое - не пркпзатель, а иногда и вовсе тупая реклама. Надо смотреть на картину в целом: как массово эту штуку применяют, как много на ней крупных и долгоживущих проектов.
4. Скорость работы кода. Сама по себе, в отрыве от конкретных решаемых задач, не значит буквально ничего. Да и во всех ли случаях код быстрее? Насколько велика разница в производительности? По факту, очень редкие задачи в приложениях требуют максимальной пооизводительности, т.е. производят хоть какие-то обьёмные вычисления. Зачастую, вычислений нет вовсе, только тупая обработка пользовательских событий. А вот "взрослость" технологии - чтобы работало везде одинаково, чтобы была поддержка и уверенность в будущем, вот эти вещи почти всегда оказываются решающими при реальной разработке.
5. Кроссплатформенность - вообще не преиммущество в 2019 году, так как есть практически во всех современных языках-технологиях. И всё опять упирается в то, насколько стабильна конкретная технология, насколько одинаково работает на разных платформах и все вот это.
Оффтоп _Программинг
Про скорость не согласный. Если так подходить - то получится как в той статье, которую ты как-то тут уже приводил, где телевизор две минуты включается. И вообще что до андройда - это же глупость, взять ядро линуха и вкорячить туда джаву с ее виртуальной машиной. Возможно взгляд несколько дилетантский, но факт остается. Это как типа на ноде писать приложения для десктопа. А чего?, работает же. И все более менее современные компы это тянут. И я например как проггер js могу и сайты делать и на полставки приложения для десктопа. Условно. И никому не интересно, что там внутри браузер зашит, который тебе по факту сайт демонстрирует, вместо того чтобы с железом напрямую работать и контролы рисовать. А для чего джаву в андройд включили не совсем ясно, наверное дань моде, а может оракл старался. Ну и потом я не совсем голословен. У нас в компании митапы бывают нередко, там про флаттер было как-то. Правда больше с react-native сравнивалось.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
Частично повторюсь:
0. Интересно - пробуй, пробовать разное - нужно и полнзно!
1. Джаву в андроид очень не зря "вкорячили". Это во-первых безопасность на уровне дизайна системы (к сожалению, безопасность андроида нарушена другими путями, но это другая история), во вторых - джава это далеко не плохой вполне современный ЯП, отодвинутый от железа. А разделение от железа очень полезно: заставляет тебя, как разработчика, не думать, как поддерживать каждую железку, а лишь писать значимую часть кода. И программа везде, где есть ВМ джавы, будет одинаково работать. Это очень хорошо. Это то, к чему вся индустрия шла десятилетия!
2. Скорость выполнения джавы, с учетом всех этих jit, уже давно как сравнима со скоростью нативного кода. Это не является узким местом, технология хороша.
3. Теперь про скорость выполнения кода: реальное узкое место, почему всё тормозит, не потому, что выбраный ЯП / технология недостаточно быстры, а потому, что низкоквалифицированные программисты пишут так. И тестируют лишь на своей супер-мощной современной машине, замечая тормоза только тогда, когда даже у них будет раком вставать. В коде 100500 зависимостей, выполнение тонн бесполезного кода под капотом выбраного фрэймвёрка и т.д. Делай больше руками, не подключай всё подряд - и программа будет быстрой и легковесной!
4. Напомню, что заставить программу тормозить - можно на любом языке. Несколько вложеных друг в друга циклов, избыточная частота вызова обработчиков событий, таймеры, ожидания между потоками - и на ровном месте можно любой язык программирования на любой сверхмощной машине - заставить тупить или вовсе висеть.
...
Рисовать напрямую контролы - ты их все равно через какое-то апи будешь рисовать, ты уверен, что это напрямую?!
А если именно напрямую, т.е. писать байты в графическую память, то твоя программа будет работать ровно на одном устройстве, под которое написана...
Добавлено спустя 30 минут 59 секунд:
И ещё информация для размвшлений.
У гугла - много технологий, было и есть. И этот flutter - далеко не первый яп от гугла. Никто не знает, где он будет через, допустим, пять лет и будут ли о нем вообще помнить.
Вопрос для самопроверки: назовите другие языки программирования от гугла, которые вы знаете.
0. Интересно - пробуй, пробовать разное - нужно и полнзно!
1. Джаву в андроид очень не зря "вкорячили". Это во-первых безопасность на уровне дизайна системы (к сожалению, безопасность андроида нарушена другими путями, но это другая история), во вторых - джава это далеко не плохой вполне современный ЯП, отодвинутый от железа. А разделение от железа очень полезно: заставляет тебя, как разработчика, не думать, как поддерживать каждую железку, а лишь писать значимую часть кода. И программа везде, где есть ВМ джавы, будет одинаково работать. Это очень хорошо. Это то, к чему вся индустрия шла десятилетия!
2. Скорость выполнения джавы, с учетом всех этих jit, уже давно как сравнима со скоростью нативного кода. Это не является узким местом, технология хороша.
3. Теперь про скорость выполнения кода: реальное узкое место, почему всё тормозит, не потому, что выбраный ЯП / технология недостаточно быстры, а потому, что низкоквалифицированные программисты пишут так. И тестируют лишь на своей супер-мощной современной машине, замечая тормоза только тогда, когда даже у них будет раком вставать. В коде 100500 зависимостей, выполнение тонн бесполезного кода под капотом выбраного фрэймвёрка и т.д. Делай больше руками, не подключай всё подряд - и программа будет быстрой и легковесной!
4. Напомню, что заставить программу тормозить - можно на любом языке. Несколько вложеных друг в друга циклов, избыточная частота вызова обработчиков событий, таймеры, ожидания между потоками - и на ровном месте можно любой язык программирования на любой сверхмощной машине - заставить тупить или вовсе висеть.
...
Рисовать напрямую контролы - ты их все равно через какое-то апи будешь рисовать, ты уверен, что это напрямую?!
А если именно напрямую, т.е. писать байты в графическую память, то твоя программа будет работать ровно на одном устройстве, под которое написана...
Добавлено спустя 30 минут 59 секунд:
И ещё информация для размвшлений.
У гугла - много технологий, было и есть. И этот flutter - далеко не первый яп от гугла. Никто не знает, где он будет через, допустим, пять лет и будут ли о нем вообще помнить.
Вопрос для самопроверки: назовите другие языки программирования от гугла, которые вы знаете.
Есть такая обширная тема, программирование для детей. По ней сделано очень много всего: начиная от специальных детских языков программирования, заканчивая обучающими играми про программирование и мультиками.
Но из всего многообразия, в последнее время посоветовали игру - https://store.steampowered.com/app/375820/Human_Resource_Machine/
Вроде как и на русском есть. Так что у кого есть ребёнки возраста 9+ и кто хочет замучить приобщить их к программирвонью - советую.
Но из всего многообразия, в последнее время посоветовали игру - https://store.steampowered.com/app/375820/Human_Resource_Machine/
Вроде как и на русском есть. Так что у кого есть ребёнки возраста 9+ и кто хочет замучить приобщить их к программирвонью - советую.
(немного скучных буков)
В последние месяцы стал углубляться в тему паттернов, архитектур и практик. Путём чтения выбраных книг. И возникли кое-какие мысли (ни в клем случае не претендую на внезапную новизну и 100% правоту, но...).
1. Сами по себе паттерны и архитектура - это попытка описать недостижимый в реальных проектах идеал. Но сам по себе этот идеал не описывает процессы и не гарантирует результат. Хотя-бы потому, что вначале никогда не известны все требования, цели и задачи (и хотелки пользователей) меняются по мере развития проекта. ВСЕГДА.
2. Поэтому куда важнее подходы более высокого уровня, позволяющие минимизировать риски скатывания проекта в неподдерживаемое мессиво. Методы, позволяющие вовремя обнаружить, что что-то не так. Очень тонкая и сложная наука, которая выходит за пределы паттернов и принципов (тот-же SOLID - сам по себе вроде бы не плох, но может затопить проект кучей дополнительных сущностей и лишнего бойлерплейта).
3. Если руководители хоть чуточку не понимают суть, не знают, в какую жопу может привести недостаточно мудрая организация разработки - в проекте будет жопа. Что уж говорить о случаях, если руководители, вдруг, вовсе самодуры.
4. Не всегда можно сразу знать все подходы и принципы, но полезно знать типовые опасности: грани той ЖОПЫ, куда может скатиться проект. И крайне желательно, чтобы в коллективе разработчиков это понимали все, вплоть до джунов. Впрочем, код-ревью требуется все равно, особенно если джуниор что-то там с энтузиазмом кодил по 100500 знаков каждый день.
В последние месяцы стал углубляться в тему паттернов, архитектур и практик. Путём чтения выбраных книг. И возникли кое-какие мысли (ни в клем случае не претендую на внезапную новизну и 100% правоту, но...).
1. Сами по себе паттерны и архитектура - это попытка описать недостижимый в реальных проектах идеал. Но сам по себе этот идеал не описывает процессы и не гарантирует результат. Хотя-бы потому, что вначале никогда не известны все требования, цели и задачи (и хотелки пользователей) меняются по мере развития проекта. ВСЕГДА.
2. Поэтому куда важнее подходы более высокого уровня, позволяющие минимизировать риски скатывания проекта в неподдерживаемое мессиво. Методы, позволяющие вовремя обнаружить, что что-то не так. Очень тонкая и сложная наука, которая выходит за пределы паттернов и принципов (тот-же SOLID - сам по себе вроде бы не плох, но может затопить проект кучей дополнительных сущностей и лишнего бойлерплейта).
3. Если руководители хоть чуточку не понимают суть, не знают, в какую жопу может привести недостаточно мудрая организация разработки - в проекте будет жопа. Что уж говорить о случаях, если руководители, вдруг, вовсе самодуры.
4. Не всегда можно сразу знать все подходы и принципы, но полезно знать типовые опасности: грани той ЖОПЫ, куда может скатиться проект. И крайне желательно, чтобы в коллективе разработчиков это понимали все, вплоть до джунов. Впрочем, код-ревью требуется все равно, особенно если джуниор что-то там с энтузиазмом кодил по 100500 знаков каждый день.
1. Основное это практики и принципы и как следствие архитектура, которая получается соблюдением их думаю. А паттерны это на вроде инструментов для достижения цели -они могут быть хорошими или нет, могут подходить к конкретной работе или нет, просто их надо применять с умом. И как раз приложение и становится поддерживаемым и масштабируемым благодаря этому. Понятно что все меняется, но всякие хотелки свистелки и перделки - это уже отдельный разговор, и если приложение спроектировано с учетом бизнес-целей, которые решает заказчик заказываемым продуктом и договор составлен и подписан, то все дальнейшее - это уже новая работа, радуйся, ты голодным значит не останешься. И насколько приятна будет эта работа и решается на стадии проектирования, когда создается та самая поддерживаемая и масштабируемая архитектура.
2. Эти подходы и есть принципы и практики, и мне лично кажется, что скажем условные лет 50 последних они достаточно известны и особо не меняются. Какие-нибудь принципы MVC и разделение ответственностей скажем. MVC с 70 годов прошлого века скажем.
3. Согласный. Хорошо хоть у нас руководители сами прогеры и могут позволить себе выбирать клиентов.
4. Тоже согласный. И эти твои типовые опасности и есть обратная сторона всяких практик и принципов, которые уже лет 50 не меняются. Ну и тут опять же от руководства многое зависит, насколько оно понимает необходимость постоянного обучения своего персонала. А код-ревью для джунов это один из инструментов роста. Хотя и не для джунов только, но и для компании. И вообще без код-ревью на постоянной основе IT-компания уже не компания, а шарашка.
А вообще на мой взгляд в погоне за баблом у нас не редко в компаниях как раз таки стадию проектирования и пропускают или делают очень поверхностно. И тут один из корней всех зол и кроется. И первый тут шаг - понимание руководством компании важности этой стадии и как следствие второй шаг - убеждение руководством заказчика в этом.
2. Эти подходы и есть принципы и практики, и мне лично кажется, что скажем условные лет 50 последних они достаточно известны и особо не меняются. Какие-нибудь принципы MVC и разделение ответственностей скажем. MVC с 70 годов прошлого века скажем.
3. Согласный. Хорошо хоть у нас руководители сами прогеры и могут позволить себе выбирать клиентов.
4. Тоже согласный. И эти твои типовые опасности и есть обратная сторона всяких практик и принципов, которые уже лет 50 не меняются. Ну и тут опять же от руководства многое зависит, насколько оно понимает необходимость постоянного обучения своего персонала. А код-ревью для джунов это один из инструментов роста. Хотя и не для джунов только, но и для компании. И вообще без код-ревью на постоянной основе IT-компания уже не компания, а шарашка.
А вообще на мой взгляд в погоне за баблом у нас не редко в компаниях как раз таки стадию проектирования и пропускают или делают очень поверхностно. И тут один из корней всех зол и кроется. И первый тут шаг - понимание руководством компании важности этой стадии и как следствие второй шаг - убеждение руководством заказчика в этом.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
Смотри. MVC - он-то конечно с 70-х годов, но тогда он был практически единственным и, возможно, первым паттерном вообще. Полноценно паттерны застолбили своё место в разработке только с выходом книги от "банды четырёх", это начало 90х годов. И то, поначалу там не всё правильно было описано. Например, тогда ещё не понимали, что допустим синглтон - это АНТИпаттерн и использовать его следует крайне осторожно.
Далее - паттерны это действительно лишь инструменты и они описывают лишь части архитектуры, но, как правило, не всю архитектуру. С тех пор теория и практика сильно продвинулись, тот-же DDD - крайне глубокая тема, которая как раз рассматривает, фактически, создание условий разработки, позволяющих проекту развиваться и не скатываться в болото.
Проектирование - это не какая-то отдельная стадия, это то, что должно происходить постоянно, наравне с рефакторингом и анализом.
Но это все лирика и попытки залезть в философию
Более призёмленно, интересно рассматривать конкретные подходы и типовые ситуации, приводящие к геморрою в проектах. Личная подборка жареных примеров (из того, с чем сталкивался лично).
1. Глобальный стэйт / синглтон, жиреющий бесконтрольно. Изначально был создан, видимо, для каких-то очень конкретных вещей - например хранить айдишник сессии на клиенте и прочее такое, но позже стал использоваться для "удобного" прокидывания данных между частями программы. Чтобы не менять сигнатуру метода, дополнительные параметры взяли и хуйнули в глобальный стейт, видимый отовсюду...
2. Бесконтрольное использование событий / сигналов, особенно у мелких низкоранговых сущностей. Некотролируемый ад из спагеттин, которые даже увидить невозможно. Регулярный race condition и вообще изначальная непредсказуемость последовательности выполнения разных частей кода.
3. Ещё один вариант получения спагетти кода: была функция foo(a, b). Понадобилось добавить туда ещё один параметр, c. Но функция уже используется в 100500 местах проекта! Программист знает, что делать как в п.1 - плохо. И вместо этого берёт и изменяет функцию один раз, но с заделом на будущее: foo(a, b, other_params[]). И вот этот самый злоебучий массив вскоре превращается в помойку с торчащей во все стороны лапшёй.
4. База данных! В таблице нехватает поля, но переделывать базу данных и код, конечно-же, лень. Стиснув булки, программист всё-таки делает ещё одно поле типа text и захуяривает туда json или xml с произвольными данными, а иногда даже с кусками кода. Куда позже сра достью начинают добавляться новые произвольные данные, кому что захотелось.
В общем, если где-то в проекте увидишь, что какой-нибудь товарищь делает так, что берёт и передаёт в функцию избыточные данные или глобальный объект, что просовывает спагеттину через базу данных или хитрожопую систему событий - советую подумать о том, чтобы... Нет, я ни на что не намекаю и ни к чему не призываю. Но если кто-то случайно возьмёт и оторвёт ему руки от жопы - это может помочь проекту!
Далее - паттерны это действительно лишь инструменты и они описывают лишь части архитектуры, но, как правило, не всю архитектуру. С тех пор теория и практика сильно продвинулись, тот-же DDD - крайне глубокая тема, которая как раз рассматривает, фактически, создание условий разработки, позволяющих проекту развиваться и не скатываться в болото.
Проектирование - это не какая-то отдельная стадия, это то, что должно происходить постоянно, наравне с рефакторингом и анализом.
Но это все лирика и попытки залезть в философию
Более призёмленно, интересно рассматривать конкретные подходы и типовые ситуации, приводящие к геморрою в проектах. Личная подборка жареных примеров (из того, с чем сталкивался лично).
1. Глобальный стэйт / синглтон, жиреющий бесконтрольно. Изначально был создан, видимо, для каких-то очень конкретных вещей - например хранить айдишник сессии на клиенте и прочее такое, но позже стал использоваться для "удобного" прокидывания данных между частями программы. Чтобы не менять сигнатуру метода, дополнительные параметры взяли и хуйнули в глобальный стейт, видимый отовсюду...
2. Бесконтрольное использование событий / сигналов, особенно у мелких низкоранговых сущностей. Некотролируемый ад из спагеттин, которые даже увидить невозможно. Регулярный race condition и вообще изначальная непредсказуемость последовательности выполнения разных частей кода.
3. Ещё один вариант получения спагетти кода: была функция foo(a, b). Понадобилось добавить туда ещё один параметр, c. Но функция уже используется в 100500 местах проекта! Программист знает, что делать как в п.1 - плохо. И вместо этого берёт и изменяет функцию один раз, но с заделом на будущее: foo(a, b, other_params[]). И вот этот самый злоебучий массив вскоре превращается в помойку с торчащей во все стороны лапшёй.
4. База данных! В таблице нехватает поля, но переделывать базу данных и код, конечно-же, лень. Стиснув булки, программист всё-таки делает ещё одно поле типа text и захуяривает туда json или xml с произвольными данными, а иногда даже с кусками кода. Куда позже сра достью начинают добавляться новые произвольные данные, кому что захотелось.
В общем, если где-то в проекте увидишь, что какой-нибудь товарищь делает так, что берёт и передаёт в функцию избыточные данные или глобальный объект, что просовывает спагеттину через базу данных или хитрожопую систему событий - советую подумать о том, чтобы... Нет, я ни на что не намекаю и ни к чему не призываю. Но если кто-то случайно возьмёт и оторвёт ему руки от жопы - это может помочь проекту!
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
Возможно будет интересно, раз уж кто-то иногда задумывается о какчестве кода.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
(занудство 146%)
Ключевым является не само по себе качество кода, а принятые в коллективе практики и методики, которые обеспечивают поддержание качества кода и архитектуры на допустимом уровне в течение всего процесса разработки и последующей жизни продукта.
Ключевым является не само по себе качество кода, а принятые в коллективе практики и методики, которые обеспечивают поддержание качества кода и архитектуры на допустимом уровне в течение всего процесса разработки и последующей жизни продукта.
А если не коллектив поддерживать будет, а кто-то другой?
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
Сергей писал(а):а кто-то другой?
В современных реалиях все реже встречается. Сейчас, когда чуть ли не каждый product as service, сама же команда разработчиков и поддерживает в течение жизненного цикла. Отдельным мэйнтэйнерам только что-то уже полумёртвое отдают: когда оперативность внесения изменений и затыкания (новых) багов уже не важна и уже не имеет высокой экономической ценности.
Хотя, с другой стороны, слышал о проектах под ключ: когда одна контора делает а потом передаёт всю кодовую базу... Но в этом случае разработка в условиях тесного взаимодействия идёт, чтобы тот другой коллектив тоже участие принимал - хотя-бы был знаком с кодом и архитектурой. Иначе - могут и будут дополнительные финансовые расходы со всех сторон. В статье по твоей ссылке про это многократно упомянуто, кстати
Хотел поковырять технологию создания десктопных приложух на js. Но потом прочитал анекдот и что-то расхотелось... 
Был у меня друг один. Всё на JavaScript писал. И клиента и бэкенд и десктоп даже. И базы данных на джаваскрипте делал и игрушки клепал. Говорил удобно, быстро, клёво. Всё работает, всё устраивает.
Ну, потом его в дурку сдали конечно…
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
Сергей писал(а):десктопных приложух на js.
Электрон. На нем целый скайп сделан и, к примеру, среда разработки VS code.
Минус по сути лишь один: даже самая простая программа будет в себе около 300-400 мегабайт браузера, фактически, содержать. И не тащить плохие практики из мира уеб-разработки, а только хорошие (использовать разумное кол-во фрэймвёрков и готовых библиотек без избытка дутаских зависимостей).
Короче один раз не пи полезно пробовать все технологии и стеки. Всегда надо что-то новое для себя осваивать.
Скайп для линуха вроде только. А еще слак. И что-то жалуются на него. Тормозной говорят, не поворотливый и памяти много отжирает. 
Так вот. По сути тот же C# с .NET выходит, только он все одно круче (C# в смысле). Тут из плюсов только, что не надо отдельный язык учить. Верстаешь себе как в браузер. Ну плюс прослойка для взаимодействия с ОС, хотя там не много вроде знаний.
ADF писал(а):Минус по сути лишь один: даже самая простая программа будет в себе около 300-400 мегабайт
Так вот. По сути тот же C# с .NET выходит, только он все одно круче (C# в смысле). Тут из плюсов только, что не надо отдельный язык учить. Верстаешь себе как в браузер. Ну плюс прослойка для взаимодействия с ОС, хотя там не много вроде знаний.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..
Кто сейчас на форуме (по активности за 1 минуту)
Сейчас этот раздел просматривают: 1 гость