Всякие разные языки программирования, размышления.

Verilog - есть в нём определённая магия. Но при всей похожести синтаксиса на обычный язык программирования - это крайне специфичная вещь. Массовый параллелизм. Код, который мы пишем работает в пределах такта процессора. Романтика. Но, есть и оборотные стороны. Например пишем где-то в коде a*b - и это требует умножителя на постоянной основе. Обращение, даже к синхронной памяти - это гемморой. Т.е. заполняем адрес, потом ждем несколько тактов, потом нам приходит результат. А когда приходится разбивать алгоритм на несколько тактов (для повышения частоты), то тут геммороя ещё больше. Разбил одним вариантом, смотришь на slack отстающийся в конце такта на разных стадиях pipeline, начинаешь выравнивать. Через определённое время начинает хотеться писать на HDL более высокого уровня. Вобщем это такой язык, по сравнению с которым даже ассемблер - высокоуровневый язык программирования. Так что Verilog - экзотика, которая никому особо не нужна.
php - крайне специфичный язык программирования. Не сильно быстрый (сильно медленнее C++). Но и не особо медленный (сильно быстрее Python). Умеет хорошо отвечать на http(s) запросы и отдавать данные, которые размещенны в базе данных/файловой системе. Причем для этой области он отлично заточен. Асинхронные запросы/ответы прозрачные для программиста позволяют сделать очень маленькую латентность при ответе по http. Смотрел даже пару сравнений скорости работы http сервера php vs java vs c#. Хоть java и C# более быстрые языки программирования, но php выигрывал. Причина? Народу хочется программировать простой последовательный код. Поэтому на java/C# сервера были с созданием потока на каждый http запрос. Это конечно сильно медленнее, чем нормальные асинхронные вызовы и асинхронная обработка данных. Вобщем, тут и без меня умельцев хватает. А я, когда требуется простой http сервер - вполне обходился вариантами на C++ и Python.
go - аналогично php заточен на задачу backend. Простой менеджмент памяти. Синтаксис языка можно выучить буквально за пару дней. goroutines которые тоже скрывают магию асинхронных вызовов и позволяют удобно писать код для ответов на http запросы. Даже где-то слышал такое интересное мнение. Google придумал этот язык против особо умных программистов. Зачем? Вот скажем сидит такой программист (junior), пишет код ответов на http запросы. Годами пишет. И предположим на C++ это делает. В начале он пишет простой и понятный код. Потом от нечего делать, изучает тонкости C++ начинает использовать всякие template/variadic/lambda. Вроде хорошо, вырос программист, может даже senior стал. Только вот беда - код у него менее понятный стал для стороннего наблюдателя. Вот, что-бы такие выскочки не выскакивали и не писали мудрёный код, придумали язык go.
Java/Kotlin - Java кстати тоже была придуманна как упрощённый C++. С автоматическим менеджментом памяти. Обрезанными редкоиспользуемыми возможностями. Впринципе неплохой язык. Надежный. Правда не сильно быстрый. Плохо подходящий для математических вычислений. Kotlin - это по большей части та-же Java, но с осовремененным синтаксисом. Лично мне в Kotlin по сравнению с Java очень нравится nullability. Т.е. в Kotlin переменные по умолчанию инициализированны. Например в переменной типа String будет находится пустая строка, а не null указатель. Я время от времени встречаюсь с Java/Kotlin кодом, когда надо что-то написать под Android. Писать код можно, но особого восторга это не вызывает. Особенно возмущает gradle (это система сборки такая). gradle - ужастно медленный, жрет кучу памяти, совершенно недокументированный. Девиз gradle такой - если что-то пошло не так, система сборки не должна выдавать ошибку со строкой в которой ошибка случилась. Система сборки должна упасть, вывалить call stack на две-три страницы кода, а уж программист разберётся, что к чему. В IntelliJ Idea при запуске дебаггера есть даже выбор, что дебагировать - программу или систему сборки. Вобщем сама java неплоха, но студия тормозная и жрёт память как не в себя. Система сборки тормозная и тоже жрёт память гигабайтами. Пустой проект - это сразу сотня файлов, так что по мелочам Java/Kotlin беспокоить не хочется. Недавно появился Kotlin script для решения этой проблеммы, но он запускается так медленно, что уж лучше писать на Python.
А тут расскажу про Python. На нём приятно "говнокодить". Т.е. писать код на выброс. Причина - можно написать весь код в одной файле, запустить этот файл и всё будет работать. Даже если в этом файле используются сторонние библиотеки, то их очень легко установить используя pip - менеджер библиотек Питона. Причем очень легко получить код, который будет отлично (и одинаково) работать под Windows/Linux/MacOS. Python правда медленный, да и отсутствие типизации усложняет написание больших программ. Получить ошибку времени компиляции значительно приятнее, чем падение в Runtime через длительное время после запуска программы. Вобщем после написания программы, размером в несколько сотен килобайт кода, уже магия и приятность Питона развеиваются. Но всё равно - Питон крайне симпатичный язык программирования. Огромное количество библиотек. numpy, scipy, mathplotlib - отличный набор, что-бы что-нить посчитать побыстрому. Web сервер тоже можно поднять парой строк кода. Десяток-другой строк кода, и у тебя уже есть обучающаяся нейросетка. Так что Питон люблю, использую, но для всяких мелочей.
C# - это такая Java от Microsoft. Лично мне C# навится сильно больше, чем Java/Kotlin. Скажем так - C# делали с любовью и вниманием к деталям. Проект на C# очень быстро компилируется. Создать новый проект на C# можно набрав несложную команду в командной строке. Отлично работает как под Windows, так и под Linux. Причем имеет как надёжность и простоту Java так и очень хорошую скорость исполнения. Если не выделять зазря память и отключить всякие инициализации/проверки которых нет в Release версии C++. Так вот если поставить C# в условия сравнимые с C++, то и скорость выполнения программ будет сравнима с C++ вариантом. Лично у меня о C# очень приятные воспоминания. Причем - скорость компиляции не деградирует с ростом проекта (но об этом напишу при описании C++). Размер скомпилированного файла так-же невелик (меньше, чем аналогичный C++ исполняемый файл). Так что писать на C# люблю, но правда редко это требуется.
С++ - царь-язык, в котором понамешанно много всего, но есть и крайне много устаревшего. Так-же огромной проблеммой является система #include из-за которой при компиляции каждого объектного файла требуется перемалывать огромное количество информации. Проблемма в том, что часть информации дублируется в объектных файлах. И чем больше информации, тем больше дубликатов. Дублируются как тела функций, объявленных в хидерах (а template только там и можно размещать) так и дебаговая информация об них. Поэтому исполняемый файл нашей игры имеет размер оголо 20 МБ. Дебаговая информация - порядка 500 МБ. Суммарный объём объектных файлов - порядка 30 гигабайт. Я жду, когда таки допилят modules, которые сильно ускорят компиляцию и уменьшат размер временных файлов. Впрочем у С++ есть и другая проблемма - ненадёжность. На С++ сравнительно легко выйти за пределы массива или обратиться к уже умершему объекту. Так-же нет "из коробки" stack trace при падении приложения. Вот все другие языки выдают stack trace, а C++ видимо слишком древний и подобное удобство не являлось обязательным в те времена. Отсутствие пакетного менеджера тоже сильно усложняет написание простых программок на C++. Под Linux это правда компенсируется встроенным менеджером, поэтому достаточно удобно можно написать "apt install libcurl-dev". Но вот под Windows подтягивать зависимости C++ неудобно.
Rust - сейчас опять смотрю на него. Отличная замена C++. Borrow checker и система владения - это конечно отличный (в смысле отличающийся от остальных) элемент. Это позволяет делать программы в которых крайне сложно обратиться к умершему объекту. Аналогично это спасает от доступа к данным из нескольких потоков. Причем это в каком-то смысле осовремененный Си. Си в котором избавились от всякого старья и в котором повысили надёжность. Естественно там есть строки встроенные. Есть проверка на выход за пределы масива. Есть call stack при падении приложений. Есть пакетным менеджер. Есть модули. Поэтому теоретически не будет деградации скорости компиляции при росте размеров проекта. Ещё интересное веяние - это наличие "синтаксической соли". Не сахара, а именно соли. Это значит, что действия ведущии к "плохим" последствиям, надо писать используя большее количество буковок/знаков. Вобщем очень интересный язык программирования. Его область идеальная применения - там где одновременно требуется скорость, надёжность и многопоточность. Для написания кода для микроконтроллёров, http(s) серверов, пользовательского интерфейса язык Rust тоже вполне подходит. Очень интересный язык программирования. Мне кажется, что за ним большое будущее. Сложноват правда он для освоения.
|
</> |