Второй месяц уже ковыряю Dart и Flutter На данный момент весьма двойственное ощущение от всего этого.
С одной стороны, вроде как это реальная действующая и рабочая кроссплатформа, и при этом на данный момент абсолютно свободная. Для сравнения тот же Qt официально "свободен" только для некоммерческих поделок, а за коммерцию официально плати немалые деньги за каждое рабочее место. Интерфейс можно делать очень симпатичный, особенно для мобилок. Так же относительно легко можно переносить морды в ВЕБ На десктопе и мобилках компилируется в найтивный код. А в лучае с чистым Dart так вообще в один единственный EXE-шник, как на каком-нибудь старом добром Delphi
А вот с другой стороны, несмотря на относительно дружелюбный синтаксис Dart, построение более или менее сложного интерфейса превращается в какой-то адский и плохо читаемый спагетти-код. Декларативная часть получатся по сути как бы адским замесом вызова конструкторов и вспомогательных функций с необходимостью вызова кучи callback функций для изненения состояний и реакции них, и уже потом где-то там вызова реального кода обработки. И вся эта фигня как бы вдохновлена React-ом и таким же "богомерзким" WEB-JS спегетти кодо-ложеством, как раз для того чтобы в конечном итоге в чистый JS для WEB и компилироваться.
Кроме того как бы заявленная компиляция в найтив по крайней мере на десктопе по скорости работы конечного кода, мягко говоря, оставляет желать лучшего. Тестовые прогоны на обработке матриц и прочих алгоритмов показали 7-ми кратно отставание от С# .NET Core и 12-ти! кратное от чистого найтива в виде VS C++. Конечный ассемблер пока рассмотреть не удалось, но вполне возможно, что никакой компиляции в те же найтивно-процессорные регистровые integer там нет, а происходит постоянная работа с объектами типа Integer.
Короче, IMHO на десктоп этому пока рано или вообще не надо.А вот для мобилок и ВЕБ-а это неплохой выбор. Хороших альтернатив с унифицированным интерфейсом не так много или они уже требуют ощутимых денежных влияний
Оно "новое и полезное" исключительно для тех, кто слаще морковки ничего не ел....
Ой-ой-ой, сколько высокомерных слов! ))) А я ведь не поленился внимательно прочесть статью. И вместе с автором ничего не имею против чистых и не замутнённых потоков.
НО беда в том, что почти всегда, когда мы имеем дело с многопоточным приложением, которое имеет пользовательский интерфейс, то мы тут же упираемся в однопоточность этого самого интерфейса. И тут-то и начинаются проблемы с синхронизацией.
Если вы писали на Delphi/Lazarus то прекрасно помните классические вызовы через Synchronize. На C# это было через Control.Invoke. И местами логика обновления интерфейса из-за этого становилась весьма запутанной. И ещё с этим можно мириться, если вам нужен постоянно работающий поток, поскольку при этом можно придумать и другие способы передачи результатов или синхронизации.
А что делать, если вам нужны разовые задачи/действия в параллельном выполнении, по завершении которых что-то должно происходить и синхронизироваться с потоком GUI?
Создавать для каждого такого действия отдельный полноценный поток: a) неудобно и многословно б) те же самые проблемы с синхронизацией в) создание и запуск нового потока на всех операционках занимает время.
Для упрощения всего этого и были сначала созданы такие объекты как Task и Future, которые чаще всего реализуются поверх какого-нибудь пула потоков. А затем уже в языках введены такие патерны как async/await поверх них. И эти идеи, как помню, летали на рубеже 2000-2010 повсеместно. Я говорил, что подобные подходы мы делали даже на Delphi ещё ~ в 2008-2009-м. И это было очень удобно. Тем более, что не надо было разделять никакие функции на "красные" и "синие", а просто указать задаче, что выполнить в потоке, что по окончанию, что синхронно в рамках одного понятного вызова.
Но собственно async/await делает почти то же самое (и автор в статье это тоже подтверждает).
Everything after the await gets hoisted into a new function that the compiler synthesizes on your behalf...
И кстати, если уж про Dart, то там кроме async/await есть и более классический подход к параллелизму.
Я понял, что вы топите за Go. Да пожалуйста, но только это тоже Google. И попробуйте догадаться сами почему для продвижения своей GUI библиотеки Google выбрала не Go, а именно Dart. В статье, кстати, даже одна из причин этого есть.
но именно "формошлёпство" - причем на базе именно контролов операционки - являяется правильным.
Практика показывает, что таки нет. И никому это толком кроме Lazarus пока не удавалось. Но даже там с этим постоянные серьёзные проблемы на Линухе и на Маках, из-за неадекватной или своеобразной отрисовки, поэтому кроссплатформенные приложения на другой операционке там порой выглядят очень криво.
Поэтому, подход с собственной кроссплатформенной отрисовкой одинаковой на всех платформах - более перспективный с точки зрения собственно кроссплатформенности. А эксклюзивы как писались под одну операционку так и будут писаться.
Одна из причин, по которой я не люблю WebAssembly.
Любите, не любите, но это как раз выход для тех кто не хочет переписывать навороченный GUI с нуля на HTML+JS, только ради якобы острой необходимости кому-то из клиентов иметь такую возможность.
А вот плохо, что это другая задача.
Это действительно другая задача. Но можно интегрировать часть HTML+JS и в WebAssembly приложение и наоборот.
А вот если бы хотелось что-то кардинально поменять с ВЕБ-ом, то текущий его формат нужно "пристрелить" (сделать deprecated) и разработать новый формат, который стал бы общим как для ВЕБ так и для десктопной разметки. Возможно, что-то похожее на QML, или типа того, НО лучше без явной привязки к языку скрипта. Но мы с вами прекрасно понимаем, что в ближайшем будущем этого не случится. Зато есть интересные и современный инициативы типа QML или Flutter. Последний так к тому же вообще-то пока полный opensource, а за использование Qt+QML в коммерции требуют дорогие лицензии.
Извините, но я не могу часто отвечать. Мне школота на Хабре давно рейтинг понизила за мой стёб над их нежно любимым Питоном и прочим откровенным Ховном для школьников, админов и домохозяек, которое зачем-то пихают теперь в каждый чайник. А писать статьи и играть по идиотским рейтинговым правилам Хабра мне некогда - работы много.
Поэтому, всего хорошего. А вы присмотритесь к Flutter+Dart - лично по-моему у него есть хороший потенциал в качестве замены богомерзкого HTML+JS фронтенда. Всего!
Это ещё почему?! Лет ~16 тому назад я даже реализовывал похожую логику работы на древних Delphi. Причём, мы делали свой собственный вариант Task-ов поверх собственного же пула потоков. И даже собственно похожую логику типа async/await там делали, но сложно-извращенным способом. К слову, на тот момент async/await даже в тот же C# ещё не завезли. Но когда я уже позже увидел те же идеи уже на уровне языка через async/await то был сильно удивлён и обрадован, что наконец-то это появилось в такой простой форме. Поэтому, если лично вам не надо - то это возможно лично ваши проблемы с пониманием нового и действительно полезного.
То есть ничего прогрессивного.
Чего вам прогрессивнее? Си-подобный синтакис сейчас стандарт де факто для большинства новых языков. И для большинства программистов он крайне привычен. И как раз хорошо, что не отличается диаметрально, поскольку с тех же майнстримовых Java/С# будет проще перелезть. Или вам Питоные извраты с обязательными отступами нравятся больше? ;)
Неплохо, но мы всё это видели давно, хоть в том же Delphi.
Тогда вы и должны понимать, что это есть хорошо.
Иными словами, это еще одна "библиотека виджетов", как Qt, GTK, поэтому и сравнивать стоит с соседями в этом ряду.
Это не совсем библиотека виджетов. Это скорее соврменный декларативный подход к интерфейсу, на манер того же QML, где вы сами вольны очень легко создавать свои собственные виджеты на основе богатой библиотеки графических примитивов. Это подход не такой простой как классическое формашлёпство a-la Delphi/Lazarus/C#+WinForms, но зато по сути ни в чём вас не ограничивает в плане стиля и дизайна и никак не привязан к контролам самой операционки (как древний VCL) Ну а третьи фирмы и интузиасты как всегда накидают вам готовых виджетов по самое нехочу.
Да, в случае .EXE это нормально, но в случае вещей типа Веба это нафиг убивает открытость, интеграция должны была бы быть выше, а не ниже.
В случае ВЕБ-а это практически ровно тоже, что предлагает подход через WebAssembly от многих конкурентов. Если вам нужно приложение, с равнозначной мордой в WEB для какого-то заказчика, который почему-то чистый десктоп "так не любит, что даже кушать не может" (tm), то это как раз очень хороший и оптимальный подход. А вот если заказчику, нужно не приложение - а ВЕБ-сайт или ВЕБ-магазин и т.п., то это уже другая задача и должна решаться другими инструментами - ручки и блокнот / Adobe Dreamweaver / Готовые движки типа WorldPress и т.п.
Тут вот пишут "по инфе от знакомого, в дарте, нет векторов
В Dart массивы и списки объеденены в понятие generic List. Они могут быть как расширяемыми так и константными. За производительность не скажу. Скоро (через пару недель) сам буду прогонять реальные серьёзные тесты на Dart. Скорее всего, sсimark2 для начала. Самому интересно, какие результаты покажет финальный exe-шник. Я вам больше скажу. Там ещё и типа byte как такового нет. Эффективная работа с отдельными байтами только через библиотеку.
НО лично я пока рассматриваю Flutter+Dart как хорошую возможность закрыть мобильное направление и ВЕБ-морду. Поэтому, мне там супер-скорость чистого незамутнённого С++ вряд ли нужна. А вот буду ли переносить какой-нибудь следующий десктоп на это - как раз и покажут реальные тесты и прочие оценки. НО в любом случае мне это уже больше нравится в рамках моего проекта, чем Qt+QML по целому ряду параметров.
Dart - язык не очень сложный, при этом современный, безопасный (с автоматической сборкой мусора), со строгой статической типизацией, с async/await шаблонами и т.п. Синтаксис Си-подобный - напоминает Java, C#, даже C++ ( в плане вызова инициализаторов в конструкторах ). Изначально задумывался как более эффективная замена JS, но по мере развития и вместе с библиотекой Flutter уже перерос в нечто существенно большее. Есть свои "тараканы" (странности), как, например, своеобразный подход к модификаторам доступа и т.п., но в целом от лидеров жанра мало чем отличается и очень быстро развивается.
Для десктопа Flutter+Dart использует Ahead-of-Time (AOT) компиляцию в целевой найтивный код и порождает один найтивный исполняемый файл для целевой платформы (в случае с Win - EXE-шник), без тонн библиотек как, например, Qt. Для мобилок тоже самое - в случае Android стандартный apk.
Для всех платформ используется один и тот же собственный способ отрисовки поверх библиотеки SKIA, которая в свою очередь работает поверх OpenGL / Vulkan. Платформенные или сторонние библиотеки виджетов (типа Qt, GTK) не используются, поэтому отображение одинаково на всех платформах.
Для случая ВЕБ это компилируется в оптимизированный JS, а отрисовка идёт через SKIA на Canvas. Для индексации поисковыми машинами такой ВЕБ не годится, но с другой стороны это и рассчитано на приложения, а не на сайты.
TypeScipt просто чуть меньше воняет, чем сам JS, да то лишь на этапе написания. Но по сути это тоже самое JS скрипто-ложество поверх Хромиума, как вы и написали, вместо нормального оптимизированного найтивного кода.
Кому вообще нужен т.н. фронтенд, если можно было бы за то же время создать несколько клиентских десктопов, работающих и выглядящих одинаково на всех операционках?
Flutter+Dart - вот действительно многообещающий проект, который способен дать пинка всем фронтендным скрипто-кодерам. Qt+QML - тоже не плохо, но требуют знакомства с C++, что для "мамкиных кодеров" будет сложновато.
Ну а по цифрам:
VS Code только стартует без проекта и тут же выжирает на моём ПК ~900 Мбайт
На этом фоне Lazarus стартует с открытым большим проектом и потребляет всего 55 Мбайт (сама среда написана на том же FPC).
- VS Code - написано на TypeScript, JavaScript, HTML, CSS - Microsoft Teams - написано на TypeScript, Angular, React - Discord - написано на TypeScript (with ReactDiscord)
Прекратите писать приложения на скриптовом JS Ховне со скриптовыми библиотеками, вернитесь к Си / C++ / Objective-c / ObjectPascal. Либо развивайте такие языки как D и т.п. И будут тогда ваши приложения летать и при этом потреблять килобайты вместо гигабайт.
НО только для этого нужно будет послать в #опу все мега-Хениальные "идеи" от эФФФективных мЭЭЭнеджеров, а "мамкиных кодеров" не брать на работы, а отправлять после школы учиться в университеты. А вот как это сделать при главенствующем тупом подходе, который формулируется как "всё должно было сделано ещё вчера, а-то у меня диаграммы Ганта будут некрасивые" (tm) - кто бы знал? )))
Сегодня мы снова приходим к этому — через Rust, Swift, TypeScript. Мы возвращаем уважение к типам, потому что устали от хаоса. Ирония в том, что ответ на этот хаос был у нас с самого начала — в старом, строгом, занудном Pascal.
Это якобы "типовое занудство" было испокон создания языков программирования. Тупо потому, что на базовом уровне железа процессор как минимум только примитивными типами - машинно-разрядными integer, double (а в древние времена и без double) и ещё машинно разрядными указателями и оперирует. А когда вы добавляете любую динамику, то она тут же тянет за собой необходимость отдельного сохранения доп. данных, их проверки и косвенного вызова некоторых лишних процедур для понимания с чем собственно мы имеем сейчас дело - а это всё лишнее время, время, время, которое суммируется в достаточно большие задержки.
Вообще, IMHO сейчас, к большому сожалению, народилось уже целое взрослое поколение т.н. "программистов", которые вообще крайне слабо себе представляют как именно работает конечный машинный код на процессорах (причём не важно на какой архитектуре - на x86/64 ли, на ARM ли, на другой ли). В основном это самоучки со стороны, без профильного образования, въехавшие каким-то боком в профессию на волне IT-бума тупо за деньгой. И львиная доля из них как раз и есть мамкины скрипто-кодеры на JS или Питоне, но так же и часть Жабистов, C-Шарпистов и т.п. Иногда из общения с такими "профессионалами" просто диву даёшься, какую чушь они несут на собеседованиях или пишут в свои блогах.
Это похоже на такой же ужас, как если бы ваш лечаший врач никогда не изучал основы органической химии, биологии, анатомии, и не проходил интернатуру, а так по быстрому нахватался бы знаний из пары книг и советов от друзей, и приступил бы к вашему лечению ))) Может быть на сотом пациенте он бы чего-то бы и понял, почитал бы и глубже поучил бы, но первые минимум сто (включая вас) точно бы лежали уже в деревянных ящиках.
Ребята из университетов хотя бы сначала базовую школу булевой алгебры, алгоритмов, архитектур, ассемблеров, C/C++, операционок, синтаксически анализаторов и т.п. так или иначе проходят, а уже потом пересаживаются на тот же JS при насущной необходимости.
А вот причина стремительного взлёта полно-динамического скриптинга типа JS только одна - это идея быстрого кроссплатформенного ВЕБ-мордошлёпства, а вовсе не удобства сплошной динамики без статики. Эта идея, во-первых, очень понравилась т.н. "эффективным менеджерам" на рубеже 2000-х, а во-вторых, надо признать, что на рубеже 2000-х и последующие лет ~15 хороших альтернатив-то почти и не было.
С++Qt был достаточно сложен, и долгое время покрывал только десктоп. Да и сам современный С++ слишком заковырист и опасен для большинства описанных выше "мамкиных кодеров" без хорошего образования и большого опыта разработки. QML же деятели из Qt запустили уже существенно позже.
Многочисленные Java фреймворки тормозили нещадно и особой красотой не обладали. А JavaFX тоже уже позже стартанул, но как-то до сих пор особо и не взлетел.
C# был долгое время без кроссплатформы, а десктоповый GUI у них и до сих пор без кроссплатформы без сторонних решений. Ну а с Вебом у MS вечная чехорда, то чистый ASP.NET, то Razor, то Blazor, завтра ещё что-нибудь.
Borland Kylix забросил по причине убытков. Embarcadero со своим мега-глючным FMX тоже делала все как будто нехотя и медленно, хотя кто-то сейчас мобилки уже и на этом пишет. И между прочим, вроде бы древний и замшелый Delphi/Object Pascal сейчас на 10-м месте в рейтинге TIOBE.
А в это время и на этом фоне с начала 2000-х "мамкины кодеры" очень быстро могли осваивать ВЕБ и JS и это было относительно безопасно для производственного процесса и очень выгодно для т.н. эффективных мЭ-Э-Энеджеров.
Сейчас есть надежда, что, например, благодаря денежным вливаниям серьёзно взлетит такой фреймворк(язык) как Flutter(Dart) для красивого, современного, безопасного, кроссплатформенного и производительного мордошлёпства (включая и идентичную отрисовку в Веб поверх Canvas). А может появится что-то ещё лучше этого. Короче, "будем посмотреть" (tm)... НО если проект Flutter+Dart стараниями Google взлетит, то тогда велика вероятность, что HTML+JS погонят SSаными тряпками из кросплатформенного мордошлёпства и тем более с серверов туда, где ему изначально самое место - на поддержку динамики ВЕБ-сайтов. Но пока здесь ключевое слово - #если ))
На Qt с их QML надежды не много. Да, там очень хорошее конечное быстродействие и очень объёмная библиотека, но как ни крути без знания C++ всё равно соваться не желательно, что как бы уже повышает порог вхождения. Ну а Delphi/Lazarus (Object Pascal) при всём моём глубочайшем уважении, какой там фреймворк уже не прикрути, уже вряд ли снова станет майнстримом. Слишком уж архаичен синтаксис. Много чисто исторических затычек из разряда "так уж повелось" и т.п. ХОТЯ В НЕКОТОРЫХ НИШАХ ОН ПО ПРЕЖНЕМУ ХОРОШ, поскольку при грамотном использовании даёт быстродействие найтивного кода сравнимое с Си/C++ при гораздо меньшей вероятности выстрелить самому себе в ногу.
JS рождался как срипт на коленке для придания динамичности статичному HTML. Кто тогда в Netscape думал, что это скриптовое простенькое Ховно (на момент создания) будет когда-то всерьёз использоваться для серьёзной разработки интерфейсов или тем более на серверах?! Но беда в том, что в погоне за дешевыми кодерами (даже без профильного образования) и веб-кросплатформенностью т.н. "эффективные мЭЭнеджеры" сделали ставку на веб-мординг - ну и понеслась.
С другой стороны чистый Pascal язык сугубо академический. На нём почти ничего массово не писали. Тот Pascal которым до сих пор пользуются - это Object Pascal (Delphi / Lazarus). А в ObjectPascal как раз испокон веков для удобства хранения любых типов есть динамический тип данных Variant .Этот тип по реализации несколько отличается от dynamic в C# или Dart, и по скорости работы конечного кода чуть более эффективен. НО при его использовании тоже запросто словить ошибку времени выполнения.
var V1, V2, V3: Variant; begin V1 := 'aaa'; V2 := 1; V3 := V1 + V2; // Здесь будет EVariantError во время исполнения ...
Другое дело, что в таких языках как ObjectPascal объявляя переменную как Variant вы как бы понимаете зачем вы это делаете, а значит и осознаёте свою ответственность. Тогда как в скриптовых и изначально динамических убожествах типа JS у вас просто нет выбора.
А когда в больших проектах на JS осознали "масштаб трагедии", то и стали прикручивать и продвигать всякие костыли типа TypeScript.
Кстати, хорошо хоть Google сейчас активно пытается исправить часть бед динамических скрипто-убожеств, активно продвигая такие языки и opensource библиотеки со строгой статической типизацией как Go или Dart (Flutter).
Ваши замечательные красивые потуги на FMX, к сожалению, уже не смогут переломить общей тенденции угасания интереса к Паскалю и к Delphi. Молодежь практически уже не смотрит в эту строну. Я-то ещё, кстати, использую FPC в реальной работе, но в основном уже только как быстрый и самодостаточный кросс-платформенный бэкенд.
Дельфи всё ещё пытаются втюхать за дорого, что почти никому кроме поддержки legacy-проектов уже не нужно. А вот FPC и Lazarus как opensource на этом фоне очень даже неплохи. Для создания небольших кросс платформенных десктопных программ и утилит с GUI подходят на ура. Скорость конечного кода на уровне GCC. Всякие питоновские скриптовые убогости там и рядом не стояли. При этом вероятность ошибиться и выстрелить себе в ногу на порядок меньше чем на C++.
Но это уже не мэйнстрим. А в корпоративной среде вообще с большим натягом применимо, поскольку WEB-интерфейсы только через одно место, и никаких тебе тонн готовых кирпичей и библиотек на каждый случай. Да даже и классические десктопные интерфейсы уже кажутся слегка устаревшими на фоне всяких там QML или WEB-движков прикрученных к дестопу.
Ну и среди миллениалов и более поздних поколений с сырой памятью и указателями (при необходимости) умеют работать уже только единицы, т.е. не вчерашние "грузчики", решившие вдруг податься в программисты из-за денег, а те кто на эту специальность в университетах учился. Но в университетах "эти ваши" Паскали уже больше не изучают. Из низкоуровневых в основном только С и C++. Поэтому, какой бы ни был хороший, современный и удобный компилятор с Паскаля - это уже по любому экзотика.
Ко всему прочему, в связи с вышесказанным уже почти не найти специалистов на Delphi / Lazarus(FPC). И поэтому т.н. эФФФективные мЭЭЭнэджеры (т.е. обычные тупые управленцы, которые сами обычно ни в чём кроме диаграмм Ганта и графиков доходов толком не разбираются) уже крайне боятся проектов на этом языке.
Очень долгое время сотрудничал с парой европейских контор по производству программно-аппаратных комплексов - нет и не было там никаких бизнес-аналитиков. Иженеры сами объясняли программистам, программисты сами дергали инженеров. Клиенты общались и передавали свои хотелки через обслуживающий персонал, через сайт, и в редких случаях напрямую с инженерами. Руководство полагалось на мнения и решения ведущего инженера и руководителя разработки.
После начала СВО вынужден был начать сотрудничать с российской конторой. Куча каких-то бизнес-аналитиков на всех этапах, которые по большому счету не нужны от слова совсем. Они лишь поверхностно вникают в производственный процесс, как правило не имею никакого профильного образования и программировать сами не умеют. По сути они лишь выступают в роли испорченного телефона и частично стенографиста. Почти любой вопрос гораздо проще и быстрее решить напрямую без их участия. И это не говоря ещё о куче каких-то почти полностью бесполезных менеджеров и промежуточных начальников. При этом везде какие-то бюрократические барьеры на пустом месте, которые походу существуют лишь за тем, чтобы кормить эту кучу почти абсолютно бесполезных для дела трутней.
Все IMHO просто. Например, в 90-е большими зарплатами (а не наворованными суммами) могли похвастаться в основном экономисты и юристы. В те времена экономические факультеты и курсы штамповали сотни тысяч бесконечно пафосных и претенциозно-амбициозных экономистов и мЭнЭджеров, которые при этом подчас даже после ВУЗа не могли правильно подсчитать элементарные проценты (сам неоднократно сталкивался), а по знаниях реального учета уступали порой даже младшему бухгалтеру. НО были убеждены в свой бесконечной значимости и требовали больших зарплат. И что характерно, часто получали желаемое. Такие были времена.
Сейчас платят хорошие деньги в IT. Поэтому-то большое количество лезет в эту сферу вовсе не по призванию и даже не по способностям, а тупо по меркантильному интересу.
Лично у меня высшее техническое - инженер-системотехник. И программирование как таковое (тогда это были (Си/C++/Pascal/Fort/Lisp/Разные ассемблеры и т.п.) - это было лишь одним из камней в системе обучения. Как условная биология или химия в обучении медиков. А кроме этого чего только не изучали. Даже собственные процессоры проектировали. НО как раз тогда-то кроме сис.админов или программистов по тупому складскому и бух.учёту, и при чем порой на довольно скромной зарплате (по сравнению даже с продажниками), особенно никто и не нужен был. И поэтому в профессии куда больше было людей именно по призванию, даже если и без высшего образования.
Я недавно поучаствовал в собеседовании со стороны как бы работодателя и насмотрелся на горе-кандидатов. В основном какие-то пафосные заготовленные пузыри про SOLID, МVVC, dependancy injection и т.д. и т.п., НО тупо приостановишь этот пафос и спросишь что-нибудь совсем простое типа, а зачем нужен абстрактный класс или какие вы знаете методы сортировки или что будет с целым числом после поразрядного сдвига влево/вправо, или что-нибудь про отличие стека от кучи, или просьба упростить булево выражение, ... - и всё - сразу видно, что никаких даже элементарных базовых знаний там и нет.
И IMHO глупость ситуации ещё в том, что частенько между нанимающей стороной и работодателем лежит прослойка в виде молоденьких дурочек/дурачков из HR, которые сами-то нифига особо в этом не понимают, но так же проставляют "обязательные" галочки на всякие там SOLID, MVVC и т.п., вот кандидаты и несут потом все как один эти зазубренные без особого понимания термины.
На мой IMHO ~80% ломящихся сейчас в IT вообще не математического, не логического и даже не технического склада ума. То ли родители отправили учиться (потому как это модно и денежно), то ли сам решил сменить карьеру неудачного повора (условно) на "удачного" программиста так же тупо из-за денег, и т.п.
Одно тут радует, что пока такое в гораздо меньшей степени возможно в нашей медицине. А иначе к врачам было бы ходить просто страшно и лучше было бы тогда делать даже сложные операции на сердце у деревенской бабки.
Если вы даете на любом серьезном ресурсе право выборного голосования безмозглой школоте или толпе, то ваш ресурс быстро и превращается в тусовочку для безмозглой школоты.
Даню Милохина сюда пригласите писать посты и комменты - он тут первым IT специалистом уже через неделю станет, поскольку тупая школота накончает ему плюсиков в комменты по любому :D
все высоконагруженные алгоритмы связанные с рендерингом встроены в движок...Юзеру остаётся управлять только логикой.
И все эти алгоритмы написаны на С++. А ты вообще-то не юзер, а девелопер. Шаг влево, шаг вправо - ой а мне вдруг нужно какой-нибудь свой алгоритм на матрицах просчитать. И что? Будешь ждать пока взрослые, умные дяденьки для тебя этот алгоритм запилят или довольствоваться пока в 2-е 3-е меньшей производительностью? Да и вообще профессиональному девелоперу в этой индустрии не знать С++ уже странно. Другое дело, что Unity изначально и нацеливался не на профессионалов индустрии, а на дизайнеров одиночек и на мелкие т.н. инди-команды, где вместо программистов с дипломом зачастую один-два школьника на подхвате.
Я не игродел. Но в силу своей специфики прекрасно знаю насколько хреново оптимизируется конечный код c MSIL в сравнении с C++, не говоря даже про объективные тормоза сборщика мусора и т.п. А вот в конторе с которой периодически моя фирма сотрудничает есть два парня работающих с UE. Они там делают очень специфические вещи по интерактивной визуализации некоторых физических процессов. И там чистой счетной матетематики, а не просто логики хоть отбавляй. А значит если нужно считать это быстро, то без хорошей оптимизации на C++ не обойтись. И кстати один из них тоже рассказывал, что начинал в студенчестве с Unity, но позже переполз на UE.
Да и мне-то все равно, на чем вы там свои поделки делаете. Но говорить о том что С++ это прошлый век, когда у вас даже сам Unity-движок безальтернативно на этом С++ и написан - это какие-то детские глупости про розовые пони.
C++ это прошлый век. Даже пользователи UE4 стараются писать всё на блюпринтах, и не лезть в C++
Прошлый, прошлый. Только вот беда, что одни и те же несложные алгоритмы на С++ даже без особых танцев с бубном и оптимизации на SSE/AVX и то выполняются порой в разы быстрее, чем на C#. SciMark вам в помощь для осознания сего факта.
А C# я тоже очень люблю в офисных и даже в инженерных поделках. Один только LINQ to Object экономит массу времени в написании рутинного перемалывания данных.
Но все же не место этой удобной мэнеджет погремушке в высокопроизводительном коде. И напрасно Unity на радость школоте его как скрипт прикрутили. UE на этом паровозе им не догнать.
Это статья, кстати, очень хорошо отражает ужас, в который порой превращается современный IT.
С одной стороны «эффективные менеджеры»(tm), коим часто по образованию по-хорошему нужно торговать помидорами на рынке, бойко крича, демпингуя и отбивая себе место под солнцем среди кавказских торговцев в кепке.
С другой стороны, приблизительно такие же по уровню «программисты»-самоучки сразу после школы/колледжа или месячных курсов примитивного жаба-скрипта с отточенным навыком и умением гуглить, какую именно жаба-скрипт библиотеку нужно молниеносно закачать для решения той или иной проблемы (конечно, если такая библиотека уже есть).
Все это сливается в банду aka команду и бежит на фрилансовые площадки отбивать себе место под солнцем, бойко конкурируя с индусами в чалмах, работающими за еду, и стремиться выполнять аж по 10 контрактов в месяц!
И как при этом люди в компаниях годами и десятилетиями выпускают, развивают и совершенствуют один и тот же продукт?!
Наверное, у них просто нет таких чудесных «эффективных менеджеров» и замечательных и реактивных «жаба-скрипт исполнителей».
И, наверное, это к счастью :)
Не так здесь то, что во времена моей учебы программазмом и схемотехникой в основном занимались те, кому это было реально интересно. Поэтому, на выходе из ВУЗов как правило уже получались специалисты весьма высокого уровня и хорошо знающие основы. А шелуха типа зубрежки языков или переключение между ними в зависимости от задачи была как бы немного вторична.
А карьеристы за зарплатой тогда шли в Финэк или на юридические факультеты. И приблизительно так же обсуждали, что бы им по-быстрому и попроще поучить, чтобы в блатную конторку на хорошую зарплату пристроиться.
> Просто у вас необычный случай… и ваша зарплата за этот стек…
Необычный случай? Зарплата за Стек? Что вы несете?
Классическое найтивное программирование вдруг стало чем-то необычным?
А платят теперь за понятие «стек технологий» (так любимое эффективными менеджерами) а не за результат, здравый смысл и возможность писать быстрые программы без каких-либо ненужных прослоек?
Давайте я объяснюсь.
Я уже писал как-то в другой теме, что вот включаю я свой персональный компьютер и не вижу там ни одной хоть сколько бы серьезной и нужной мне программы, написанной на javascript-е. И уж тем более ни одной на Питоне. А ведь последний чуть ли не в лидерах должен быть по количеству шума вокруг него в последние годы.
Но я ничего не вижу на десктопе и из лидеров данного конкретного списка. За исключением разве что Objective-C (но я не вижу и Objective-C, поскольку в моей области деятельности Маки нафиг никому не нужны).
Да у меня даже и на C#-то на десктопе днем с огнем ничего не сыщешь (кроме разве что каких-то мелочей от самой MS). Хотя, казалось бы, это-то должно бы давно уже появиться.
Все графические редакторы, все инженерные и математические пакеты, весь 3D, все нужные мне офисы и бухгалтерии, все системные утилиты и прочие интрументы для работы, все это либо C++, либо в том числе и Delphi (Delphi в моем случае это AIMP, утилиты Auslogics и хелпмэйкер HelpNDoc, пару хороших утилит для Баз-данных включая DBWorkbench, сборщик FinalBuilder и шикарный но дорогой автотестер TestComplete ). И просто поверьте, что я не выбираю программное обеспечение по принципу на чем это сделано.
И только не нужно мне рассказывать, что это мол де десктоп, а вот у нас мол в корпоративе все крутится на серверном скриптике «A» под библиотечкой «B» с прикрученными справа и слева пакетами «C» и «D», а визуализируется на HTML страничках под нехилым набором из новомодненьких библиотек E, F, G (набор которых чуть ли не каждые пару-тройку лет меняются).
И изначально все это было задумано вашими «эффективными менеджерами», чтобы ускорить и упростить.
Только на деле чаще всего выходит, что на создание и отладку всего этого времени уходит не меньше, а то и больше, чем на написание быстрого десктопа и серверной части сразу под конкретные платформы (естественно, кроме самих серверов и баз данных). А хуже то, что постоянная изменчивость и нестабильность вышеперечисленных «стеков», помноженная на нестройность и не строгость скриптовых технологий, еще раз помноженная на слабую компетентность непрофильных специалистов и четвертый раз помноженное на естественные скриптовые тормоза никак в результате не приводит к заветному для «эффективных менеджеров» удешевлению и упрощению.
Да и в результате чаще всего мы видим лишь очередную эмуляцию десктопа в Браузере, поскольку все html красивоти для серьезной работы как бы нафиг не нужны. Ну и не факт, что это вообще будет работать через пару лет при смене браузера и поколения скриптового движка.
При этом я вовсе не умаляю существенную значимость того же javascript-а в сайтостроительстве.
Хотя по размерам кода современных сайтов IMHO на таком изначальном убожестве это писать уже опасно. Недаром и появляются обертки типа typescript-ов
> При итоговом выборе вступают еще и другие критерии, как, например, количество людей на рынке труда могущих, и главное желающих с ним работать, чтобы потом было кому поддерживать и развивать это всё.
Ну вы же, думаю, не надеетесь, что что-либо из вышеперечисленных мной серьезных пакетов будет вдруг непонятно зачем переписано на какую-нибудь Скалу или Го лишь мимолетной моды ради?
Или тем более на скриптовые тормоза?
А главное зачем?! Чтобы нанять якобы дешевых спецов? См.выше. Да и по факту спецы эти уже не дешевы.
А теперь давайте более предметно и прагматично.
Вот нужны десктопные морды с небольшими мобильными довесками.
В силу задач (управление промышленными контроллерами) на десктопе желательно иметь возможность быстро спускаться до низкоуровневого программирования и время отклика должно быть минимален по возможности. Т.е. желателен быстрый найтив.
C# и вообще менеджет подход не желателен (к тому же часть все равно придется писать на найтиве).
Ну, например, можно и на С++Qt, благо опыт есть.
Но оказывается, что и современный Дельфи совсем не плох.
Интерфейсная часть накидывается элементарно и относительно быстро. А при использовании FMX теперь можно это замутить хоть даже и под Линукс. А вся подноготная часть пишется одинаково просто хоть на прикладном уровне, хоть на уровне прямого доступа к памяти и даже ассемблера и с почти бесшовным склеиванием с СОМ и низкоуровневым API на любой поддерживаемой платформе. При этом вероятность выстрелить себе в ногу при написании рутинной части все же существенно меньше, чем на C++.
Специалистов на просторах СНГ полно, да и за пределами есть. И это уже чаще именно специалисты, а не ничего не знающие пока толком школьники, которые лишь мечтают вызубрить (именно вызубрить) какую-то очередную новомодную фенечку ради заветной большой зарплаты.
Но только даже на моих глазах таких фенечек с 90-х уже куча промелькнула и пропала в никуда.
И знаете, я бы все понял, если бы в этих списках новомодных и хорошо-оплачиваемых языков, появлялись бы такие вещи как язык «D». И не только появлялись, но и выходили бы хорошие IDE, а сторонние фирмы наперебой клепали бы инфраструктуру и компоненты для этого.
Но вместо этого лишь куча таких же как и «D» многообещающих, но бесплодных выстрелов.
Ну или если бы C# на найтив перевели с возможностью прямого доступа к пямяти и ее очистки по желанию и т.п.( а ведь грозились когда-то).
А вместо этого MS лишь мечутся как Г в проруби и регулярно кидают своих адептов.
И вот на этом фоне Дельфи или даже Лазарь на найтиве выглядят весьма даже неплохо и развиваются вполне предсказуемо и стабильно. Не говоря уже о конечном результате в виде единственного запускаемого файла, который стабильно, быстро и совершенно не прожорливо пашет потом годами и ему как и Си-шному найтиву очень долго потом плевать и на смену операционок, и от смен прослоек он тоже не зависит.
Поэтому, если я могу к счастью выбрать сам, не опираясь на мнения «эффективных менеджеров» (ака недоучек из экономических колледжей) и не на мнение тинейджеров без профильного образования, то выходит, что и Дельфи живее всех живых, да еще и мобильные довески делать позволяет опираясь практически ровно на тот же код.
А платят мне и напарнику за конечный результат, а не зарплату. Поэтому, и сумма в среднем большая выходит.
Второй месяц уже ковыряю Dart и Flutter
На данный момент весьма двойственное ощущение от всего этого.
С одной стороны, вроде как это реальная действующая и рабочая кроссплатформа, и при этом на данный момент абсолютно свободная. Для сравнения тот же Qt официально "свободен" только для некоммерческих поделок, а за коммерцию официально плати немалые деньги за каждое рабочее место.
Интерфейс можно делать очень симпатичный, особенно для мобилок.
Так же относительно легко можно переносить морды в ВЕБ
На десктопе и мобилках компилируется в найтивный код. А в лучае с чистым Dart так вообще в один единственный EXE-шник, как на каком-нибудь старом добром Delphi
А вот с другой стороны, несмотря на относительно дружелюбный синтаксис Dart, построение более или менее сложного интерфейса превращается в какой-то адский и плохо читаемый спагетти-код. Декларативная часть получатся по сути как бы адским замесом вызова конструкторов и вспомогательных функций с необходимостью вызова кучи callback функций для изненения состояний и реакции них, и уже потом где-то там вызова реального кода обработки. И вся эта фигня как бы вдохновлена React-ом и таким же "богомерзким" WEB-JS спегетти кодо-ложеством, как раз для того чтобы в конечном итоге в чистый JS для WEB и компилироваться.
Кроме того как бы заявленная компиляция в найтив по крайней мере на десктопе по скорости работы конечного кода, мягко говоря, оставляет желать лучшего. Тестовые прогоны на обработке матриц и прочих алгоритмов показали 7-ми кратно отставание от С# .NET Core и 12-ти! кратное от чистого найтива в виде VS C++.
Конечный ассемблер пока рассмотреть не удалось, но вполне возможно, что никакой компиляции в те же найтивно-процессорные регистровые integer там нет, а происходит постоянная работа с объектами типа Integer.
Короче, IMHO на десктоп этому пока рано или вообще не надо.А вот для мобилок и ВЕБ-а это неплохой выбор. Хороших альтернатив с унифицированным интерфейсом не так много или они уже требуют ощутимых денежных влияний
Ой-ой-ой, сколько высокомерных слов! )))
А я ведь не поленился внимательно прочесть статью. И вместе с автором ничего не имею против чистых и не замутнённых потоков.
НО беда в том, что почти всегда, когда мы имеем дело с многопоточным приложением, которое имеет пользовательский интерфейс, то мы тут же упираемся в однопоточность этого самого интерфейса.
И тут-то и начинаются проблемы с синхронизацией.
Если вы писали на Delphi/Lazarus то прекрасно помните классические вызовы через Synchronize. На C# это было через Control.Invoke.
И местами логика обновления интерфейса из-за этого становилась весьма запутанной.
И ещё с этим можно мириться, если вам нужен постоянно работающий поток, поскольку при этом можно придумать и другие способы передачи результатов или синхронизации.
А что делать, если вам нужны разовые задачи/действия в параллельном выполнении, по завершении которых что-то должно происходить и синхронизироваться с потоком GUI?
Создавать для каждого такого действия отдельный полноценный поток:
a) неудобно и многословно б) те же самые проблемы с синхронизацией в) создание и запуск нового потока на всех операционках занимает время.
Для упрощения всего этого и были сначала созданы такие объекты как Task и Future, которые чаще всего реализуются поверх какого-нибудь пула потоков. А затем уже в языках введены такие патерны как async/await поверх них.
И эти идеи, как помню, летали на рубеже 2000-2010 повсеместно.
Я говорил, что подобные подходы мы делали даже на Delphi ещё ~ в 2008-2009-м. И это было очень удобно. Тем более, что не надо было разделять никакие функции на "красные" и "синие", а просто указать задаче, что выполнить в потоке, что по окончанию, что синхронно в рамках одного понятного вызова.
Но собственно async/await делает почти то же самое (и автор в статье это тоже подтверждает).
И кстати, если уж про Dart, то там кроме async/await есть и более классический подход к параллелизму.
Я понял, что вы топите за Go. Да пожалуйста, но только это тоже Google.
И попробуйте догадаться сами почему для продвижения своей GUI библиотеки Google выбрала не Go, а именно Dart. В статье, кстати, даже одна из причин этого есть.
Практика показывает, что таки нет. И никому это толком кроме Lazarus пока не удавалось. Но даже там с этим постоянные серьёзные проблемы на Линухе и на Маках, из-за неадекватной или своеобразной отрисовки, поэтому кроссплатформенные приложения на другой операционке там порой выглядят очень криво.
Поэтому, подход с собственной кроссплатформенной отрисовкой одинаковой на всех платформах - более перспективный с точки зрения собственно кроссплатформенности. А эксклюзивы как писались под одну операционку так и будут писаться.
Любите, не любите, но это как раз выход для тех кто не хочет переписывать навороченный GUI с нуля на HTML+JS, только ради якобы острой необходимости кому-то из клиентов иметь такую возможность.
Это действительно другая задача. Но можно интегрировать часть HTML+JS и в WebAssembly приложение и наоборот.
А вот если бы хотелось что-то кардинально поменять с ВЕБ-ом, то текущий его формат нужно "пристрелить" (сделать deprecated) и разработать новый формат, который стал бы общим как для ВЕБ так и для десктопной разметки. Возможно, что-то похожее на QML, или типа того, НО лучше без явной привязки к языку скрипта.
Но мы с вами прекрасно понимаем, что в ближайшем будущем этого не случится.
Зато есть интересные и современный инициативы типа QML или Flutter. Последний так к тому же вообще-то пока полный opensource, а за использование Qt+QML в коммерции требуют дорогие лицензии.
Извините, но я не могу часто отвечать.
Мне школота на Хабре давно рейтинг понизила за мой стёб над их нежно любимым Питоном и прочим откровенным Ховном для школьников, админов и домохозяек, которое зачем-то пихают теперь в каждый чайник. А писать статьи и играть по идиотским рейтинговым правилам Хабра мне некогда - работы много.
Поэтому, всего хорошего. А вы присмотритесь к Flutter+Dart - лично по-моему у него есть хороший потенциал в качестве замены богомерзкого HTML+JS фронтенда.
Всего!
Это ещё почему?!
Лет ~16 тому назад я даже реализовывал похожую логику работы на древних Delphi. Причём, мы делали свой собственный вариант Task-ов поверх собственного же пула потоков. И даже собственно похожую логику типа async/await там делали, но сложно-извращенным способом.
К слову, на тот момент async/await даже в тот же C# ещё не завезли.
Но когда я уже позже увидел те же идеи уже на уровне языка через async/await то был сильно удивлён и обрадован, что наконец-то это появилось в такой простой форме.
Поэтому, если лично вам не надо - то это возможно лично ваши проблемы с пониманием нового и действительно полезного.
Чего вам прогрессивнее? Си-подобный синтакис сейчас стандарт де факто для большинства новых языков. И для большинства программистов он крайне привычен. И как раз хорошо, что не отличается диаметрально, поскольку с тех же майнстримовых Java/С# будет проще перелезть.
Или вам Питоные извраты с обязательными отступами нравятся больше? ;)
Тогда вы и должны понимать, что это есть хорошо.
Это не совсем библиотека виджетов. Это скорее соврменный декларативный подход к интерфейсу, на манер того же QML,
где вы сами вольны очень легко создавать свои собственные виджеты на основе богатой библиотеки графических примитивов.
Это подход не такой простой как классическое формашлёпство a-la Delphi/Lazarus/C#+WinForms, но зато по сути ни в чём вас не ограничивает в плане стиля и дизайна и никак не привязан к контролам самой операционки (как древний VCL)
Ну а третьи фирмы и интузиасты как всегда накидают вам готовых виджетов по самое нехочу.
В случае ВЕБ-а это практически ровно тоже, что предлагает подход через WebAssembly от многих конкурентов.
Если вам нужно приложение, с равнозначной мордой в WEB для какого-то заказчика, который почему-то чистый десктоп "так не любит, что даже кушать не может" (tm), то это как раз очень хороший и оптимальный подход.
А вот если заказчику, нужно не приложение - а ВЕБ-сайт или ВЕБ-магазин и т.п., то это уже другая задача и должна решаться другими инструментами - ручки и блокнот / Adobe Dreamweaver / Готовые движки типа WorldPress и т.п.
В Dart массивы и списки объеденены в понятие generic List.
Они могут быть как расширяемыми так и константными.
За производительность не скажу. Скоро (через пару недель) сам буду прогонять реальные серьёзные тесты на Dart. Скорее всего, sсimark2 для начала. Самому интересно, какие результаты покажет финальный exe-шник.
Я вам больше скажу. Там ещё и типа byte как такового нет. Эффективная работа с отдельными байтами только через библиотеку.
НО лично я пока рассматриваю Flutter+Dart как хорошую возможность закрыть мобильное направление и ВЕБ-морду. Поэтому, мне там супер-скорость чистого незамутнённого С++ вряд ли нужна.
А вот буду ли переносить какой-нибудь следующий десктоп на это - как раз и покажут реальные тесты и прочие оценки.
НО в любом случае мне это уже больше нравится в рамках моего проекта, чем Qt+QML по целому ряду параметров.
Многообещающего там много, например:
Dart - язык не очень сложный, при этом современный, безопасный (с автоматической сборкой мусора), со строгой статической типизацией, с async/await шаблонами и т.п.
Синтаксис Си-подобный - напоминает Java, C#, даже C++ ( в плане вызова инициализаторов в конструкторах ).
Изначально задумывался как более эффективная замена JS, но по мере развития и вместе с библиотекой Flutter уже перерос в нечто существенно большее.
Есть свои "тараканы" (странности), как, например, своеобразный подход к модификаторам доступа и т.п., но в целом от лидеров жанра мало чем отличается и очень быстро развивается.
Для десктопа Flutter+Dart использует Ahead-of-Time (AOT) компиляцию в целевой найтивный код и порождает один найтивный исполняемый файл для целевой платформы (в случае с Win - EXE-шник), без тонн библиотек как, например, Qt. Для мобилок тоже самое - в случае Android стандартный apk.
Для всех платформ используется один и тот же собственный способ отрисовки поверх библиотеки SKIA, которая в свою очередь работает поверх OpenGL / Vulkan.
Платформенные или сторонние библиотеки виджетов (типа Qt, GTK) не используются, поэтому отображение одинаково на всех платформах.
Для случая ВЕБ это компилируется в оптимизированный JS, а отрисовка идёт через SKIA на Canvas. Для индексации поисковыми машинами такой ВЕБ не годится, но с другой стороны это и рассчитано на приложения, а не на сайты.
TypeScipt просто чуть меньше воняет, чем сам JS, да то лишь на этапе написания.
Но по сути это тоже самое JS скрипто-ложество поверх Хромиума, как вы и написали, вместо нормального оптимизированного найтивного кода.
Кому вообще нужен т.н. фронтенд, если можно было бы за то же время создать несколько клиентских десктопов, работающих и выглядящих одинаково на всех операционках?
Flutter+Dart - вот действительно многообещающий проект, который способен дать пинка всем фронтендным скрипто-кодерам.
Qt+QML - тоже не плохо, но требуют знакомства с C++, что для "мамкиных кодеров" будет сложновато.
Ну а по цифрам:
VS Code только стартует без проекта и тут же выжирает на моём ПК ~900 Мбайт
На этом фоне Lazarus стартует с открытым большим проектом и потребляет всего 55 Мбайт (сама среда написана на том же FPC).
Как говорится, комментарии излишни )))
Закономерности-то простые:
- VS Code - написано на TypeScript, JavaScript, HTML, CSS
- Microsoft Teams - написано на TypeScript, Angular, React
- Discord - написано на TypeScript (with ReactDiscord)
Прекратите писать приложения на скриптовом JS Ховне со скриптовыми библиотеками,
вернитесь к Си / C++ / Objective-c / ObjectPascal. Либо развивайте такие языки как D и т.п.
И будут тогда ваши приложения летать и при этом потреблять килобайты вместо гигабайт.
НО только для этого нужно будет послать в #опу все мега-Хениальные "идеи" от эФФФективных мЭЭЭнеджеров, а "мамкиных кодеров" не брать на работы, а отправлять после школы учиться в университеты.
А вот как это сделать при главенствующем тупом подходе, который формулируется как "всё должно было сделано ещё вчера, а-то у меня диаграммы Ганта будут некрасивые" (tm) - кто бы знал? )))
Это якобы "типовое занудство" было испокон создания языков программирования.
Тупо потому, что на базовом уровне железа процессор как минимум только примитивными типами - машинно-разрядными integer, double (а в древние времена и без double) и ещё машинно разрядными указателями и оперирует.
А когда вы добавляете любую динамику, то она тут же тянет за собой необходимость отдельного сохранения доп. данных, их проверки и косвенного вызова некоторых лишних процедур для понимания с чем собственно мы имеем сейчас дело - а это всё лишнее время, время, время, которое суммируется в достаточно большие задержки.
Вообще, IMHO сейчас, к большому сожалению, народилось уже целое взрослое поколение т.н. "программистов", которые вообще крайне слабо себе представляют как именно работает конечный машинный код на процессорах (причём не важно на какой архитектуре - на x86/64 ли, на ARM ли, на другой ли).
В основном это самоучки со стороны, без профильного образования, въехавшие каким-то боком в профессию на волне IT-бума тупо за деньгой. И львиная доля из них как раз и есть мамкины скрипто-кодеры на JS или Питоне, но так же и часть Жабистов, C-Шарпистов и т.п.
Иногда из общения с такими "профессионалами" просто диву даёшься, какую чушь они несут на собеседованиях или пишут в свои блогах.
Это похоже на такой же ужас, как если бы ваш лечаший врач никогда не изучал основы органической химии, биологии, анатомии, и не проходил интернатуру, а так по быстрому нахватался бы знаний из пары книг и советов от друзей, и приступил бы к вашему лечению )))
Может быть на сотом пациенте он бы чего-то бы и понял, почитал бы и глубже поучил бы, но первые минимум сто (включая вас) точно бы лежали уже в деревянных ящиках.
Ребята из университетов хотя бы сначала базовую школу булевой алгебры, алгоритмов, архитектур, ассемблеров, C/C++, операционок, синтаксически анализаторов и т.п. так или иначе проходят, а уже потом пересаживаются на тот же JS при насущной необходимости.
А вот причина стремительного взлёта полно-динамического скриптинга типа JS только одна - это идея быстрого кроссплатформенного ВЕБ-мордошлёпства, а вовсе не удобства сплошной динамики без статики.
Эта идея, во-первых, очень понравилась т.н. "эффективным менеджерам" на рубеже 2000-х,
а во-вторых, надо признать, что на рубеже 2000-х и последующие лет ~15 хороших альтернатив-то почти и не было.
С++Qt был достаточно сложен, и долгое время покрывал только десктоп. Да и сам современный С++ слишком заковырист и опасен для большинства описанных выше "мамкиных кодеров" без хорошего образования и большого опыта разработки.
QML же деятели из Qt запустили уже существенно позже.
Многочисленные Java фреймворки тормозили нещадно и особой красотой не обладали. А JavaFX тоже уже позже стартанул, но как-то до сих пор особо и не взлетел.
C# был долгое время без кроссплатформы, а десктоповый GUI у них и до сих пор без кроссплатформы без сторонних решений. Ну а с Вебом у MS вечная чехорда, то чистый ASP.NET, то Razor, то Blazor, завтра ещё что-нибудь.
Borland Kylix забросил по причине убытков. Embarcadero со своим мега-глючным FMX тоже делала все как будто нехотя и медленно, хотя кто-то сейчас мобилки уже и на этом пишет. И между прочим, вроде бы древний и замшелый Delphi/Object Pascal сейчас на 10-м месте в рейтинге TIOBE.
А в это время и на этом фоне с начала 2000-х "мамкины кодеры" очень быстро могли осваивать ВЕБ и JS и это было относительно безопасно для производственного процесса и очень выгодно для т.н. эффективных мЭ-Э-Энеджеров.
Сейчас есть надежда, что, например, благодаря денежным вливаниям серьёзно взлетит такой фреймворк(язык) как Flutter(Dart) для красивого, современного, безопасного, кроссплатформенного и производительного мордошлёпства (включая и идентичную отрисовку в Веб поверх Canvas).
А может появится что-то ещё лучше этого. Короче, "будем посмотреть" (tm)...
НО если проект Flutter+Dart стараниями Google взлетит, то тогда велика вероятность, что HTML+JS погонят SSаными тряпками из кросплатформенного мордошлёпства и тем более с серверов туда, где ему изначально самое место - на поддержку динамики ВЕБ-сайтов.
Но пока здесь ключевое слово - #если ))
На Qt с их QML надежды не много. Да, там очень хорошее конечное быстродействие и очень объёмная библиотека, но как ни крути без знания C++ всё равно соваться не желательно, что как бы уже повышает порог вхождения.
Ну а Delphi/Lazarus (Object Pascal) при всём моём глубочайшем уважении, какой там фреймворк уже не прикрути, уже вряд ли снова станет майнстримом.
Слишком уж архаичен синтаксис. Много чисто исторических затычек из разряда "так уж повелось" и т.п.
ХОТЯ В НЕКОТОРЫХ НИШАХ ОН ПО ПРЕЖНЕМУ ХОРОШ, поскольку при грамотном использовании даёт быстродействие найтивного кода сравнимое с Си/C++ при гораздо меньшей вероятности выстрелить самому себе в ногу.
JS рождался как срипт на коленке для придания динамичности статичному HTML.
Кто тогда в Netscape думал, что это скриптовое простенькое Ховно (на момент создания) будет когда-то всерьёз использоваться для серьёзной разработки интерфейсов или тем более на серверах?!
Но беда в том, что в погоне за дешевыми кодерами (даже без профильного образования) и веб-кросплатформенностью т.н. "эффективные мЭЭнеджеры" сделали ставку на веб-мординг - ну и понеслась.
С другой стороны чистый Pascal язык сугубо академический. На нём почти ничего массово не писали.
Тот Pascal которым до сих пор пользуются - это Object Pascal (Delphi / Lazarus).
А в ObjectPascal как раз испокон веков для удобства хранения любых типов есть динамический тип данных Variant .Этот тип по реализации несколько отличается от dynamic в C# или Dart, и по скорости работы конечного кода чуть более эффективен.
НО при его использовании тоже запросто словить ошибку времени выполнения.
varV1, V2, V3: Variant;
begin
V1 := 'aaa';
V2 := 1;
V3 := V1 + V2; // Здесь будет EVariantError во время исполнения
...Другое дело, что в таких языках как ObjectPascal объявляя переменную как Variant вы как бы понимаете зачем вы это делаете, а значит и осознаёте свою ответственность.
Тогда как в скриптовых и изначально динамических убожествах типа JS у вас просто нет выбора.
А когда в больших проектах на JS осознали "масштаб трагедии", то и стали прикручивать и продвигать всякие костыли типа TypeScript.
Кстати, хорошо хоть Google сейчас активно пытается исправить часть бед динамических скрипто-убожеств, активно продвигая такие языки и opensource библиотеки со строгой статической типизацией как Go или Dart (Flutter).
Ваши замечательные красивые потуги на FMX, к сожалению, уже не смогут переломить общей тенденции угасания интереса к Паскалю и к Delphi. Молодежь практически уже не смотрит в эту строну.
Я-то ещё, кстати, использую FPC в реальной работе, но в основном уже только как быстрый и самодостаточный кросс-платформенный бэкенд.
Дельфи всё ещё пытаются втюхать за дорого, что почти никому кроме поддержки legacy-проектов уже не нужно.
А вот FPC и Lazarus как opensource на этом фоне очень даже неплохи. Для создания небольших кросс платформенных десктопных программ и утилит с GUI подходят на ура.
Скорость конечного кода на уровне GCC. Всякие питоновские скриптовые убогости там и рядом не стояли. При этом вероятность ошибиться и выстрелить себе в ногу на порядок меньше чем на C++.
Но это уже не мэйнстрим. А в корпоративной среде вообще с большим натягом применимо, поскольку WEB-интерфейсы только через одно место, и никаких тебе тонн готовых кирпичей и библиотек на каждый случай.
Да даже и классические десктопные интерфейсы уже кажутся слегка устаревшими на фоне всяких там QML или WEB-движков прикрученных к дестопу.
Ну и среди миллениалов и более поздних поколений с сырой памятью и указателями (при необходимости) умеют работать уже только единицы, т.е. не вчерашние "грузчики", решившие вдруг податься в программисты из-за денег, а те кто на эту специальность в университетах учился. Но в университетах "эти ваши" Паскали уже больше не изучают. Из низкоуровневых в основном только С и C++. Поэтому, какой бы ни был хороший, современный и удобный компилятор с Паскаля - это уже по любому экзотика.
Ко всему прочему, в связи с вышесказанным уже почти не найти специалистов на Delphi / Lazarus(FPC).
И поэтому т.н. эФФФективные мЭЭЭнэджеры (т.е. обычные тупые управленцы, которые сами обычно ни в чём кроме диаграмм Ганта и графиков доходов толком не разбираются) уже крайне боятся проектов на этом языке.
Очень долгое время сотрудничал с парой европейских контор по производству программно-аппаратных комплексов - нет и не было там никаких бизнес-аналитиков. Иженеры сами объясняли программистам, программисты сами дергали инженеров. Клиенты общались и передавали свои хотелки через обслуживающий персонал, через сайт, и в редких случаях напрямую с инженерами. Руководство полагалось на мнения и решения ведущего инженера и руководителя разработки.
После начала СВО вынужден был начать сотрудничать с российской конторой.
Куча каких-то бизнес-аналитиков на всех этапах, которые по большому счету не нужны от слова совсем. Они лишь поверхностно вникают в производственный процесс, как правило не имею никакого профильного образования и программировать сами не умеют. По сути они лишь выступают в роли испорченного телефона и частично стенографиста. Почти любой вопрос гораздо проще и быстрее решить напрямую без их участия. И это не говоря ещё о куче каких-то почти полностью бесполезных менеджеров и промежуточных начальников.
При этом везде какие-то бюрократические барьеры на пустом месте, которые походу существуют лишь за тем, чтобы кормить эту кучу почти абсолютно бесполезных для дела трутней.
Все IMHO просто.
Например, в 90-е большими зарплатами (а не наворованными суммами) могли похвастаться в основном экономисты и юристы. В те времена экономические факультеты и курсы штамповали сотни тысяч бесконечно пафосных и претенциозно-амбициозных экономистов и мЭнЭджеров, которые при этом подчас даже после ВУЗа не могли правильно подсчитать элементарные проценты (сам неоднократно сталкивался), а по знаниях реального учета уступали порой даже младшему бухгалтеру. НО были убеждены в свой бесконечной значимости и требовали больших зарплат. И что характерно, часто получали желаемое. Такие были времена.
Сейчас платят хорошие деньги в IT. Поэтому-то большое количество лезет в эту сферу вовсе не по призванию и даже не по способностям, а тупо по меркантильному интересу.
Лично у меня высшее техническое - инженер-системотехник. И программирование как таковое (тогда это были (Си/C++/Pascal/Fort/Lisp/Разные ассемблеры и т.п.) - это было лишь одним из камней в системе обучения. Как условная биология или химия в обучении медиков.
А кроме этого чего только не изучали. Даже собственные процессоры проектировали.
НО как раз тогда-то кроме сис.админов или программистов по тупому складскому и бух.учёту, и при чем порой на довольно скромной зарплате (по сравнению даже с продажниками), особенно никто и не нужен был. И поэтому в профессии куда больше было людей именно по призванию, даже если и без высшего образования.
Я недавно поучаствовал в собеседовании со стороны как бы работодателя и насмотрелся на горе-кандидатов. В основном какие-то пафосные заготовленные пузыри про SOLID, МVVC, dependancy injection и т.д. и т.п., НО тупо приостановишь этот пафос и спросишь что-нибудь совсем простое типа, а зачем нужен абстрактный класс или какие вы знаете методы сортировки или что будет с целым числом после поразрядного сдвига влево/вправо, или что-нибудь про отличие стека от кучи, или просьба упростить булево выражение, ... - и всё - сразу видно, что никаких даже элементарных базовых знаний там и нет.
И IMHO глупость ситуации ещё в том, что частенько между нанимающей стороной и работодателем лежит прослойка в виде молоденьких дурочек/дурачков из HR, которые сами-то нифига особо в этом не понимают, но так же проставляют "обязательные" галочки на всякие там SOLID, MVVC и т.п., вот кандидаты и несут потом все как один эти зазубренные без особого понимания термины.
На мой IMHO ~80% ломящихся сейчас в IT вообще не математического, не логического и даже не технического склада ума. То ли родители отправили учиться (потому как это модно и денежно), то ли сам решил сменить карьеру неудачного повора (условно) на "удачного" программиста так же тупо из-за денег, и т.п.
Одно тут радует, что пока такое в гораздо меньшей степени возможно в нашей медицине.
А иначе к врачам было бы ходить просто страшно и лучше было бы тогда делать даже сложные операции на сердце у деревенской бабки.
Если вы даете на любом серьезном ресурсе право выборного голосования безмозглой школоте или толпе, то ваш ресурс быстро и превращается в тусовочку для безмозглой школоты.
Даню Милохина сюда пригласите писать посты и комменты - он тут первым IT специалистом уже через неделю станет, поскольку тупая школота накончает ему плюсиков в комменты по любому :D
И все эти алгоритмы написаны на С++. А ты вообще-то не юзер, а девелопер.
Шаг влево, шаг вправо - ой а мне вдруг нужно какой-нибудь свой алгоритм на матрицах просчитать. И что? Будешь ждать пока взрослые, умные дяденьки для тебя этот алгоритм запилят или довольствоваться пока в 2-е 3-е меньшей производительностью?
Да и вообще профессиональному девелоперу в этой индустрии не знать С++ уже странно. Другое дело, что Unity изначально и нацеливался не на профессионалов индустрии, а на дизайнеров одиночек и на мелкие т.н. инди-команды, где вместо программистов с дипломом зачастую один-два школьника на подхвате.
Я не игродел. Но в силу своей специфики прекрасно знаю насколько хреново оптимизируется конечный код c MSIL в сравнении с C++, не говоря даже про объективные тормоза сборщика мусора и т.п. А вот в конторе с которой периодически моя фирма сотрудничает есть два парня работающих с UE. Они там делают очень специфические вещи по интерактивной визуализации некоторых физических процессов. И там чистой счетной матетематики, а не просто логики хоть отбавляй. А значит если нужно считать это быстро, то без хорошей оптимизации на C++ не обойтись. И кстати один из них тоже рассказывал, что начинал в студенчестве с Unity, но позже переполз на UE.
Да и мне-то все равно, на чем вы там свои поделки делаете. Но говорить о том что С++ это прошлый век, когда у вас даже сам Unity-движок безальтернативно на этом С++ и написан - это какие-то детские глупости про розовые пони.
Прошлый, прошлый. Только вот беда, что одни и те же несложные алгоритмы на С++ даже без особых танцев с бубном и оптимизации на SSE/AVX и то выполняются порой в разы быстрее, чем на C#. SciMark вам в помощь для осознания сего факта.
А C# я тоже очень люблю в офисных и даже в инженерных поделках. Один только LINQ to Object экономит массу времени в написании рутинного перемалывания данных.
Но все же не место этой удобной мэнеджет погремушке в высокопроизводительном коде. И напрасно Unity на радость школоте его как скрипт прикрутили. UE на этом паровозе им не догнать.
И на какие только извращения не идут любители офисных мэнэджет-песочниц, чтобы не учить C++ :D
С одной стороны «эффективные менеджеры»(tm), коим часто по образованию по-хорошему нужно торговать помидорами на рынке, бойко крича, демпингуя и отбивая себе место под солнцем среди кавказских торговцев в кепке.
С другой стороны, приблизительно такие же по уровню «программисты»-самоучки сразу после школы/колледжа или месячных курсов примитивного жаба-скрипта с отточенным навыком и умением гуглить, какую именно жаба-скрипт библиотеку нужно молниеносно закачать для решения той или иной проблемы (конечно, если такая библиотека уже есть).
Все это сливается в банду aka команду и бежит на фрилансовые площадки отбивать себе место под солнцем, бойко конкурируя с индусами в чалмах, работающими за еду, и стремиться выполнять аж по 10 контрактов в месяц!
И как при этом люди в компаниях годами и десятилетиями выпускают, развивают и совершенствуют один и тот же продукт?!
Наверное, у них просто нет таких чудесных «эффективных менеджеров» и замечательных и реактивных «жаба-скрипт исполнителей».
И, наверное, это к счастью :)
На худой конец уже давно как появился WebAssembly.
Не так здесь то, что во времена моей учебы программазмом и схемотехникой в основном занимались те, кому это было реально интересно. Поэтому, на выходе из ВУЗов как правило уже получались специалисты весьма высокого уровня и хорошо знающие основы. А шелуха типа зубрежки языков или переключение между ними в зависимости от задачи была как бы немного вторична.
А карьеристы за зарплатой тогда шли в Финэк или на юридические факультеты. И приблизительно так же обсуждали, что бы им по-быстрому и попроще поучить, чтобы в блатную конторку на хорошую зарплату пристроиться.
А теперь все перевернулось наоборот :)
> А кто говорит, что вы что-то делаете не так?
Вы иронию понимаете? ;)
> Просто у вас необычный случай… и ваша зарплата за этот стек…
Необычный случай? Зарплата за Стек? Что вы несете?
Классическое найтивное программирование вдруг стало чем-то необычным?
А платят теперь за понятие «стек технологий» (так любимое эффективными менеджерами) а не за результат, здравый смысл и возможность писать быстрые программы без каких-либо ненужных прослоек?
Давайте я объяснюсь.
Я уже писал как-то в другой теме, что вот включаю я свой персональный компьютер и не вижу там ни одной хоть сколько бы серьезной и нужной мне программы, написанной на javascript-е. И уж тем более ни одной на Питоне. А ведь последний чуть ли не в лидерах должен быть по количеству шума вокруг него в последние годы.
Но я ничего не вижу на десктопе и из лидеров данного конкретного списка. За исключением разве что Objective-C (но я не вижу и Objective-C, поскольку в моей области деятельности Маки нафиг никому не нужны).
Да у меня даже и на C#-то на десктопе днем с огнем ничего не сыщешь (кроме разве что каких-то мелочей от самой MS). Хотя, казалось бы, это-то должно бы давно уже появиться.
Все графические редакторы, все инженерные и математические пакеты, весь 3D, все нужные мне офисы и бухгалтерии, все системные утилиты и прочие интрументы для работы, все это либо C++, либо в том числе и Delphi (Delphi в моем случае это AIMP, утилиты Auslogics и хелпмэйкер HelpNDoc, пару хороших утилит для Баз-данных включая DBWorkbench, сборщик FinalBuilder и шикарный но дорогой автотестер TestComplete ). И просто поверьте, что я не выбираю программное обеспечение по принципу на чем это сделано.
И только не нужно мне рассказывать, что это мол де десктоп, а вот у нас мол в корпоративе все крутится на серверном скриптике «A» под библиотечкой «B» с прикрученными справа и слева пакетами «C» и «D», а визуализируется на HTML страничках под нехилым набором из новомодненьких библиотек E, F, G (набор которых чуть ли не каждые пару-тройку лет меняются).
И изначально все это было задумано вашими «эффективными менеджерами», чтобы ускорить и упростить.
Только на деле чаще всего выходит, что на создание и отладку всего этого времени уходит не меньше, а то и больше, чем на написание быстрого десктопа и серверной части сразу под конкретные платформы (естественно, кроме самих серверов и баз данных). А хуже то, что постоянная изменчивость и нестабильность вышеперечисленных «стеков», помноженная на нестройность и не строгость скриптовых технологий, еще раз помноженная на слабую компетентность непрофильных специалистов и четвертый раз помноженное на естественные скриптовые тормоза никак в результате не приводит к заветному для «эффективных менеджеров» удешевлению и упрощению.
Да и в результате чаще всего мы видим лишь очередную эмуляцию десктопа в Браузере, поскольку все html красивоти для серьезной работы как бы нафиг не нужны. Ну и не факт, что это вообще будет работать через пару лет при смене браузера и поколения скриптового движка.
При этом я вовсе не умаляю существенную значимость того же javascript-а в сайтостроительстве.
Хотя по размерам кода современных сайтов IMHO на таком изначальном убожестве это писать уже опасно. Недаром и появляются обертки типа typescript-ов
> При итоговом выборе вступают еще и другие критерии, как, например, количество людей на рынке труда могущих, и главное желающих с ним работать, чтобы потом было кому поддерживать и развивать это всё.
Ну вы же, думаю, не надеетесь, что что-либо из вышеперечисленных мной серьезных пакетов будет вдруг непонятно зачем переписано на какую-нибудь Скалу или Го лишь мимолетной моды ради?
Или тем более на скриптовые тормоза?
А главное зачем?! Чтобы нанять якобы дешевых спецов? См.выше. Да и по факту спецы эти уже не дешевы.
А теперь давайте более предметно и прагматично.
Вот нужны десктопные морды с небольшими мобильными довесками.
В силу задач (управление промышленными контроллерами) на десктопе желательно иметь возможность быстро спускаться до низкоуровневого программирования и время отклика должно быть минимален по возможности. Т.е. желателен быстрый найтив.
C# и вообще менеджет подход не желателен (к тому же часть все равно придется писать на найтиве).
Ну, например, можно и на С++Qt, благо опыт есть.
Но оказывается, что и современный Дельфи совсем не плох.
Интерфейсная часть накидывается элементарно и относительно быстро. А при использовании FMX теперь можно это замутить хоть даже и под Линукс. А вся подноготная часть пишется одинаково просто хоть на прикладном уровне, хоть на уровне прямого доступа к памяти и даже ассемблера и с почти бесшовным склеиванием с СОМ и низкоуровневым API на любой поддерживаемой платформе. При этом вероятность выстрелить себе в ногу при написании рутинной части все же существенно меньше, чем на C++.
Специалистов на просторах СНГ полно, да и за пределами есть. И это уже чаще именно специалисты, а не ничего не знающие пока толком школьники, которые лишь мечтают вызубрить (именно вызубрить) какую-то очередную новомодную фенечку ради заветной большой зарплаты.
Но только даже на моих глазах таких фенечек с 90-х уже куча промелькнула и пропала в никуда.
И знаете, я бы все понял, если бы в этих списках новомодных и хорошо-оплачиваемых языков, появлялись бы такие вещи как язык «D». И не только появлялись, но и выходили бы хорошие IDE, а сторонние фирмы наперебой клепали бы инфраструктуру и компоненты для этого.
Но вместо этого лишь куча таких же как и «D» многообещающих, но бесплодных выстрелов.
Ну или если бы C# на найтив перевели с возможностью прямого доступа к пямяти и ее очистки по желанию и т.п.( а ведь грозились когда-то).
А вместо этого MS лишь мечутся как Г в проруби и регулярно кидают своих адептов.
И вот на этом фоне Дельфи или даже Лазарь на найтиве выглядят весьма даже неплохо и развиваются вполне предсказуемо и стабильно. Не говоря уже о конечном результате в виде единственного запускаемого файла, который стабильно, быстро и совершенно не прожорливо пашет потом годами и ему как и Си-шному найтиву очень долго потом плевать и на смену операционок, и от смен прослоек он тоже не зависит.
Поэтому, если я могу к счастью выбрать сам, не опираясь на мнения «эффективных менеджеров» (ака недоучек из экономических колледжей) и не на мнение тинейджеров без профильного образования, то выходит, что и Дельфи живее всех живых, да еще и мобильные довески делать позволяет опираясь практически ровно на тот же код.
А платят мне и напарнику за конечный результат, а не зарплату. Поэтому, и сумма в среднем большая выходит.