Это как посмотреть. Паскаля нет уже давно, есть Object Pascal (Delphi / Lazarus). По уровню новомодного синтаксического сахара и всеобъемлемости библиотек C# конечно же опережает обе эти реализации ObjectPascal-я.
Но иногда важен результат, а не синтаксис или синтаксический "сахар". Например, в случае с Lazarus - в результате получаем компактный по современным понятиям полностью автономный, найтивный и неплохо оптимизированный исполняемый файл, потребляющий минимум памяти и вообще в принципе не тормозящий на сборе мусора, как под все основные десктопные так и под некоторые встраиваемые платформы. Если грамотно писать тоже самое на С++, то скорость работы конечного кода может быть ещё быстрее (в среднем от 20-30 процентов), но и вероятность выстрелить себе в ногу, а соответственно и время на разработку и отладку сильно возрастают, как и требования к квалификации программистов. Поэтому, ObjectPascal до сих пор очень даже хорош в некоторых направлениях. А лично мне поддержка проектов на ObjectPascal до сих пор приносит больше прибыли, чем что-либо ещё.
С другой стороны, писать на ObjectPascal сейчас что-то кроме специфичного десктопа или быстрого и непрожорливого бэкенда на мой взгляд, как минимум, не разумно. Даже не смотря на наличие FMX в современном Delphi.
Я в программировании очень давно, основные майнстримовые языки типа Cи/С++/C# знаю очень хорошо.И это не считая того, что начинал вообще на Fortran в ВЦ, и писал когда-то в том числе и на Ассемблере, и на Lisp, и на Forth, и на VB, и на Java. Кстати, Intel компиляторы с Fortran до сих пор порождают самый быстрый код для вычислений.
И поэтому мне на эти рейтинги вообще положить с прибором. На них у нас в основном смотрят лишь "бегущие за зарплатой"
Например, сейчас для нового небольшого проекта сделал ставку на Flutter + Dart в том числе и для десктопа, ВЕБа и мобилок (в TIOBE Dart даже в 20-ку не входит). Хотя, на десктопе найтивный релизный код Dart работает по факту ~ в 7 раз медленнее того же ObjectPascal или C# (мы проводили тесты), не говоря уже о крайне неудобной работе с "изолейтами" в Dart по сравнению с обычными потоками и т.д. и т.п. НО по факту интерфейс получается красивый, современный, везде одинаковый, с богомерзким JS почти не нужно сталкиваться самостоятельно (полностью переводит всё в JS для ВЕБ) и т.п. А вот сервер решил оставить на Лазаре (быстро, компактно, не прожорливо, и работает даже на "утюге").
Итог: 1. Каждая технология бывает хороша по своему. 2. Многие якобы "древние" языки и технологии ещё дают фору современным в определённых нишах. 3. Все эти рейтинги нужны лишь ради рейтингов. В основном на них ориентируются лишь тупые мЭ-Э-Э-неджеры и новички в поисках зарплат. Но ориентируясь только на это можно и сильно пролететь как, например, с Adobe Flash => Старайтесь освоить несколько языков и технологий, тем самым диверсифицируя свои знания.
Есть подозрение, в свете других событий, что всё делается намерено. В ГосдуРе призывают запретить ИП и самозанятость. Похоже, что зажравшиеся "бояре", чтобы компенсировать огромные дыры в бюджете и сохранить себе возможность закупки "золотых унитазов", хотят в очередной раз прихлопнуть текущий "НЭП" и сделать что-то типа new-идустриализации с некой формой нео-крепостного права.
Просто тогда миллионы людей потеряют возможность заработка и возможность работы на самого для себя, а не на богатого дядю, и вынуждены будут пойти на "заводы и стройки" (условно) или в большие корпорации, где за миску похлёбки вместо мигрантов класть кирпичи, точить болванки и шить говн@давы, и писать "православнутый" и одобренный код. Т.е. по сути как раз это и будет new-барщина.
Ну а сверху ещё накроют это цифровым Гулагом, где можно смотреть и слушать только то, что нужно и можно - т.е. как какой-нибудь очередной идеологически-правильный "Шаман" поёт "Славься, славься, наш русский царь!" для ботоксного самодура, а оплаченные пропаг@ноны будут рассказывать, какие все вокруг России сволочи и только здесь самая скрепно-православная правдушка...
Наверху как обычно у нас в большом количестве сидят прибившиеся к сытному корыту трутни, которым, судя по всему, наплевать на всё и на всех, лишь бы остаться у этого корыта. Они так же щедро оплачивают и всяческих пропаг@ндонов, которые несут порой полную чушь или тупые лозунги.
То, что рекламу для ряда мелкого бизнеса убили закрыв Инст@грам - им глубоко фиолетово
То, что инженеры и IT-шники (которые им якобы нужны) часто уже не могут через YouTube смотреть обучающие или профильные видео - им глубоко фиолетово
То, что сами иностранные компании (как яркий пример, Intel) закрылись от российских адресов и без VPN из России никакой тех.информации не получить - им положить с прибором
То, что никто из зарубежных партнеров (у кого ещё остались деловые контакты) не будет с вами общаться по MAX - им положить с прибором.
Ради сохранения собственного доступа к корыту, и для агрессивной поддержки местных крупных корпораций они готовы заблокировать вообще всё - им на обычных людей или на мелкий бизнес вообще наср@ть.
Нострадамлю, что рано или поздно они прикроют и GitHub и прочие source-хранилища. Благостную причину для сидящих у зомбоящика дураков конечно же найдут, но основной причиной будет то, чтобы максимально ограничить доступ к открытым технологиям для масс.
Чтобы только гос.компании могли беспрепятственно использовать opensource, приклеивать к нему свои ярлыки и продавать за дорого на внутреннем закрытом рынке как якобы свои же разработки.
Второй месяц уже ковыряю 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) - кто бы знал? )))
Ваши замечательные красивые потуги на 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 контрактов в месяц!
И как при этом люди в компаниях годами и десятилетиями выпускают, развивают и совершенствуют один и тот же продукт?!
Наверное, у них просто нет таких чудесных «эффективных менеджеров» и замечательных и реактивных «жаба-скрипт исполнителей».
И, наверное, это к счастью :)
На Delphi, FMX у вас не получится запустить это так просто под ВЕБ ( На Flutter - без проблем).
На Delphi уже не найдёте молодую перспективную команду ( только старых пердунов (40-50)+ )
FMX лично я гонял начиная ещё с XE2 ( судя по собственному опыту и форумам - как было очень много багов так и осталось )
Скорость развития Flutter благодаря поддержке и большим фин.вливаниям Google дадут нехилую фору Delphi.
Это как посмотреть.
Паскаля нет уже давно, есть Object Pascal (Delphi / Lazarus).
По уровню новомодного синтаксического сахара и всеобъемлемости библиотек C# конечно же опережает обе эти реализации ObjectPascal-я.
Но иногда важен результат, а не синтаксис или синтаксический "сахар".
Например, в случае с Lazarus - в результате получаем компактный по современным понятиям полностью автономный, найтивный и неплохо оптимизированный исполняемый файл, потребляющий минимум памяти и вообще в принципе не тормозящий на сборе мусора, как под все основные десктопные так и под некоторые встраиваемые платформы.
Если грамотно писать тоже самое на С++, то скорость работы конечного кода может быть ещё быстрее (в среднем от 20-30 процентов), но и вероятность выстрелить себе в ногу, а соответственно и время на разработку и отладку сильно возрастают, как и требования к квалификации программистов.
Поэтому, ObjectPascal до сих пор очень даже хорош в некоторых направлениях.
А лично мне поддержка проектов на ObjectPascal до сих пор приносит больше прибыли, чем что-либо ещё.
С другой стороны, писать на ObjectPascal сейчас что-то кроме специфичного десктопа или быстрого и непрожорливого бэкенда на мой взгляд, как минимум, не разумно. Даже не смотря на наличие FMX в современном Delphi.
Я в программировании очень давно, основные майнстримовые языки типа Cи/С++/C# знаю очень хорошо.И это не считая того, что начинал вообще на Fortran в ВЦ, и писал когда-то в том числе и на Ассемблере, и на Lisp, и на Forth, и на VB, и на Java.
Кстати, Intel компиляторы с Fortran до сих пор порождают самый быстрый код для вычислений.
И поэтому мне на эти рейтинги вообще положить с прибором.
На них у нас в основном смотрят лишь "бегущие за зарплатой"
Например, сейчас для нового небольшого проекта сделал ставку на Flutter + Dart в том числе и для десктопа, ВЕБа и мобилок (в TIOBE Dart даже в 20-ку не входит).
Хотя, на десктопе найтивный релизный код Dart работает по факту ~ в 7 раз медленнее того же ObjectPascal или C# (мы проводили тесты), не говоря уже о крайне неудобной работе с "изолейтами" в Dart по сравнению с обычными потоками и т.д. и т.п.
НО по факту интерфейс получается красивый, современный, везде одинаковый, с богомерзким JS почти не нужно сталкиваться самостоятельно (полностью переводит всё в JS для ВЕБ) и т.п.
А вот сервер решил оставить на Лазаре (быстро, компактно, не прожорливо, и работает даже на "утюге").
Итог:
1. Каждая технология бывает хороша по своему.
2. Многие якобы "древние" языки и технологии ещё дают фору современным в определённых нишах.
3. Все эти рейтинги нужны лишь ради рейтингов. В основном на них ориентируются лишь тупые мЭ-Э-Э-неджеры и новички в поисках зарплат. Но ориентируясь только на это можно и сильно пролететь как, например, с Adobe Flash
=> Старайтесь освоить несколько языков и технологий, тем самым диверсифицируя свои знания.
Есть подозрение, в свете других событий, что всё делается намерено.
В ГосдуРе призывают запретить ИП и самозанятость.
Похоже, что зажравшиеся "бояре", чтобы компенсировать огромные дыры в бюджете и сохранить себе возможность закупки "золотых унитазов", хотят в очередной раз прихлопнуть текущий "НЭП" и сделать что-то типа new-идустриализации с некой формой нео-крепостного права.
Просто тогда миллионы людей потеряют возможность заработка и возможность работы на самого для себя, а не на богатого дядю, и вынуждены будут пойти на "заводы и стройки" (условно) или в большие корпорации, где за миску похлёбки вместо мигрантов класть кирпичи, точить болванки и шить говн@давы, и писать "православнутый" и одобренный код. Т.е. по сути как раз это и будет new-барщина.
Ну а сверху ещё накроют это цифровым Гулагом, где можно смотреть и слушать только то, что нужно и можно - т.е. как какой-нибудь очередной идеологически-правильный "Шаман" поёт "Славься, славься, наш русский царь!" для ботоксного самодура, а оплаченные пропаг@ноны будут рассказывать, какие все вокруг России сволочи и только здесь самая скрепно-православная правдушка...
Наверху как обычно у нас в большом количестве сидят прибившиеся к сытному корыту трутни, которым, судя по всему, наплевать на всё и на всех, лишь бы остаться у этого корыта.
Они так же щедро оплачивают и всяческих пропаг@ндонов, которые несут порой полную чушь или тупые лозунги.
То, что рекламу для ряда мелкого бизнеса убили закрыв Инст@грам - им глубоко фиолетово
То, что инженеры и IT-шники (которые им якобы нужны) часто уже не могут через YouTube смотреть обучающие или профильные видео - им глубоко фиолетово
То, что сами иностранные компании (как яркий пример, Intel) закрылись от российских адресов и без VPN из России никакой тех.информации не получить - им положить с прибором
То, что никто из зарубежных партнеров (у кого ещё остались деловые контакты) не будет с вами общаться по MAX - им положить с прибором.
Ради сохранения собственного доступа к корыту, и для агрессивной поддержки местных крупных корпораций они готовы заблокировать вообще всё - им на обычных людей или на мелкий бизнес вообще наср@ть.
Нострадамлю, что рано или поздно они прикроют и GitHub и прочие source-хранилища. Благостную причину для сидящих у зомбоящика дураков конечно же найдут, но основной причиной будет то, чтобы максимально ограничить доступ к открытым технологиям для масс.
Чтобы только гос.компании могли беспрепятственно использовать opensource, приклеивать к нему свои ярлыки и продавать за дорого на внутреннем закрытом рынке как якобы свои же разработки.
Второй месяц уже ковыряю 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) - кто бы знал? )))
Ваши замечательные красивые потуги на 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.