Комментарии 305
Зря вы так на openCl.
Пока ему нет замены, если речь идет о кроссплатформерных задачах на gpu в науке. Cuda, metal отличаются вендор-локами все же.
Я смотрю OpenCL упорно пытаются похоронить уже лет 15 как. А он всё ещё живее всех живых.
Ни CUDA, не тем более вулкан его не заменил.
Я пишу на CoffeeScript. Интересно, есть хоть кто-нибудь, кто всё ещё его использует?
Но это же почти Ruby (и не только) поверх JS!))
Вот, к слову, тот самый язык из которого вытащили фичи и он умер.
Так то там появились классы до того как в JS их завезли, а ещё стрелочные функции с фиксацией this, и рест-параметры, когда пишешь 3 точки и все оставшиеся параметры попадают в массив. Хороший язык был, но увы, JS забрал всё хорошее и проект умер.
Сравнивают с Ruby его, но по факту только тем он близок что в стеке Ruby любили фронт на нем писать, вместо JS. А так для Ruby на фронте вообще Opal есть.
А так к питону ближе - из-за того что отступы вместо скобочек.
Ещё язык плохо с IDE дружит, что тоже даёт ему не очень зеленый свет. Так что оно может ещё и живо и в принципе из-за компиляции в JS оно может жить вечно, но в реальных проектах почти не используют.
А ещё в CoffeScript поздно завезли async/await, от чего даже временно родился IcedCoffeeScript. Потом в версии 2 допилили и кое-чего нативно добавили из JS, но уже поздно. К тому же автор языка на полтора года уезжал в путешествие во время бума популярности, возможно зря.
Я успел пописать на IcedCoffeeScript. Его await+defer немного отличался от того, что потом стали понимать async+await, т.к. он был реализован ещё на колбэках, без промисов.
Он позволил мне быстро накидать логику, и в целом способствовал моему совершенствованию в конкурентном программировании. Но в процессе рефакторинга, большую часть сахара я переделал обратно на колбэки. Осталось одно или два места с await+defer.
ну хоть я не одна такая странная.
Хотя, строго говоря, только в старых проектах, которые ещё году в 9-12 начинались.
Как вообще Erlang и тем более Elixir оказались в этой статье. Последний же не просто не на дороге вниз, он пока только набирает комьюнити.
На счет Elixir не скажу, а вот "очень своеобразный" (ИМХО через чур функциональный) Erlang - он реально не подойдет ни для одной новой разработки, на мой взгляд.
Тут у нас в компании оказалось некоторое количество в разной степени "микровости" сервисов когда-то написанных на Erlang... и каждый раз глядя на это люди говорят, а давайте лучше перепишем на python/Go/что-то еще с нормальной поддержкой в копании...
говорят, а давайте лучше перепишем на python/Go
Прямо как раньше, когда ещё в школах изучали не Python, а Бейсик, вчерашние школьники, поступившие в вуз, когда им задавали написать какое ни будь задание или курсовую на Си говорили "а давайте мы вместо Си лучше будем писать на Бейсике?".
Работал в компании, в которой основная разработка, в том числе и создание новых продуктов, ведётся именно на Erlang. Уверен, куда бы там послали того, кто предложил бы "а давайте перепишем всё на Go". ;)
Да, WhatsApp давно пора переписать на питоне. А RabbitMQ — на гошечке.
Существует значительный класс задач, в которых эрланг незаменим. Если ваши микросервисы можно без потери общности переписать на питоне/го — скорее всего, микросервисы вам не нужны вообще.
python/Go/что-то еще с нормальной поддержкой в копании...
Ну "поддержка в копании" у Erlang-а на недостижимом для python/go уровне. Там можно в приложение зайти как по SSH на сервер, и, не останавливая приложение (даже работающий прод), изучать, как оно работает, смотреть "процессы", смотреть их состояние, трейсить RPC между ними и любые функции в них. И на лету править код...
ИМХО через чур функциональный
И не просто так. Те, кто пытался повторить архитектуру Erlang-а на императивных языках (на том же go есть несколько попыток создать OTP, на java были) с сожалением обнаруживали, что с виду OTP создать можно, но гарантий OTP оно не дает. Оказывается гарантии стоят на обязательной иммутабельности, а язык с обязательной иммутабельностью - функциональный по-определению.
и каждый раз глядя на это люди говорят, а давайте лучше перепишем
Возможно они так говорят не потому что go/python лучше для задачи, а потому что им лень разбираться с Erlang.
Erlang для Elixir это как Java для Kotlin.
На Elixir можно писать и без знания Erlang (сам так три года писал), но лучше всё-же с ним.
А на Elixir микросервисы пишутся легко и непринуждённо. Асинхронный параллелизм из коробки.
Python вообще не конкурент, это другая ниша. Go.. почему бы и нет, но с тем же успехом можно и на плюсы переписывать.
Возможно, мне следовало изъясняться яснее) Erlang/Elixir тут в списке нишевых, но вполне себе живых языков)
https://lfe.io/ — и его пилит сам Роберт, между прочим.
Тут в целом ошибка их так писать. Это ж не C/C++, а 2 совершенно разных языка.
Elixir так вообще на данный момент самый лучший выбор для backend-разработки, если вам нужна отказоустойчивость и стабильная работа под высокими нагрузками. Phoenix уже который год подряд забирает номинацию "most loved web framework" от StackOverflow. И для IoT Elixir тоже топ. И ML модельки можно крутить, и интерактивные заметки делать (https://livebook.dev/) ничем не хуже, чем в Jupyter. Так что о нишевости тут и речи быть не может.
"most loved web framework"
Мне видится в этом некоторая манипуляция. Давайте для примера возьмем:
За 2022 год.
Phoenix: loved 972 vs 192
Laravel: loved 2810 vs 2349
Вроде бы всё честно, но очевидно сравнивается тёплое и мягкое.
Те, кто пишут на Phoenix явно не пишут на Laravel и не могут его оценить корректно.
И наоборот. Те, кто пишут на Laravel не могут оценить Phoenix.
Разумеется, мы будем наивно считать, что не было дизлайков вида "мне не нравится ларавель потому что он для ПХП, а ПХП говно").
P.S. Количество дизлайков jquery умиляет.
P.P.S. И да, на всякий случай: я тоже не люблю ларавель.
---
https://survey.stackoverflow.co/2024/developer-profile#key-territories-all-countries
Что касается этого опроса - вопросов по поводу репрезентативности еще больше.
Ну, пойнт был скорее в том, что глупо называть Elixir нишевым языком.
Тут уж даже упомянутый вами PHP и то более нишевый, т.к. у него меньше областей возможного применения.
Нишевый-нишевый. У каждого своя ниша. У Эликсира своя, у PHP своя ;-)
Это у нас только питон стяжает славу универсального каждой-бочке-затычка-языка.
Ну, с таким определением практически все языки нишевые у вас будут. В моём понимании, нишевый - это антоним для языка общего назначения. Т.е. примеры нишевых языков: SQL, CSS, Verilog и т.д.
Потому что ни один из перечисленных Вами не является языком программирования!
Это больше вопрос определений. Полнотой по Тьюрингу они обладают, пусть и с некоторыми оговорками (напр. взять не ANSI SQL 99, а TSQL), значит, при желании можно и языком программирования назвать. Но можно и менее спорные примеры нишевых ЯП привести: R, 1C, Q#
CSS уж точно не является тьюринг-полным в традиционном понимании, с любыми оговорками. В остальном соглашусь.
А если так?
Executing a program requires the ability to write to memory or in our case, to toggle inputs. This cannot be done automatically through CSS; a user must perform a mouse click for each individual toggle.
This cannot be done automatically through CSS; a user must perform a mouse click for each individual toggle.
Сомнительное условие. Но так можно и холивар устроить.
Это ж не C/C++, а 2 совершенно разных языка.
Строго говоря, С и С++ тоже расходятся в разные стороны все дальше и дальше...
Там, конечно, остается еще некий общий базовый синтаксис, но...
Elixir так вообще на данный момент самый лучший выбор для backend-разработки, если вам нужна отказоустойчивость и стабильная работа под высокими нагрузками.
Вот все не могу взять в толк - backend разработка - это вообще что? То, что крутится на сервере безо всяких интерфейсов, в фоне? Так там может крутиться что угодно.
Например, безумная числодробилка типа машинного моделирования каких-то процессов, написанная на фортране. Или, если это банк, то очень интенсивная работа с БД + вычисления с фиксированной точкой и всякими датами (и там от языка кроме всего прочего еще нужна поддержка эффективной работы с БД + умение эффективно работать с форматами с фиксированной точкой, включая всякие операции с округлением). У нас это пишется на упоминавшемся тут RPG хотя бы потому, что в плане работы с БД у него нет конкурентов. Плюс нативная поддержка всех типов данных, что есть в БД. Включая дату, время, timestamp и числа с фиксированной точкой decimal/numeric.
Вот все не могу взять в толк - backend разработка - это вообще что? То, что крутится на сервере безо всяких интерфейсов, в фоне?
то что крутится на сервере в принципе и да, не имеет интерфейсов
фронтэнд это GUI десктопных приложений, вебмордочки и мобилки(когда бизнеслогика находится на внешнем сервере, ютубчик например)
Так там может крутиться что угодно
Очень странно писать бэк на JS например, хотя был довольно продолжительный период когда на node.js писали бэк.
Тут вопрос скорее концептуально отраслевой, а так то бекенд можно хоть на бат-файлах под винду написать.
собственно есть инструменты более удобные для этого
вот например у меня есть проект с математическим моделированием через rest туда закидываются данные, питоном раскладываются по объектам и отправляются в сторонний математический солвер который их обрабатывает, потом обратно забирается результат, формируются отчёты и они становятся через rest доступны любому потребителю, будь то веб-фронт или 1С или еще какаянить чертовщина
собственно питончик тут удобная бэкендовская прокладка которая обеспечивает rest интерфейс, пред- и пост- обработку данных
У нас есть центральные сервера на которых крутится АБС - т.е. все данные, все собственно банковские операции там. Они работают на IBM i (AS/400) и там в основном RPG. Немного С/С++ (там где это удобнее - RPG, все-таки, специализированный язык, всякие системные штуки на нем коряво получаются). Ну и немного на CL - разные обертки где много вызовов системных команд.
Все это достаточно изолировано от внешнего мира. Общение с серверами или через очереди (IBM MQ, сейчас вот еще Kafka прикрутили - есть порт для АС-ки), или через вебсервисы на ESB шине. Напрямую из внешней сети до сервера доступа нет.
Это все mission critical часть.
То, что снаружи для нас - "внешние системы". Их несколько десятков разных, там другие платформы, другие стеки. Если общаться через очередь - на нашей стороне есть MQ API (которые обернуты движком - он мониторит очереди, получает сообщения, по типу сообщения вызывает прописанный для этого типа в конфигах обработчик где вся логика работы с этим сообщением) или сервисы для работы с кафкой, на той стороне скорее всего джава (для MQ там есть JMS - Java Messaging Services).
Вебсервисы - рестовые (хотя есть еще старые, соаповские). Пишутся на джаве, но там все тупо до безобразия. Просто преобразование типов данных. Их два типа - Get (передает параметры запроса, получает в ответ результат в резалтсете, на каждый тип запроса свой сервис) и AMD (Add/Maintain/Delete) - это сервисы на изменение данных. На каждую таблицу (которую предполагается изменять данными извне) свой сервис.
На нашей стороне для каждого вебсервиса есть соответствующий сервис-модуль. Это уже наша кухня - тут уже RPG. Там дернули вебсервис, у нас дернулся сервис-модуль. Вся логика в сервис-модуле реализована.
Как-то так все это живет.
IBM и компании, которые используют на IBM i, не особо то заинтересованы в популяризации этой платформы. Попытки портировать более распространенные языки на эту платформу были, но кажется большинство устраивает RPG и Cobol
На самом деле тому есть причина. Эта платформа позиционируется как высоконадежные и высокопроизводительные сервера для среднего и большого бизнеса. С упором на работы с БД и коммерческие вычисления.
И это есть коробочное решение. Т.е. все что тут есть, оно поставляется сразу с системой и глубоко в систему интегрировано.
Т.е. это достаточно специализированная платформа со специализированными инструментами для вполне определенного класса задач. И имеющийся инструментарий с этими задачами вполне справляется.
Плюс к тому внутренняя архитектура системы очень специфична и ни на что другое не похожа. Тут можно почитать Солтиса "Основы AS/400" - там и история и технические аспекты "потрохов" системы расписаны достаточно неплохо.
COBOL, кстати, тут не сильно популярен. В отличии от RPG, на котором пишется более 80% приложений. Потому что он, при всей своей простоте, позволяет решать специфические для этой системы задачи максимально быстро и эффективно.
Строго говоря, С и С++ тоже расходятся в разные стороны все дальше и дальше...
Соглашусь. Я имел в виду, что у этой парочки хотя бы есть совместимость на уровне того, что компилятор C++ понимает и код на C. Во всяком случае, так было, когда я прошлый раз этим интересовался.
Вот все не могу взять в толк - backend разработка - это вообще что? То, что крутится на сервере безо всяких интерфейсов, в фоне?
Ну, интерфейс должен быть, просто программный - в виде API, которое в свою очередь дергает frontend, инициируя тем самым HTTP-запросы. То, что крутится в фоне относится к фоновым задачам. Это можно рассматривать как часть backend-разработки, но не всегда. Например, там может, какая-нибудь ML-модель крутиться, или отдельный Data Lake. Поэтому иногда уточняют, что к backend относится только OLTP слой.
есть совместимость на уровне того, что компилятор C++ понимает и код на C
Анонимные структуры в C++ уже завезли?
Такое считается?
Исходник, если не хочется переходить на godbolt
template<typename T>
int test(const T&)
{
return sizeof(T);
}
int main()
{
struct {int a; double b;} x;
return test(x);
}
PS: чем лямбды не анонимные структуры с оператором круглые скобки?
Я про struct A { int x; struct { double y; float z ; }; }; Судя по годболту современные C++ компиляторы понимают, но когда появилось в стандарте не отследил. Но не уверен, что все фишки C17 есть в C++20.
чем лямбды не анонимные структуры
Как минимум тем, что никак не помогут в компиляции скопипащенного сишного кода.
Лет 15 назад анонимные структуры использовал...
Просто struct { int x; int y; } s; работало давно, вопрос об объявлении полей внутри других структур. В С оно появилось в C11, вопрос когда протащили в C++.
Можете кодом пример показать? Я либо не совсем понимаю Ваш запрос, либо это то, что эти самые 15 лет назад использовал.
#include <stdint.h>
#include <stdio.h>
struct {
union
{
struct { char low; char hi; }; // no member name!
uint16_t word;
};
} s;
int main()
{
s.hi = 0xab;
s.low = 0xde;
printf("%x\n", s.word);
return 0;
}Как минимум компилятор C++ из состава Visual Studio 2005 также сжирал без проблем.
PS: нашёл исходник проекта, который был завершён в 2006 году, который собирался VS2003, и там тоже такое было. Иными словами, анонимные структуры, похоже, поддерживались всегда.
Как расширение да, компиляторы съедали. Но в стандарте до 11го года не было.
Вот тоже проблема С++ - стандарт очень быстро меняется, язык становится все сложнее и сложнее (в него постоянно тащат все до чего руки дотянутся), компиляторы не всегда успевают за стандартом...
В результате, если есть какой-то большой проект, который развивается и поддерживается долгое время, обновление компилятора может вызвать определенные сложности.
обновление компилятора может вызвать определенные сложности.
Когда работал в достаточно крупном проекте (сотня девелоперов, компилировался пару часов), перед переходом на новую версию компилятора (без смены стандарта C++) инфраструктурная команда неделю вылизывала проблемки в своей песочнице.
Я на С начал писать где-то в конце 80-х. И он мне очень нравился (и до сих пор нравится).
Потом появился С++ - тогда фактически "С с классами". И тоже понравилось.
Но вот что с ним стали творить потом... Чем дальше, тем меньше нравится. Язык получается переусложненным. Как концептуально, так и синтаксически. С ним уже стало тяжело работать.
Слава богу, сейчас уже не приходится писать на нем что-то большое, а для мелочи вполне хватает С или С с классами по-минимуму.
Лично мне многие изменения (в том числе ещё не вошедшие в стандарт - скажем, std::simd и std::execution) скорее нравятся, и понимаю, почему для них нужна поддержка в самом языке (на уровне библиотек поддержать кодогенерацию под GPU или векторные инструкции проблематично) - но согласен, что в целом вырос огромный монстр, понять который целиком невозможно, и использование в большом продукте требует особой дисициплины в том, какие фичи и как использовать.
Из приятного в C++ - это RAII и move-семантика. Из неприятного - та же move-семантика, когда сравниваешь с другими, более новомодными, языками.
С RAII вопрос неоднозначный. В общем (и подавляющем большинстве) случае - да.
Но вот классический пример для RAII относительно файла - при выхода из области видимости файл закрывается. У нас такая техника строжайше запрещена т.к. ведет к избыточному переоткрытию файлов что приводит к затратам ресурсов.
Т.е. стандартная техника - файл открывается один раз и держится открытым. Но тут уже вступают в игру особенности системы. Все что работает, работает в рамках изолированного задания (job). А внутри задания есть еще группы активации (любая программа компилируется с указанием как использовать ГА - наследовать от вызывающей программы - *CALLER, создавать каждый раз новую - *NEW или использовать свою, именованную ГА).
Все выделенные в программе ресурсы хранятся в ГА. Что приводит к интересным результатам. Например, в одном и том же задании вызываем программу несколько раз. Так вот на второй и все последующие разы значения всех глобальных и статических переменных сохраняются с прошлого вызова. Если, конечно, программа вызывалась в той же ГА (т.е. это не касается *NEW - там под каждый вызов создается временная ГА которая уничтожается вместе со всеми ресурсами по завершении программы). Соответственно, при закрытии ГА все выделенные в ней ресурсы освобождаются.
Что это дает в плане производительности? Многократный вызов в рамках одного задания вещь достаточно частая у нас. И тут мы можем экономить ресурсы на открытии файлов. Или делать какие-то кеши (справочники и т.п.) которые заполнятся при первом вызове, а при 99 (условно) последующих уже будут сразу готовы к использованию. Все это в условия работы высокими нагрузками может оказаться достаточно существенным.
Так что RAII это хорошо, но может быть не всегда :-)
Т.е. стандартная техника - файл открывается один раз и держится открытым.
Тут тоже можно дойти до крайностей и упереться в лимит на число открытых файловых дескрипторов в ядре ) Но соглашусь, что без необходимости делать при смене области видимости что-то тяжёлое не стоит.
Более адекватный пример для RAII - захват и освобождение мутекса при доступе к разделяемым переменным, тут никуда не денешься, разве что поиграться с lock free (которое чревато багами и тоже не панацея, так что надо очень хорошо понимать, что оно даст в кокнретной ситуации).
Вот насчет количества открытых файлов в ядре... Если у нас постоянно крутится тысячи заданий и практически все они работают с таблицами (а таблица или индекс здесь - это файл с которым обычно работаем как с файлом). А в системе несколько десятков тысяч таблиц... Так что есть сомнения что там как-то это ограничено. Скорее ограничение "на задание" + ограничение на количество активных заданий в системе
По крайней мере под линуксом периодически влетаем в "Too many open files in system". Да, есть соответствующие ручки в proc и sysctl, но у нас "коробочный" софт, который пользователи скачивают и запускают в своём окружении, не всегда есть права что то поменять.
Ну то в линуксе :-)
Тут все иначе. Это ближе к мейнфреймам (хотя формально таковыми и не является). Система изначально многопользовательская. Т.е. подразумевается что тут будет много заданий одновременно работать. Так что есть ограничение на количество заданий в системе (достаточно большое, надо заметить), все остальные ограничения действуют в рамках задания.
Задание - какой-то процесс, выполняющий определенную функцию. Ну вот, скажем, контроль платежей. Там есть кроме всего прочего десять фоновых заданий которые занимаются проверками платежей. Т.е. идет поток платежных документов, он раскидывается на 10 заданий пачками по несколько документов. Каждый проходит через несколько проверок. Каждая проверка - отдельная программа. В RPG программа может иметь набор аргументов не как в С - argc/argv, а нормальных, типизированных. И любая программа может быть вызвана из другой как обычная процедура. Т.е. получаем не монолит, но набор программ-процедур, каждая из которых выполняет какую-то логическую функцию.
Вот и получаем что в задании работает диспетчер проверок который смотрит платежный документ и в соответствии с его данными (входящий, исходящий, внутренний, физик-физик, юрик-юрик и т.п.) вызывает в определенной последовательности набор программ-проверок. Каждая проверка использует для работы свои таблицы. В результате каждая проверка за стуки в одном задании может вызываться десятки и сотни тысяч раз (примерная нагрузка оценивается в сотню миллионов платежных документов в сутки - один из самых нагруженных сервисов). И при этом открытие файлов (таблиц) будет всего один раз. И один раз будут заполняться разные кеши со справочными данными (типа настроек и параметров проверки и т.п.)
Но с ограничением на количество открытых файлов тут не сталкивались... Бывало когда какая-то программа начинала в joblog спамить - да. На размер лога есть ограничение.
Также не сталкивались с ограничением на память - тут в основном она одноуровневая (single level модель). Формально на задание выделяется 16Гб статической памяти. И размер одного объекта не может превышать 16Мб. Там где надо больше - используем модель teraspace - там можно объекты до 2Гб создавать, но это редко когда реально надо. Хотя как-то делал. Там, если нужно что-то, сделано в teraspace, стыковать с тем, что сделано в singlelevel, приходится с указателями мудрить - в SL они 128бит, а в TS - 64бит...
Понятно, что в линуксе тоже можно настраивать ограничения для конкретного пользователя или для конкретной задачи в контейнере. Но уткнуться вполне можно.
Формально на задание выделяется 16Гб статической памяти.
Что то совсем мало даже просто на поиграться. Я обычно компилирую с make -j 64, при этом и один инстанс плюсового компилятора легко отхватывает гиг-другой, на линковке бывает побольше - благо на локальном серверке памяти более чем достаточно.
Вообще, хватает. Это же не относится к динамически выделяемой памяти. Там ограничение только на размер сплошного куска - 16Гб в single level и 2гб в teraspace.
А памяти хватает, да. Только оперативки на сервере 12тб установлено. А в одноуровневой памяти оно и не диске (400тб SSD) может выделяться.
В целом здесь ни разу не сталкивались чтобы память не хватало.
Ну бывает компилятор ругается что предельный размер автоматического массива слишком большой запрошен - выходит за пределы 16Гб (пару раз было - пожадничал).
Понятно, то есть масштабируется система обработкой действительно большого числа одновременных заданий.
Одноуровневая память и AS/400 в целом действительно интересны, но я только Солтиса читал - хорошая книжка даже если живьём никогда не столкнёшься ) Но там же вроде идеологически и без файлов можно обойтись - есть просто объекты, которые когда надо сохраняются на диске. Или всё таки приходится явно использовать файловое API?
Не... Там изначально "объектная система". Т.е. "все есть объект".
У объекта есть тип и атрибуты - это задается при создании и поменять потом нельзя. И есть набор свойств которые можно менять потом - имя, описание (строка), права доступа...
Набор допустимых действий с объектом определяется его типом. Ну то есть открыть программный объект и поправить там пару байтиков в hex редакторе не получится - такое действие для данного типа объекта не предусмотрено.
Есть объект типа *FILE. Это может быть или таблица (атрибут PF-DTA - "физический файл данных"), индекс (LF - логический файл), Файл с исходниками (PF-SRC - "физический файл исходных текстов") - фактически это тоже таблица (и ее можно скулем читать) в которой содержится несколько "элементов" (member) - каждый исходник - отдельный элемент. Например
Список файлов с исходниками.
Элементы (собственно исходники) внутри одного из файлов
Разных типов объектов в системе много. Там и очереди есть и области данных и "пользовательсеие пространства" и много чего еще.
С объектами типа *FILE работаем как с таблицами (это и есть таблицы) - найти запись, добавить запись, прочитать запись и т.п.
Есть "область данных" - *DTAARA - вот это типа как обычный файл размером до 2000 байт. Его можно прочитать в память, что-то поменять и сохранить обратно. Т.е. сначала создаем объект командой CRTDTAARA,в программе описываем буфер (ds - структура данных с привязкой к данному объекту)
dcl-ds dsECLCTL qualified dtaara('DAECLCTL') len(512);
LogMode char(1);
DelDate char(7);
LogDepth char(2);
MQReply char(1);
BadChars char(80);
Priority char(5) dim(5);
ExclAddrT char(20);
ExAdrTypArr char(2) dim(10) samepos(ExclAddrT);
PERlbAlwd char(1);
PPTRlbAlwd char(1);
OMURlbAlwd char(1);
OldPEIsOn char(1);
FullContCd char(40);
RESRlbAlwd char(1);
NKMECU char(1);
NKMECF char(1);
NKMECU1 char(1);
NKMECF1 char(1);
NKMECA char(1);
NKMECD char(1);
dsRCLPER likeds(t_dsRCLPER);
DetalLog char(1);
UNLRlbAlwd char(1);
RclAdrLst char(5) dim(5);
ECAElm char(1);
CntpAddrLmt char(3);
end-ds;тут ключевое слово - dtaara('DAECLCTL') - означает что эта ds связана с областью данных.
А потом читаем
in dsECLCTL;Если что-то поменяли и нужно сохранить
out dsECLCTL;Эти штуки обычно для хранения всяких настроек используются.
Есть еще "пользовательское пространство" - User Space - *USRSPC. С ним работа как с memory mapped file. Т.е. создаем его командой CRTUSRSPC а потом чтобы работать нужно сначала получить указатель на него. Когда есть указатель с ним уже работаешь просто как с памятью и все изменения автоматически сохраняются на диске.
Т.е. как такового файлового API тут нет. Есть способы работы с объектами для каждого типа свои.
Есть еще IFS - интегрированная файловая система. Это отдельное хранилище. Вот там уже обычный unix-like. Т.е. обычные файлы, папки и все вот это привычное. С ней можно работать обычными С-шными функциями работы с файлами. Ну или есть системные команды позволяющие, например, элемент (исходник) из файла исходников скопировать на IFS. Или наоборот, с IFS файл в элемент файла исходников.
В общем, тут достаточно непривычно это все поначалу.
В целом, все это можно и руками потрогать. Есть бесплатный сервер PUB400 можно там создать профайл (места немного дают, но поиграться можно). Единственное что там надо - эмулятор терминала IBM5250 (говорят, что telnet клиент более-менее работает, но лучше взять пакет IBM i Access Client Solutions - он бесплатный и там есть все для работы с сервером).
вы только указывайте про какие оси вы говорите, если про IBMовскую проприетарную ОС, то там архитектура может быть даже близко не похожа на линукс и странно обсуждать ограничения дескрипторов ФС сравнивая их напрямую
Ну про ту, в которой работаю естественно. AS/400.
Конечно там близко похожего на никсы ничего нет.
Собственно, разговор начался с того, что RAII хорошо в большинстве случаев, но возможны ситуации когда оно будет мешать и снижать производительность. Точнее, мешать использовать стандартные приемы для повышения производительности.
Соглашусь. Я имел в виду, что у этой парочки хотя бы есть совместимость на уровне того, что компилятор C++ понимает и код на C. Во всяком случае, так было, когда я прошлый раз этим интересовался.
Увы, но уже не всякий С-шный код будет скомпилирован С++ компилятором. Т.е. "чисто С-шный". Тут скорее может идти речь о "С++ без классов" а не о классическом С.
Ну, интерфейс должен быть, просто программный - в виде API, которое в свою очередь дергает frontend, инициируя тем самым HTTP-запросы
Ну в таком понимании у нас нет "бэкэнда". Т.к. у фронтов нет прямого доступа к тому, что работает на сервере. И уж тем более никакого HTTP. Мы JSON-то только в самых крайних случаях используем ввиду больших затрат на его кодирование-декодирование.
Все крутится фоном.
Ну или у вас просто специфическое понимание бекенда, которое не совпадает с общепринятым мнением. Хотя само слово бекенд в целом многозначное, можно и бекенд компилятора сюда приплести. Но обычно речь идёт по умолчанию о том, что я описал.
Ну я просто пытаюсь понять - то что мы делаем это бэкенд или нет.
Судя по всему, таки нет в принятом его трактовании.
Тогда встает вопрос - "что ты такое?" (С) Ни фронт, ни бэк, ни десктоп...
Если к вам поступают данные из каких-то внешних источников, но не напрямую от пользователей (через MQ, насколько я вас понял), вы их каким-то образом обрабатываете, а потом предоставляете доступ к данным, чтобы их могли забрать другие системы, которые уже напрямую контактируют с внешним миром, то похоже, что вы делаете data-слой (ETL, OLAP, etc.)
Ну я не силен в модных словах. Наша задача - обеспечивать всю внутреннюю банковскую логику, которая крутится в фоновом режиме. Попутно есть несколько десятков "внешних систем", которым тоже что-то бывает нужно. Тот же клиент мобильный или интернет-банк. Хочет клиент посмотреть историю операций - дергает REST API - "дай выписку за такой-то период для такого-то клиента по такому-то счету". REST API дергает вебсервис, тот дергает наш сервис-модуль с передачей ему параметров запроса - клиент, счет, период. Сервис-модуль выполняет запрос и возвращает SQL резалтсет который уходит обратно в мобильное приложение клиента. Это синхронный механизм.
Если речь идет об очередях, то там похоже, но асинхронно - есть пара очередей - входящая и исходящая. Кто-то там кладет в очередь сообщение с указанным типом и набором данных. На нашей стороне работает HMQ движок который мониторит очереди. Он берет из очереди сообщение, смотри его тип и по типу запускает (обычно в параллельном задании) обработчик данного типа сообщений (имя обработчика определяется из конфигов), отдавая ему в качестве параметров тип и тело сообщения. Дальше обработчик делает что нужно по логике и если требуется ответ, обработчик кладет его в исходящую очередь которую на той стороне уже мониторит источник запроса.
Но все это всего лишь один из аспектов нашей деятельности. Там еще много чего еще. Платежи, тарифы, лимиты, разные уведомления клиентам... Закрытие банковского дня и переход на следующий день... Все это само по себе в фоне крутится постоянно.
Вот каждый день запускается сервис рассылки уведомлений. В частности, проверяются сроки действия ДУЛ (документ удостоверяющий личность) клиентов. Если у клиента истекает срок действия ДУЛ - ему посылается предупреждение. Если уже истек - уведомление о блокировке счетов. Проверяются ДУЛы самих клиентов и их держателей карт (когда клиент оформляет карту на другое лицо). Сформированное уведомление помещается в очередь откуда потом забирается одной из внешних систем, отвечающей за физическую рассылку (e-mail, sms, push...)
Еще есть журнальные мониторы... Которые отслеживают изменения в таблицах и смотрят что изменилось и нужно ли что-то делать по этому поводу. Например, открыл клиент новый счет - банк обязан сообщить об этом в ФНС. Вот ЖМ, отслеживающий таблицу счетов обнаружил новую запись - формирует соответствующее сообщение и кладет его в очередь для внешней системы, отвечающей за отсылку данных в ФНС.
Тут такое количество логики, что всю ее очень мало кто знает. Команд много, каждая занимается своим направлением. Есть тарифный модуль, лимитный модуль, модуль пластиковых карт... Есть система расчетов... Есть комплаенс (я как раз в команде комплаенса). Одна из наших задач - получение списков росфинмониторинга и раскладка их по базе с формированием стоплистов (списки совпадений клиентов с субъектами списков - имена, адреса и т.п.). Собственно списки приходят куда-то во внешнюю систему в виде многомегабайтных XML. Там они режутся на порции (один субъект) и передаются нам через MQ. Наш обработчик уже все это раскладывает по БД в удобном нам для дальнейшего использования формате. И каждое утро (начало банковского дня) запускается "сверка" - поиск совпадений между клиентами банка и субъектами. Их 4 штуки - по именам (клиенты и субъекты клиентов - всякие доверенные лица и т.п.) и по адресам (аналогично). Про сверку по адресам немного писал тут
И опять это все только одна из многих задач, которые решаются на нашем (центральные сервера) уровне. Описывать все это очень долго и сложно все это связно расписать. Огромный объем логики и огромное количество самых разных данных и бизнес-процессов.
Хочет клиент посмотреть историю операций - дергает REST API - "дай выписку за такой-то период для такого-то клиента по такому-то счету". REST API дергает вебсервис, тот дергает наш сервис-модуль с передачей ему параметров запроса - клиент, счет, период. Сервис-модуль выполняет запрос и возвращает SQL резалтсет который уходит обратно в мобильное приложение клиента. Это синхронный механизм.
Такой сервис-модуль NRT-витрина называется в терминах data-слоя.
Но в целом, из всего того, что вы описали, выглядит так, что у вас и backend, и data-слой, и оркестратор в одну кучу свалены. Я уже даже не удивлюсь если у вас ещё и куча логики в хранимых процедурах на уровне СУБД находится. Поэтому одним словом тут не обойтись. Сейчас принято это всё на отдельных уровнях делать, и совсем разные команды каждым направлением занимаются.
Это АБС банка. Тут хранятся все необходимые для работы данные и вся логика. Т.е. вся mission critical часть.
Растаскивать все это - в ущерб производительности.
И SQL тут используется очень ограниченно. Есть возможность прямой работы с БД - это и по скорости и по ресурсам предпочтительнее.
В целом это немного похоже на модель акторов - есть много модулей-функций, каждый из которых вызывается по мере необходимости (по времени, по событию или еще как-то).
Тем временем всякие RabbitMQ все еще активно исрользуют первый
вот только где оно, это набирающее силу комьюнити?
Более полугода не можем закрыть вакансии в бэкэнд на Elixir. В итоге, принято решение начать перевод нескольких систем на java.
Commodore BASIC у меня установлен на айфоне. А ещё Galmbit Scheme и Common Lisp.
Не увидел Perl
Перл ещё недостаточно мёртв.
Год назад работал в месте, где были скрипты на Perl для самописной сборочной системы, написаны они были 7 лет назад одним энтузиастом, и с тех пор почти не изменились, т.к. никто в отделе из 70+ человек больше не знает Perl)
И это было единственное место за последние 10 лет, где я видел Perl)
Могу сказать, что пользовался Perl года 4 назад - писал скрипты для обработки результатов расчетов газодинамики в постропроцессоре ANSYS CFX :) Так что вполне еще живой, но да, Пайтон конечно удобнее
В Мэйле (ныне часть ВК) и Яндексе ещё много Perl. Но от него активно пытаются избавиться (в основном, переходя на Go), т.к. нанять нового разработчика или стажёра стало невероятно трудно.
Говорят, Booking.Com весь на перле. Не знаю, как сейчас, но лет пять назад мне писал их хантер со словами «неважно, если вы вдруг не знаете Perl, мы вас научим. Вы только приходите, пожалуйста». И это он не меня так высоко оценивал, а явно шаблон рассылал всем подряд.
Насчет всего не знаю, но то что проходил собес туда на PHP точно
В Мэйле (ныне часть ВК)
Наоборот же, Mail.Ru Group стала VK называться.
Не далее, чем в 2021 году занимался переносом бэкенда одного проекта с перла на node.js. Сколько ещё подобных приложений продолжает работать в продакшене -- одному Ктулху ведомо.
И это один из главных причин его ухода - поддерживать написаное некому, мало кто знает перл. Я бы даже сказала мало кто хочет поддерживать чужое легаси на перле. Вот сколько видела чужой код - разобраться в чужом и внести небольшую правку зачастую не проще, чем с нуля написать что-то свое.
Всё потому, что пропагандируемый со времён первых массовых книжек от о'Рейли "хороший перловый стиль" - фактически, write only. На перле можно писать понятно, но это некузяво :)))
Я видела очень много разных "стилей" написания. Если это не пьяное творчество (такое можно понять наверное только автору и в аналогичном состоянии), то в целом можно приспособиться и начать читать авторский стиль перлокода. Тут скорее проблема в интерпретаторе, который переваривает почти любой стиль и разметку. Хочешь функционально, хочешь объектно, можно в перемешку, хочешь - любую структуру данных через классы или хеш хешей хешей не сильно типизированных данных. То, что можно делать с переменными в перле настолько безобразно безгранично, что просто ужас. Особенно если приправить неявными переменными.
Его периодически тыкают палкой, слышат слабый стон и оставляют ещё.
Ещё лет 10 назад мне периодически кидали вакансии на Perl отчаявшиеся HR-ы, разглядев в глубоких недрах моего резюме, что ещё 25 лет назад до этого я писал на Perl. Пришлось в итоге полностью удалить из резюме инфу о старых местах работы, ибо забодали предложениями про Perl, Sharepoint и прочие предания старины глубокой, к которым я не хотел возвращаться.
Думаю разработчику с КДПВ должен быть вполне понятен "план калкуль"
B4X java-based, который теперь и к Python будет имеет интерфейс.
На ум приходят различные диалекты BASIC (1964), появившиеся вместе с Commodore, ZX Spectrum, Amiga и т. д. Они умерли вместе с софтом, для которого создавались.
PureBasic жив https://www.purebasic.com
Пришлось прочитать метр статьи с повторением одного и того же что бы узнать что на самом деле меня ждёт простое перечисление языков, которое автор обещал не делать в начале статьи
Вы не поймёте язык, код на котором мы не покажем!
Можно вспомнить ещё ДИАМС (который из Mumps родился). Можно было и по нормальному писать, но обычно все, включая системное ПО, написано в таком птичьем стиле. Вначале мозги набекрень, а потом привыкаешь и сам также пишешь, коротко и удобно
Код со скриншота Intercal'а - вот где черпали вдохновение Раммы, когда писали Ду хаст ;)
"Язык" 1С версии 5.0-6.0 подозрительно похож на Plankalkül (только с кириллицей). Вот такая примерно это была дичь:?(СТРДЛИНА(СП{3}.1)=0\""+СН{3}\""+СП{3}.1)+?(СТРДЛИНА(СП{3}.2)=0\""\", "+СП{3}.2)+": "+СП{3}.5+", "+СП{3}.3+","+СП{3}.4
Да нет, большинство вполне понятно.
ЕРШОЛ забыли:
алг Сумма квадратов (арг цел n, рез цел S)
дано | n > 0
надо | S = 1*1 + 2*2 + 3*3 + … + n*n
нач цел i
| ввод n; S:=0
| нц для i от 1 до n
| | S := S + i * i
| кц
| вывод "S = ", S
кон
ЕРШОЛ забыли
Очень похоже на тот язык (КуМир) который проходили (может до сих пор проходят) школьники в России в старших классах.
до сих пор проходят, только не в старших, а в 5-6. Кумир просто отвратительно задокументирован каким-то птичьим языком. Предполагалось, что документация для школьников, но я там так и не понял, как найти нужный оператор, когда дочке в школе пытался помочь. Меня спасло от позора, что дочка сама нашла в своих записях раньше, чем я сумел понять логику хелпиков у кумира..
Ептоскрипт
1C забыли <sarcasm>
правило хабра #4365: в любой статье про языки программирования в комментариях всегда будет упоминание 1С
1С нас с вами переживёт. Он и до импортозамещения себя неплохо чувствовал, а теперь и большие конторы его вынужденно внедряют вместо «ушедшего софта».
Он неплохо себя чувствовал исключительно за счёт законодательной монополии.
А можно пояснение? Какая такая у него была законодательная монополия?
никто никого не заставляет использовать именно 1С для чего-либо
было когдато время когда налоговая рекомендовала использовать некоторые программы от 1С потому что другие аналоги вообще не могли осилить сделать чтото вменяемое
и были времена когда ПФР например не принимал некоторые отчеты сделанные в 1С (7.7 ЗиК) потому что эту софтину явно делали наркоманы и там без поллитры не то что программисту, но и пользователю было тяжело раобраться что оно там и почему считает...и все пользовались поделками от какихто студентов... (собственно мнение про наркоманов в зарплатных конфах от 1С у меня не поменялось до сих пор)
А как же spl?
На М600 СМ2М его семействе жил до См1210
Я сейчас работаю с IBM iSeries серверами и на нем работают приложения на очень специфичном языке RPG. Очень древний и чем-то похож на COBOL
В тред призывается @SpiderEkb
Лучше @saipr, он 40 лет назад книжку выпустил про комплексирование всякого из этой серии, в том числе РПГ. https://habr.com/ru/articles/740018/comments/#comment_25622096
Да, почти 50 лет назад я написал транслятор с РПГ, вы не поверите, для ЭВМ М-220:
Ну... Это был изначальный RPG. Максимум, RPG-II Который начинался как "начинка" для эмуляторов табуляторов IBM-1401
Современный "FullFree RPG" это совершенно другой язык. Процедурный, с синтаксисом паскалевского типа (но легким привкусом PL/I - все эти dcl-... к примеру). И давно уже ушли от изначального Cycle Mode первых версий (где программа по умолчанию крутится в цикле, обрабатывая запись за записью пока не будет установлен индикатор "последней записи" - *inLR = *on) к обычному для традиционных языков Linear Mode.
Конечно, совсем другой. Вот например как в стародавние времена описывалась выходная форма:
Ну я в соотв. статье приводил фирменный бланк RPG
Кстати, современный компилятор RPG на IBM i до сих пор "переваривает" FIXED код
*---------------------------------------------------------------------------------------MAIN
* MAINLINE MAIN
*---------------------------------------------------------------------------------------MAIN
* MAIN
B001 C @BEGIN IFEQ 'Z' MAIN
001 C MOVE *ON *INLR MAIN
001 C RETURN MAIN
E001 C ENDIF @BEGIN EQ 'Z' MAIN
* MAIN
* Request initialisation MAIN
B001 C @BEGIN IFEQ #YES MAIN
001 C #BEGAN ORNE #YES MAIN
001 C EXSR A000 MAIN
E001 C ENDIF @BEGIN EQ #YESMAIN
* MAIN
C Z-ADD *ZERO @NORET MAIN
B001 C @NOREQ IFEQ *ZERO MAIN
001 C @NOREQ ORGT #ARLEN MAIN
001 C Z-ADD #ARLEN @NOREQ MAIN
E001 C ENDIF @NOREQ EQ *ZERMAIN
* MAIN
C MOVE 'N' #SFFUL 1 MAIN
* MAIN
* If no error generated MAIN
B001 C @ERCOD IFEQ *BLANKS MAIN
* MAIN
* Retrieve relevant database records MAIN
B002 C @NORET DOWNE @NOREQ MAIN
002 C #EOF ANDEQ #NO MAIN
И периодически с ним приходится работать когда что-то совсем старое на доработку попадается. Так что как минимум "читать со словарем" такой код обязан.
По возможности стараемся избавляться (если изменений в логике достаточное количество, проще переписать модуль на fullfree чем править вот это вот).
Здорово. Мы изучали РПГ вот по этой книге:
Да... В те времена все по книгам... Сам начинал в "доинтернетную" (у нас) эпоху...
Впрочем, сейчас нет книг по современному RPG где все было бы более-менее связно и концептуально изложено. Есть справочная литература по функциям, есть разного рода Programmer's Guide, Tips and Techniques, но там все скорее в виде "хочешь получить это - делай так". Без понимания концепций языка. Чисто практические навыки. А вот вглубь приходится самостоятельно копать уже.
Когда-то правил программы на чем-то похожем. Какие-то внутренности бухгалтерской Sun Account
Вполне возможно. RPG в ранних версиях много где пытались "приживить" Но не прижился т.к. достаточно глубоко интегрирован в AS/400 и DB2 и все свои преимущества проявляет именно в родной среде.
Да видел тему. Ну раз призывается...
В целом, писал уже про RPG здесь и чуть более подробно про одно из его основных назначений - работа с БД здесь.
Если кратко - язык нишевый. Но живой и развивающийся постоянно. Живет он на нишевой же (банки, страховые и т.п.) платформе IBM i (AS/400) - Hi-End серверы для среднего и крупного бизнеса. Высоконадежные, высокопроизводительные. Отличительная особенность в том, что это на 100% коробочное решение. Покупая сервер с ОС клиент получает сразу все - БД (DB2) интегрирована в ОС (за счет этого достигается высокая производительность). Не поставлена сверху, а именно интегрирована. Все средства администрирования, разработки (компиляторы тоже интегрированы, еще и объединены в единую среду - ILE). Все это постоянно развивается - и железо (процессора семейства Power - в 17-м году я начал с этой системой работать на Power8, сейчас у нас Power9 и несколько машинок с Power10, а на подходе уже Power11) и ОС - начинал с 7.3, сейчас 7.4, есть уже 7.5 (и это не считая выпусков минорных обновлений - TR - Technology Refresh которые пару раз в год появляются).
В РФ, из того что знаю - минимум 4 банка (Альфа, Райф, Росбанк и Ак-Барс) на ней работают. Еще Альфа-Страхование. Были машинки в ПФР и РЖД (не знаю как сейчас).
Так вот, на этой платформе более 80% кода написано и пишется на RPG. Т.е. там это фактически основной язык. Плюс С/С++ там, где это удобнее (например что-то системное). Они между собой прекрасно стыкуются.
Пример из недавнего - нужна была одна функция, которую мне лично было удобнее написать на С (т.к. я на нем писал более 25-лет). Пишем исходник PARCEPARMS.CPP в котром раеализована
extern "C" char getKeyValuePair(char* inStr, PVarChar key, int keyLen, PVarChar value, int valLen);Основной исходник у нас на RPG (точнее, на RPG с использованием embedded SQL) - USPD93R.SQLRPGLE. В нем описываем прототип нужной С-ной функции на RPG (она описывается как "внешняя процедура" т.к. находится в другом модуле (модуль, *MODULE - аналог объектного файла) - связывание будет на этапе биндинга (bind здесь аналог link)
dcl-pr getKeyValuePair ind extproc(*cwiden: 'getKeyValuePair');
inStr pointer value options(*string: *trim);
key varchar(16535) options(*varsize);
keysize int(10) value;
value varchar(16535) options(*varsize);
valsize int(10) value;
end-pr;Далее создаем модули для PARCEPARMS
CRTCPPMOD MODEULE(QTEMP/PARCEPARMS) SRCFILE(&ASRC/&SRCF) SRCMBR(PARCEPARMS) OUTPUT(*PRINT) DBGVIEW(*SOURCE)и для USPD93R
CRTSQLRPGI OBJ(QTEMP/USPD93R) SRCFILE(&ASRC/&SRCF) SRCMBR(USPD93R) DYNUSRPRF(*OWNER) DBGVIEW(*SOURCE) COMMIT(*NONE) OBJTYPE(*MODULE) RPGPOPT(*LVL2) SRTSEQ(*HEX) OUTPUT(*PRINT) LANGID(rus)а потом собираем их в одну программу
CRTPGM PGM(&AEXT/USPD93R) MODULE((QTEMP/PARCEPARMS) (QTEMP/USPD93R)) BNDDIR((*LIBL/EQBNDDIR)) ACTGRP(*CALLER) STGMDL(*SNGLVL) ALWUPD(*YES) ALWLIBUPD(*NO) ENDMOD(QTEMP/USPD93R) USRPRF(*OWNER)CRTCPPMOD, CRTSQLRPGI, CRTPGM - системные команды вызова компиляторов С++, SQLRPGLE (сначала SQL препроцессор, потом RPG компилятор, если без SQL то была бы команда CRTRPGMOD) и биндера (линкера).
Биндеру указываем список модулей из которых собирается программа
MODULE((QTEMP/PARCEPARMS) (QTEMP/USPD93R))и модуль, содержащий точку входа (в RPG нет зарезервированной функции main - она может называться как угодно главное указать в программе CTL-OPT MAIN(USPD93R) - это значит что точкой входа будет процедура с именем USPD93R)
ENDMOD(QTEMP/USPD93R)Если используются какие-то сервисные программы (*SRVPGM - аналог динамической библиотеки), указываем их Binding Directory (*BNDDIR - аналог библиотеки импорта)
BNDDIR((*LIBL/EQBNDDIR))That's all Folks! Получаем программу, часть которой написана на RPG (да еще с использованием встроенного SQL), а часть - на С/С++
Впрочем, система сборки у нас автоматизирована так что все эти страшные команды генерируются автоматом на основе gradle скриптов
В данном случае
as400modules {
PARSEPARMS {
sourceMember = "PARSEPARMS" // Set value for member with source code if not match with OBJECTNAME
sourceType = "CPP" // supports types: RPGLE, RPG, SQLRPGLE, CL, CLLE, CLE, C, SQLCLE, SQLC, CPP, CPPLE, SQLCPP, SQLCPPLE
compileOptions = "OUTPUT(*PRINT)" // COMPILE OPTIONS
}
USPD93R {
sourceMember = "USPD93R" // Set value for member with source code if not match with OBJECTNAME
sourceType = "SQLRPGLE" // supports types: RPGLE, RPG, SQLRPGLE, CL, CLLE, CLE, C, SQLCLE, SQLC, CPP, CPPLE, SQLCPP, SQLCPPLE
compileOptions = "DYNUSRPRF(*OWNER)" // COMPILE OPTIONS
}
}
as400crtPgm {
USPD93R {
description = "СМ Контроль блокировок ФЛ" // PROGNAME if not specified
programLib = "%AEXT%"
activationGroup = "*CALLER"
userProfile = "*OWNER"
entryModule = "QTEMP/USPD93R" // qualified name of entry module
modules{
// modules for program creating
USPD93R {
moduleName = "USPD93R" // set if value not match OBJECTNAME
moduleLib = "QTEMP" // QTEMP by default
}
PARSEPARMS {
moduleName = "PARSEPARMS" // set if value not match OBJECTNAME
moduleLib = "QTEMP" // QTEMP by default
}
}
bnddirs{
// *BNDDIR objects for resolving import symbols
EQBNDDIR {
bndDirName = "EQBNDDIR" // set if value not match OBJECTNAME
bndDirLib = "*LIBL" // *LIBL by default
}
}
}
}Так что вполне себе живем.
Ух ты. Огромное спасибо. Даже в один комментарий можно вложить хороший такой кусочек знаний.
Я первый раз столкнулся с AS/400 в 2007 году когда работал в голландском ABN AMRO и все банковские продукты крутились на этих мейнфреймах. К счастью, или к сожалению, взаимодействие с кодом было минимальное, все было написано и отлажено до идеала задолго до меня, только один раз мне потребовалось в тестовом окружении хорошенько так править код. Но вот что странно, я не помню, чтобы это был RPG синтаксис. И не Си. Такое ощущение, что это был COBOL, но вспомнить уже не получится за давностью лет.
Сейчас работаю в американском страховании и тут тоже сервера IBM. Моя задача переводить код из RPG в Java. Компания решила мигрировать и эта задача по миграции просто огроменная. Строк кода миллион
Спасибо :-)
Вообще-то на AS/400 COBOL тоже поддерживается и тоже входит в список ILE языков. Другое дело, что IBM сама COBOL особо не двигала - этим занимается MicroFocus (могу наврать, не взыщите но ощущения именно такое). По крайней мере на AS/400 в приоритете всегда был RPG как основной язык.
Мигрировать с него куда-то... Если оставаться на этой же платформе - дело абсолютно бессмысленное. Потому что в той же Java нет ни поддержки типов данных (всякие decimal, numeric, date, time. timestamp, которые есть в БД и которые поддерживаются языком, делая работу с БД простой и удобной), ни поддержки работы с БД - прямым доступом (который в ряде случаев намного эффективнее SQL), ни встроенного SQL с возможностью делать статические запросы с подготовкой плана запроса на этапе компиляции что сокращает время и ресурсы в рантайме). Т.е. все это будет работать медленнее и затрат на миграцию там будет мама не горюй.
В целом, RPG поддерживает стыковку с Java объектами. Подробностей не знаю т.к. никогда не пользовался, но в целом суть подхода та же - работу с БД и всякую бизнес-логику пишем на RPG, а что удобнее - всякие внешние бантики - на Java.
Уж если мигрировать, то на С/С++. Там хотя бы можно embedded SQL есть поддержка decimal типа данных (но нет numeric, хотя он простой - можно конвертировать легко) и нет такой поддержки date/time/timestamp. Но есть возможность прямой работы с БД через библиотеку RECIO - тоже штатная на AS/400.
Ну и канонический пример миграции - Банк Содружества Австралии и Океании. В один момент решили "избавиться от легаси". С чего мигрировали не в курсе (скорее всего тот же COBOL). Куда - ну, видимо, Java. Но суть не в этом. Суть в том, что заняло это у них 5 лет - с 2012 по 2017гг. И обошлось в $750 000 000... Ну и проблем по дороге нахватали типа как в один день обнулилась вся кредиторская задолженность по всем клиентам... А это откат с ленты на прошлую бизнес-дату, а потом все ручками, ручками... За меньшее-то могут на комиссию по инцидентам позвать, а тут такое...
Но если что - заходите, может смогу чем помочь :-) Все-таки скоро 8 лет как работаю на этой платформе.
Нам руководство о причинах миграции не рассказывает, но насколько я понимаю, для них этот код - лютое легаси. Людей, кто может это поддерживать, не говоря уже писать что-то новое, как говорится кот наплакал. Я видел программистов, которые пишут РПГ код у нас в компании и которые работают здесь уже лет 40, им самим уже за 60. В руководстве понимают, что еще лет 10 и всё - они уйдут. На рынке людей со знанием РПГ видимо тоже критически мало. Заниматься обучением рисковано. Вот и мигрируют на попсовый стек.
С другой стороны, сама IBM тоже не сильно продвигает свой язык. И честно говоря, мне их стратегия непонятна. С одной стороны они активно развивают свое железо, судя по вашим комментариям про Power8-Power11. Но с другой стороны свой нишевый язык просто тянут паровозом за серверами. Мне не встречалось еще современных книг по RPG. Взять любой другой язык, не вендорлоковый - тонны литературы.
Ну язык-то очень сильно интегрирован в систему. Вне нее не живет. А так - постоянно что-то новое появляется в нем...
А мигрировать такие системы - пока мигрируешь, модный стек уже в легаси превращается :-)
Вообще, судя по группам в LinkedIn, разрабы на RPG есть вполне себе живые.
Там вообще много известных людей - Хатчинсон, Клемент, Коцци, Аллан (который IBM i Development Pack писал для VSCode). Барбара Моррис иногда бывает (хотя ее проще на StackOverflow найти)
Иногда легче написать свой простой скриптовый язык для нишевой задачи, связанной с управлением оборудованием тестирования электроники, к примеру , или интеллектуального датчика. Пример такой системы и табличного языка описан в моей статье ( в моем профиле на хабр.). В общем система живет и развивается. Программирование тестов стало рутинной задачей. Обошлись без высокоуровнего языка программирования. Только LabVIEW и SQL.
Если проект выстреливает и развивается, то очень часто в итоге такой скриптовый язык потом сводится к своей кривой-косой версии либо Python, либо Lua.
Поэтому проще сразу их и взять.
Наблюдал такое в геймдеве, когда помню у всех инструментов типа Maya когда-то был свой собственный скриптовый язык, но постепенно все стали переходить на стандартные языки.
MEL, кажись, был в Майе.
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Вот, кстати, Common Lisp ещё вполне живой.
Вы не поняли. Это так называемый DSL, предметно-ориентированный язык. Работает на клиенте labview в качестве интерпретатора. Заменить LabVIEW не так просто любым универсальным языком, ибо требуется очень и очень много кода. И делать это бессмысленно, так как LabVIEW это суперстабильная система, в отличие от других ЯП.
Я 30 лет назад использовал Clipper для базы данных клиентов центрального отопления города
И с тех пор не встречал программистов, которые хотя бы слышали о таком ЯП :)
https://ru.wikipedia.org/wiki/Clipper
До сих пор где-то лежит документация в формате Norton Guides
Позже, году в 1998-1999, эту программу переписали на Visual FoxPro
У меня до сих где-то книжка по Clipper валяется :-) Хотя когда мы в 90-х им баловались, народ таки под DOS FoxPro применялb, либо Clarion. А можно ещё dBase IV вспомнить
Тоже писал на нем.
На clipper'е не писал, но пересекался с людьми, которые переходили с него на clarion. Вот на clarion'е я уже сам писал ;)
del
Гм... Четверть века назад я программил на заводе. И написали тогда крохотным коллективом из пары человек немаленькую программу на Клиппере. "Расчёт полной себестоимости изделия". Там было всё: загрузка станков, технологические карты, износ инструмента, нормочасы, стоимость покупных изделий и прочее (уже не помню за давностью лет). Потом мы оттуда уволились и пришедшие после нас решили это переписать на C++ (мы как раз после Клиппера перешли на C++ Builder). Писали они писали, но не смогли. После них пришли ещё более новые и лучшие люди. Знающие SOLID, паттерны и прочее. Эти уже писали на С#. Но когда я последний раз общался с людьми с завода - там всё ещё работала клипперовская программа.
Вообще, на Rebol тоже одну небольшую программулинку написал. Там у него работа с электронной почтой и прочие сетевые дела прям в язык встроены. А мне как раз это и надо было. Уложился строк в 30.
Кобол застал. Но уже на излёте. После него Клиппер просто в радость был.
На REXX для PC-DOS и OS/2 всякую мелкую автоматизацию делал. Когда перешёл на Windows - заменил на Tcl.
А GPSS кто-нибудь помнит?
У нас (страховая компания) до сих пор большая часть кода на COBOL, хотя все новое пишется преимущественно на Java. Несмотря на поставленную цель отказаться от старых программ, поддерживать нам их придётся ещё немало лет.
А ещё у нас до недавнего времени был математический модуль на APL...
Мы в институте 4 года назад писали на GPSS.
GPSS кто-нибудь помнит?
Как же, как же...
Система Симуляции Генерала Пурпоса! :)))
На ЕСках лабы на ней делали :)))
Да ладно не слышали. Сталкивался на первой "программистской" работе с ним. Там на нем была написана система торгов на товарной бирже. Это где-то 91-93 годы...
Еще сталкивался (немного) с Clarion (еще под DOS).
Строго говоря, клиппер никогда не был "языком программирования". Это был компилятор для дибейса (и при доработке напильником - любого иного х-бейс ЯП). В отличие от интерпретаторов - он создавал exe-файл, который мог запустить пользователь, и не требовал "лишней" оболочки.
Ну... Я сейчас не помню как там тот exe был организован... Но в свое время был такой Turbo Basic от борланда. Он тоже генерировал exe файл в котором... Правильно - был интерпретатор BASIC + текст программы в виде данных :-)
Возможно, Клиппер примерно так же работал.
Эх, а я так хотел экзешник сделать в майкрософт бейсике, который вместе с досом шёл, но так и не смог...
Правильно - был интерпретатор BASIC
Turbo Basic – более-менее компилятор, не просто интерпретатор с обёрткой.
Возможно, там был некий байт-код. Но какой-то интерпретатор там все-таки зашивался внутрь... Потому что exe-шники получались достаточно объемные
Я такой, первая работа, за которую заплатили живые деньги, студенту (очень, очень давно, в забытой вселенной) Порог вхождения низкий, библиотека готовых форм приличная - обертка вокруг базы пишется за неделю.
(x)Harbour живее всех живых :)
Ну почему же, мы на нем СУБД регистрации транспортных средств в своё время писали. Для тогда ещё ГАИ.
Я слышал о таком ЯП и даже немного писал )
Я во времена своего студенчества, году в 1994, работал в фирме, котграя автоматизировала всякие бухгалтерии и учёты как рез на Clipper'е :)
Тогда уже было понятно, что надо переходить на что-то более другое под Windows... Но текущие заказы надо было доделывать, да и за несколько лет уже немало кода понаписано было... В общем своё так и не рискнули начать пилить новое, а потом на внедрение "Галактики" и 1С ушли...
Я на клиппере медицинскую систему писал лет 30 назад
Я тоже на нем написал несколько приложений. Одно достаточно сложное было для учета зерна на элеваторе.
Писать о популярности того или иного ЯП немного бессмысленно в отрыве от инструментов разработки и рантайма. Например COBOL (предполагается что это IBM COBOL) жив не потому что незаменим (как раз все что получалось перетащить уже перетащили интеграторы), а потому что компилятор, библиотеки, ос и железо проприетарны. Если не можешь съехать с рантайма стоимостью в полмиллиона, то синтаксис программы это самая маленькая проблема.
В позапрошлом году вот такой съезд проектировал. Я делал маленькую часть, а в целом проект в очень большие трудозатраты выливался, - и это при условии, что там ни особых вычислений, ни какой-то крутой математики не было.
Зато реализация приложения на коболе любо дорого посмотреть. Хоть в музей отдавай.
Например, стоимость замены старой инфраструктуры на новую обошлась одному из крупных банков Австралии в $749,9 млн.
Это про переход с Кобола на Джаву было, емнис. так что ещё вопрос, что дешевле.
С таких платформ съехать крайне сложно. Обычно это очень большие системы с большими объемами данных и логики и куда-то с них мигрировать - значит написать всю логику заново с нуля, потом перетащит все данные, провести полный ретест всей системы и убедиться что оно работает как минимум не хуже (по производительности). Это огромные затраты ресурсов (денег, времени) при том, что положительный результат (что оно будет дешевле и при этом без потери производительности и надежности) не гарантирован.
Немного «позанудствую» с точки зрения написания текста.
« Да, вот еще одна причина вымирания — язык внес в программирование что-то классное, его идеи получили признание, но сам сгинул.»
Звучит крайне нелогично и странно, то, что из языка были позаимствованы фичи в другие языки, никак не может быть причиной его вымирания.
Формулировка, конечно, корявая. Но в целом - вполне рабочая схема. Язык заносит какую-то классную фичу, конкуренты ее воспроизводят. А дальше либо языку есть что предложить сверх этой фичи, либо он становится не нужен, потому что все его киллер-фичи уже есть в конкурирующих языках.
В целом достаточно много языков так и вымерло, оставив по себе память в виде фич, осевших в других языках.
Ну почему, может.
Вот Scala - в какой-то момент у нее популярность поперла вверх, так как Java стагнировала, а многим разработчикам (и мне в том числе) нужен был язык, работающий на JVM, имеющий простой интероп с джавой, и при этом имеющий все новые популярные фишки типа функциональщины-лямбд, которые были на тот момент уже во многих других языках.
Саму по себе Скалу я считаю плохим переусложненным языком с неконсистентным синтаксисом и посредственным тулингом, но наличие в ней этих удобных фич позволяло мириться с темной стороной этого языка.
Но постепенно все клевые фичи все-таки перешли и в джаву, а Scala, как по мне, после этого стала просто не нужна. А потом еще и Kotlin появился, где весь этот синтаксический сахар довели до ума.
В итоге когда все фичи нишевого языка появляются в других более мейнстримных языках, пропадает всякий смысл его использовать дальше. Так как уникальность его фич была единственной причиной его изучать, во всем остальном нишевые языки всегда хуже с точки зрения их полезности как для компаний, так и для разработчиков - меньше вакансий, меньше фреймворков, меньше гайдов и туториалов, меньше готовых решений, меньше потенциальных сотрудников.
А ещё было прикольно примерно на таком модуле отладочные программы вводить на СМ-1420 :-) Пишешь на ассемблере, потом в двоичный код переводишь и кнопками щёлкаешь :-) В частности для тестирования накопителей ЕС 5061. Приятно вспомнить те старые времена
Спасибо за фото из молодости! А до этого был Вычислительный Комплекс М5000 с выключателями П2К и лампочками вместо СИДов и перфокарточный ввод-вывод. А диск(Ф ок.50см), если не читался, мыли тряпочкой со спиртом. А потом приобрели ЭБМ Искра-555. Это уже был не "мебельный гарнитур" (по занимаемой площади), а только двухтумбовый стол, и программировался он на языке ЯМБ. Я впервые (ок.1985г.) получил свободный (сервис-) доступ к Машине! Машина "научилась" давать тесты "на совместимость характеров", писать: "Прошу заменить оператора!". Но верхом моих усилий стала игра "Жизнь"(известная всем), вычитанная в журнале "Наука и Жизнь" и переведенная на ЯМБ. Дальше я "ушел" в электронику.
Да уж. Была в 80-х такая система (кстати, очень классная для тех времен) MicroPower Pascal. Хост на PDP-11 (у меня СМ-1420 была), построенный образ заливался по последовательной кишке в младшие модели, Э60 или подобные. Помню, целый день, обложившись распечатками исходников, с этого самого пульта искал, почему RSX на хосте крэшится при попытке залития образа. Нашел забытое слово в стеке в драйвере терминала. Эх, молодость)
У нас как-то сбой по ОЗУ был (если правильно помню 2 платы было, по несколько рядов в каждой), пришлось с этого пульта искать проблему, также по исходникам искал. Нашёл линейку которая сбоила (по моему из 8 микросхем ряд), далее паяльник :-) Благо дохлая оказалась 2 или 3 микросхема.
Я уже в другой город перебрался когда машины списали. Рассказывали, что когда на лом отдали и приехала некая контора забирать, модули, платы вырывали, ногами выпинывали. Ребята говорили что сердце кровью обливалось когда такой вандализм видели. Мы же к машинам чуть не с нежностью относились, они практически в идеальном состоянии были, а тут такое.
Пишу на Clarion. Считаю что язык умер. Но пишу )
Такая статья и так мало перечислено..
Начать с языка Ада .. он ещё жив, уже мертв, или его время ещё не пришло? Кто пишет на нем?
Далее, семейство Паскаля .. Оберон он где-то применяется? Что на нём пишут из нового? Модулу, ладно помянул.
Рапира, Рая .. как с ними? А ведь "школьница" была очень передовым ПО в некоторых местах (dll на дискетках)
Парадокс, которому посвятил года 3 своей жизни, где? Пациент жив или мертв или "одно из трёх"? А ведь интересное изделие было..
После Си и плюсов был такой язык "D" и? )
Под напрячься, можно ещё с десяток вспомнить, на чем работал.. да хоть тотже PL/1..
Ещё забыли:
FoxPro - поддержка прекращена в 2015-м
Clipper - не обновлялся с 1997-го, перестали продавать в 2017-м
Ceylon - окончательно закрыли в 2023-м
Nemerle - забросили в районе 2017-го (а жаль, крутой был язык от русского разработчика)
После Си и плюсов был такой язык "D" и? )
Там был ещё и C--
А D пока вполне жив: https://dlang.org/changelog/2.110.0.html
A Forth жив?
Пока ядро FreeBSD загружается им — явно не мёртв.
Forth жив просто потому, что написать реализацию под новую платформу может один человек за несколько вечеров.
Начать с языка Ада .. он ещё жив, уже мертв, или его время ещё не пришло? Кто пишет на нем?
Жив! Но, не самостоятельно, а как часть другого языка: PL/SQL = SQL + Ada
Жив! Но, не самостоятельно, а как часть другого языка: PL/SQL = SQL + Ada
То есть примерно как неандертальцы в наши дни.
Да, я купленную когда-то книгу "язык Ada" подарил программистам на pl/sql + Oracle Forms. Им оно нафиг не надо, но точно описывает работу в Oracle Forms.
А ещё я видел фаната Ada. Сайтики в свободное от работы время клепал. Когда он узнал, как звучит название любимого языка программирования на русском (он швед) - долго смеялся...
да хоть тотже PL/1..
Вроде, как и COBOL живёт на мейнфреймах, а пишут код пенисионеры.
Ну, как "пенсионеры"... Три года назад ко мне подкатывали люди с предложением "ты же в детстве на коболе писал, давай возглавишь подразделение по поддержке кобольных финсистем, а то ЖИВЫХ РАЗРАБОВ не осталось".
А вот LLM хорошо знают COBOL ;)
Там обычно проблема не в самом языке. Эти языки (типа COBOL, RPG) сами по себе достаточно простые (даже у учетом специфического синтаксиса COBOL).
Там проблема в платформах на которых они работают. Это сильно не десктопы. Это ближе к "большим машинам". Там всегда надо понимать, что все что ты делаешь (неважно - в фоне твоя программа работает или ты в интерактиве в терминале), ты делаешь в рамках задания (job). Которе работает наравне с кучей других заданий и полностью от них изолировано. И есть различные сущность, связанные с заданием - JOBLOG (протокол задания), очередь сообщений задания и т.п. Есть средства коммуникации между заданиями. В той же AS/400 внутри задания еще есть "группы активации" (activation group) и каждая программа работает внутри группы активации...
В общем, там много тонкостей и хитростей в плане чтобы все это работало максимально эффективно, которые требуют понимания как работает платформа в целом.
Ну и плюс там может быть реализована достаточно хитрая логика. И хорошо если она документирована... А если нет, то проблема уже опять не в языке, а в том, что никто не знает как оно работает :-)
Незаслуженно был забыт любимый многими YoptaScript
Я в таких статьях всегда упоминаю Inform 7.
Пример кода
Да, это именно исполняемый код, ещё и с тестом
The Editor's Office is a room. The desk is a supporter in the Editor's Office.
A red pencil is a kind of thing. 12 red pencils are on the desk.
A letter is a kind of thing. 12 letters are on the desk. Understand "correspondence" as a letter.
Rule for printing the plural name of a letter:
if the listing group size is greater than 7, say "correspondence";
otherwise say "letters".
Rule for printing a number of something (called the target) when the listing group size is greater than 7:
say "[one of]some [or]various [or]an assortment of [at random]";
carry out the printing the plural name activity with the target.
Rule for printing a number of red pencils (called the target) when the listing group size is greater than 10:
carry out the printing the plural name activity with the target;
say " in nearly-sufficient quantity".
Test me with "get two letters / look / get a pencil / i / get pencil / g / g / look / i / get all / i".
Забавно, но это уже ближе к Brainfuck. А на Inform написаны тысячи игр, некоторые на десятки часов геймплея, некоторые - коммерческие серии, так что его применимость на практике можно считать доказанной.
это уже ближе к Brainfuck
Полная противоположность - Inform 7 был сделан для того, чтобы писать максимально читаемый код для Z машины.
Brainfuck был создан вовсе не для того, что сделать код максимально нечитаемым. На самом деле при правильном форматировании и комментировании (а всё, что не является одной из 8 инструкций - это комментарий), код на BF вполне себе читаем.
Brainfuck был создан как proof-of-concept, что для полноты по Тьюрингу достаточно всего 8 операций. И даже это оказалось избыточным, есть модификации с меньшим количеством инструкций, есть самостоятельные языки с одной (или нулём) инструкций.
Код на C или JS, написанный в одну строчку, тоже сложно читать.
Но если сгруппировать одинаковые инструкции (плюсы с плюсами, стрелочки со стрелочками) в отдельной строке, сделать отступы для квадратных скобок, то понимать BF будет проще. Хотя, конечно, отсутствие нормальных идентификаторов и зависимость от контекста усложняют читабельность.
Ну и да, написать комментариев больше, чем кода, благо мы может вообще писать комментарии слева, а код где-нибудь справа.
Есть ещё один забавный момент. Так как всё, что не является инструкцией, игнорируется, очень легко писать код-полиглот, который одновременно будет валидным кодом и на BF, и на каком-нибудь другом языке (например, JS).
С удивлением узнал, что objective-c помер, а в 1988 уже была ява)
Objective-c живее всех живых. Работа с сырой памятью в swifte это сплошной ад. Все низкоуровневые либы и драйвера и даже ядро mac/ios на objective-c/c++.
Эта история напоминает холивар rust <-> c в linux, где тоже пытаются сишку хоронить.
Есть еще x++. Конкурент Кобола. Пока жив.
Интересно, LaTeX можно считать ЯП?
APL сам по себе был нишевым и сложным, поэтому не прижился. APL2 использовал нестандартные символы и требовал особой клавиатуры, из-за чего программисты просто не хотели с ним работать.
Я хотел, но его было нигде не достать. :-(
В 1988 мир переходил на java. А ничего что java ещё не было?
Только Turbo Pascal 5.5.
Только хардкор.
Microsoft J++. Я был настолько темный, что начал было разбираться с ним, решив, что это и есть пресловутая Java )) Не пинайте, это был 1998, интернет был крайне ограничен, а по английски я знал буквально yes и no.
Был ещё Microsoft J#.
И JScript, который был похож на JavaScript, но со своими плюшками. Написал на нем пару сотен строк однажды, для десктопной программы. Это был 2009-2010 примерно. С тех пор я больше его никогда не встречал.
Да, я на нём тоже примерно в 2008-2009гг случайно написал бэкенд для деплоя сервисов на удалённые Windows-сервера.
На самом деле, довольно удобный был язык - лучше чем VBScript, на мой взгляд. Потом Microsoft его убила и был довольно большой период до тех пор пока powershell не дорос до чего-то юзабельного.
Странно включать в список "мертвых" эзотерические языки. Причем INTERCAL включили, а BrainFuck нет.
У нас в лаборатории есть свой весьма популярный в узких кругах язык программирования - названия правда нет, при помощи него управляем координатником и АЦП. Всё собираюсь статью про него написать.
MODULE HelloWorld;
IMPORT Io;
BEGIN IO.Put ("Hello World\n")
END HelloWorld.
Это не Modula-3, а Modula-2! Стыдно не знать! ))
Я начинал на TopSpeed Modula-2. Чумовой компилятор!
Modula-3 (Oberon compiler + Oberon OS) это уже другой уровень - последнее дыхание господина Н.Вирта. Если бы не его (Вирта) почтенный возраст, возможно Linux бы не занимал такое место, как сейчас. Тогда правили бал не маркетологи, а математики..
Блин, сколько нас тут таких - винтажных газогенераторов...
В общем-то, вот актуальный вариант для cm3 Modula-3 ( единственная активно поддерживаемая реализация Modula-3):MODULE Helloutf8 EXPORTS Main;
IMPORT IO;
BEGIN
IO.Put ("ЭКС-ГРАФ? ПЛЮШ ИЗЪЯТ. БЬЁМ ЧУЖДЫЙ ЦЕН ХВОЩ!\n");
IO.Put ("Экс-граф? Плюш изъят. Бьём чуждый цен хвощ!\n");
IO.Put ("экс-граф? плюш изъят. бьём чуждый цен хвощ!\n");
END Helloutf8.
P.S. Искусственный интеллект, кстати, уверен что:
Текущее состояние
Поддержка: Проект поддерживается небольшим сообществом энтузиастов. Основной репозиторий находится на GitHub: CM3 GitHub.
Активность: Периодические обновления (последние коммиты в 2022–2024 гг.)
Поддерживает Linux, MacOS, Windows ( нативно и через Cygwin), BSD.
Генерирует нативный код для различных архитектур (x86, ARM и др.).
Интересно, а JCL ещё жив?
Скриптовый язык в Macromedia Flash 4. Минималистичный. Еще до появления более-менее полноценного ActionScript.
Код вводился (точнее создавался) путем выбора команд в интерфейсе - привет специальной клавиатуре. Набрать код вручную и скопировать было нельзя. Точнее можно было купить за непозволительные в 99 году $$ утилиту подставлявшую в буфер спецсимволы с которыми можно было вставить код из текстового редактора.
Но в итоге на нем делали шедевральные вещи.
FOCAL - кто-нибудь из олдов помнит?
Мой первый ЯП на ПЛОС - перфоленточной операционной системе для ЭВМ "ЭЛЕКТРОНИКА-100И" (клон PDP-8)
Я помню :-) Немного писал на нём недавно :-)
Фокал БК-0010-01. Basic кажется был во внешнем модуле?
Пришлось из-за тормознутости учить Assembler.
О, да!
Рекурсия (для подобного это круто) и возможность создавать программы, которые нельзя посмотреть стандартным способом :D
В школе пописывал.
Это примерно такая же катастрофа, как и Dartmuth BASIC :)
Есть ещё такая странная штука, как Haxe
Внутри – наследие почившего Flash в виде ActionScript
Одна из фишек – перевод написанного в код на десятке языков и stdlib, которая их пытается подружить
Некий кроссязыковой common ground, написал либу один раз – используешь в разных языках
Используется где-то в геймдеве, вроде, но судя по всему тоже подыхает
Плюс сейчас ИИ помогает делать примерно то же самое с помощью молитв и угроз "сделай мне красиво" вообще без кода, по туманным словесным спецификациям
На Планкалкюле я написал небольшую программу в 2011-м :-)
А кто-нибудь на Prolog писал? Жив он еще?
Ну я писал, да и пишу иногда. Жив, конечно — в этой области ничего столь же проработанного, со столь же удобными инструментами нет. Из родственного — Curry, Verse (в Фортнайте), но это надо на шкаф залезать.
Урезанный Prolog (то есть, Datalog) с диким синтаксисом находится во многих экспертных системах, даже если авторы об этом и не подозревают. Поэтому если хочется ловко писать на этих встроенных DSL, полезно поиграться с Prolog'ом, т.к. тот же SWI-Prolog отлично интегрирован в VS Code.
Я в студенческие годы писал на трубо-Прологе. :-)
А вот, APL и Лисп попробовать, увы, не довелось. :-(
Писал только на Turbo Prolog. Он сильно отличался (в худшую сторону) от того диалекта, о котором я читал в книжке.
Ждал-ждал упоминания REXX, и так не дождался. Сам на нём не писал.
В статье говорится про язык Ark (https://github.com/ark-lang), а ссылка на Arc (который типа Lisp), или опечатка?
Языки программирования основываются на железе. Сравнивать Бэсик или Фортран или Паскаль с Питоном или сишками это глупо слишком сильно развитие прогресса. Потом, есть низкоуровневые компиляторы которые работают на уровне командных задач процессору, короче статься ни о чем.
В статье ошибка про язык S. Он не имеет отношения к Perl. Это родоначальник языка R, который сейчас очень даже живой и используемый. Я преподаю R в ВШЭ.
Microsoft J++ (1996)
Попытка Microsoft создать свою версию Java. Поддержка прекращена после судебного процесса с Sun Microsystems.
Почему-то в моей голове это был J#
Никак не упомянут Пролог. Жив ли ещё.
Странно, что никто не вспомнил про Пролог. А ведь по-своему уникальный язык
Ещё не упомянуты макроассемблеры, которые оптимизирующие компиляторы С в области разработки ПО для микроконтроллеров, фактически, похоронили.
@Kotofay, @brownfox, @SpiderEkb а вот кому тут пролога свеженького?
-- из не упомянутого --
ActionScript забыли упомянуть (Flash - это платформа). AS3 и так и не ушедший дальше драфта AS4 очень сильно повлияли и на JS, на TS.
CoffeeScript - прикольная надстройка над JS, сильно выигрывает в codegolf, но крайне сложен в поддержке - пропустил где-то один символ, и будешь три дня искать, поэтому не прижился.
Стрелочные функции в JS пришли именно из CoffeeScript.
-- из упомянутого --
INTERCAL создавался как прикол, но его можно считать прародителем эзотерических языков программирования, а значит детей и внуков у него больше, чем у любого другого ЯП.
Curl, если верить слухам, имел какую-то очень странную лицензию. Нужно было то ли платить за каждый сайт, созданный на нём, то ли вообще за каждую компиляцию. Жадность создателей его сгубила.
Unlambda, как и Brainfuck, и некоторые другие эзотерические языки, обладает полнотой по Тьюрингу при супер-минималистичном синтаксисе. Такие языки часто используются для доказательства полноты по Тьюрингу новых языков или концепций. Например, если можно реализовать Unlambda с помощью системы типов TypeScript, или с помощью карт Magic the Gathering, или с помощью языка, который вы только что придумали, следовательно, они тоже обладают полнотой по Тьюрингу.
На Cobol'е довольно сносно пишет Grok (ChatGPT и DeepSeek не проверял, но думаю, что тоже), поэтому довольно скоро кожаные программисты вымрут, и ИИ будет единственным, кто сможет поддерживать банковский и биржевой софт. Вот тут-то Скайнет и похохочет.
К сожалению, ChatGPT может сыграть злую шутку. Я писал про это (относительно RPG) тут (там можно промотать до картинок сразу и подняться чуть вверх к "Операции чтения записи")
Т.е. формально код правильный, но неэффективный.
Ох, зачем вытягивать на арену экзотические языки?
Покажите C++ код программисту, который пишет на одном подмножестве языка C++ другому программисту, который пишет на другом подмножестве этого же языка. И они друг друга не поймут.
Вот где жесть жестяная.
Кстати, Rust это тоже касается: https://habr.com/ru/articles/578198/
Из популярных языков в свое время, на которых я программировал, к мертвым я бы отнес VBScript и Forth.
Благодаря Эффекту Линди нам, заматерелым C-программистам, похоронить свой любимый язык не грозит. И вам не удастся :)
А Пролог и Ада еще живы?)
Пролог живой. Не далее как вчера статья была - решение задачи Эйнштейна на Prolog На мой взгляд красиво...
Ада жива в составе PL/SQL = SQL + Ada.
рефал был очень забавный язык... производные в нем можно было считать прямо в текстовом виде )) И еще был АлМир с его "устанавливаю точность вычислений 100 знаков после запятой" ))
Ну раз тут неоднократно упоминалась IBM...
На AS/400 (iSeries, IBM i) есть такой язык - CL (Control Language)
Интересен тем, что с одной стороны, команды этого языка есть средство общения с системой. Т.е. в терминале в интерактиве работаешь этими командами (а их там... Референс по командам - 2300 страниц в pdf). А с другой стороны на нем можно писать программы. С винтом и профурсетками типизированными переменными, циклами и всем вот этим вот. Причем, это будут полноценные компилируемые программы. А компиляция производится командой того же CL - CRTBNDCL :-)
Более того, этот язык входит в упоминавшееся тут выше ILE наряду с С/С++, RPG и COBOL.
Пример кода
PGM PARM(&TYPE)
/* ---------------------------------------------------------------------*/
/* &TYPE='B' Создает в QTEMP файл SEAPF */
/* Делает оверрайд на него. */
/* &TYPE='S' Создает в QTEMP файл HZSEA3 (замена BUFFSFL) и */
/* делает на него оверрайд. */
/* &TYPE='E' Удаляет оверрайды на файлы. */
/* ---------------------------------------------------------------------*/
DCL VAR(&TYPE) TYPE(*CHAR) LEN(1)
IF COND(&TYPE *EQ 'B') THEN(DO)
DLTOVR FILE(SEAPF) LVL(*JOB)
MONMSG MSGID(CPF9841)
CHKOBJ OBJ(QTEMP/YL2PF) OBJTYPE(*FILE)
MONMSG MSGID(CPF9801) EXEC(GOTO CMDLBL(CRTPF))
CLRPFM FILE(QTEMP/SEAPF)
GOTO OVR
CRTPF:
DLTF FILE(QTEMP/SEAPF)
MONMSG MSGID(CPF2105)
CRTDUPOBJ OBJ(SEAPF) FROMLIB(*LIBL) OBJTYPE(*FILE) +
TOLIB(QTEMP) NEWOBJ(SEAPF) DATA(*NO)
OVR:
OVRDBF FILE(SEAPF) TOFILE(QTEMP/SEAPF) +
OVRSCOPE(*JOB)
GOTO CMDLBL(END)
ENDDO
IF COND(&TYPE *EQ 'S') THEN(DO)
CRTDUPOBJ OBJ(HZSEA3) FROMLIB(*LIBL) OBJTYPE(*FILE) +
TOLIB(QTEMP) NEWOBJ(HZSEA3) DATA(*NO)
MONMSG MSGID(CPF2130) EXEC(CLRPFM FILE(QTEMP/HZSEA3))
OVRDBF FILE(HZSEA3) TOFILE(QTEMP/HZSEA3) +
OVRSCOPE(*JOB) SEQONLY(*NO)
GOTO CMDLBL(END)
ENDDO
IF COND(&TYPE *EQ 'E') THEN(DO)
DLTOVR FILE(SEAPF) LVL(*JOB)
MONMSG MSGID(CPF9999)
DLTOVR FILE(HZSEA3) LVL(*JOB)
MONMSG MSGID(CPF9999)
ENDDO
END:
ENDPGMУ нас используется в основном сопровождением - они всякие небольшие программки на нем пишут для запуска разных процессов и т.п.
Ну и основное - инсталлятор поставок. Наша система сборки по gradle скриптам автоматически генерирует программу-инсталлятор на CL. Для развертывания поставки достаточно просто скомпилировать и запустить инсталлятор, дальше он уже все сам делает.
Еще интересное - CL позволяет создавать свои команды. Т.е. если есть какая-то программа, ее можно "обернуть" в команду CL
Например, есть программа на RPG, которая создает "пользовательскую очередь" - UserQueue, *USRQ. Интерфейс у нее такой:
// --------------------------------------------------
// Prototype for main procedure
// --------------------------------------------------
dcl-proc CRTUSRQPGM;
dcl-pi *n;
dsQName likeds(t_dsQName);
MaxLen uns(5);
Descr char(50);
Seq char(1);
KeyLen uns(5);
dsSize likeds(t_dsSize);
ReCreate char(1);
end-pi ;Нам надо создать команду CL - CRTUSRQ
Для этого пишется описнаие команды
CMD PROMPT('Create User Queue')
PARM KWD(USRQ) TYPE(USRQNAM) MIN(1) +
PROMPT('User queue name')
USRQNAM: QUAL TYPE(*NAME) LEN(10)
QUAL TYPE(*NAME) LEN(10) +
PROMPT('Library')
PARM KWD(MAXLEN) TYPE(*UINT2) RANGE(1 63948) +
MIN(1) PROMPT('Maximum entry data length')
PARM KWD(DESC) TYPE(*CHAR) LEN(50) +
PROMPT('Description')
PARM KWD(SEQ) TYPE(*CHAR) LEN(6) RSTD(*YES) +
DFT(*FIFO) +
SPCVAL((*FIFO F) (*LIFO L) (*KEYED K)) +
PROMPT('Queue type')
PARM KWD(KEYLEN) TYPE(*UINT2) +
RANGE(1 256) SPCVAL((*NONE 0)) +
DFT(*NONE) PROMPT('Entry key length')
PARM KWD(SIZE) TYPE(USRQSZ) +
PROMPT('Queue size')
USRQSZ: ELEM TYPE(*INT4) +
SPCVAL((*MAX -2)) +
DFT(*MAX) +
PROMPT('Maximum entries')
ELEM TYPE(*INT4) DFT(16) +
PROMPT('Initial entries')
ELEM TYPE(*INT4) DFT(16) +
PROMPT('Extention size')
PARM KWD(RCRT) TYPE(*CHAR) LEN(4) RSTD(*YES) +
DFT(*NO) +
SPCVAL((*YES Y) (*NO N)) +
PROMPT('Delete if exist?')В которой описываются все параметры (обязательные, необязательные, значений по умолчанию для необязательных.... А дальше командой CL создаем новую команду того же CL :-)
CRTCMD CMD(&ALIB/CRTUSRQ) PGM(*LIBL/CRTUSRQPGM) SRCFILE(&ASRC/&SRCF) SRCMBR(CRTUSRQ) TEXT('Создание USRQ') HLPPNLGRP(*LIBL/CRTUSRQPNL) HLPID(*CMD) MSGF(*LIBL/KSMMSGF)Тут еще упоминается CRTUSRQPNL - это нечто типа Help по команде. Дело в том, что когда команда используется в интерактиве и пользователь не ввел все обязательные параметры, система автоматически выводит интерфейс для ввода параметров
где будут отмечены обязательные параметры, а для необязательных установлены дефолтные значения.
При нажатии на F1 получаем контекстную подсказку
Вот так легко и просто можно создать новую команду являющуюся интерфейсом к программе.
По стилю ключевых слов сразу видно, что создано в IBM. CRTDUPOBJ, OVRDBF - это EBCDIC какой то )
На самом деле это единый стиль именования команд. С четкой логикой.
CRTDUPOBJ - Create Duplicated Object - создать копию (дубликат) объекта
WRKOBJ - Work with Object - работа с объектом
WRKACTJOB - Work with Active Jobs - работа с активными (в данный момент) заданиями
WRKUSRJOB - Work with User Job - работа с заданиями указанного пользователя
OVRDBF - Override DataBase File [properties] - изменение свойств файла БД
И так далее. К этому очень быстро привыкаешь. И это реально удобно. Всегда знаешь что все что CRT... - это создание, WRK... - работа с... DLT... - удаление EDT... - редактирование и т.п.
В этом плане здесь все логично и единообразно. Система цельная, нет ощущения сборной солянки. И любую команду можно легко найти - есть команда для поиска команд :-) SLTCMD (Select Command)
Интересуют команды создания. Вводим "все что начинается на CRT*" и получаем
Находим, например, "создать очередь данных", выбираем
и оказываемся в нужной команде
Все просто, логично и удобно
Соглашусь, что если привыкнуть, читать и писать легко, но после C/C++ воспринимается сложно (хотя они, конечно, тоже не образец читабельности).
К этому очень быстро привыкаешь и потом уже понимаешь что не нужно запомнить все 100500 (а их реально очень много) команд (только системных, не считая того что там еще сами наделали) - все можно найти просто зная чего ты хочешь.
И что не надо запоминать все параметры (а их может быть очень много). Можно просто ввести команду без параметров и получить интерфейс где будет видно все - что обязательно, что будет по умолчанию подставляться...
Я подозреваю, что на первые месяцы желателен кто-то под рукой, кто может помочь с простыми вещами. Кто расскажет про внутреннюю логику, как вы сейчас. Ну хотя бы, что она, эта логика, есть.
У нас стандартный онбординг подразумевает первые 3 месяца "испытательный срок", который на самом деле суть обучение (т.е. я не знаю людей, которые его не прошли бы - это надо быть или конченым м...ком чтобы команда сказала что "с таким не сработаемся никак", или самому понять что тебе все это не нужно). При этом за полную з/п, отсчет отпуска с первого дня и т.п. Только ДМС и НС оформляется после.
Есть программа обучения - набор задачек от простого к сложному, есть наставник (кто-то из команды, но обратиться можно к любому - всегда помогут). Так что стараемся чтобы человеку было попроще во все это вникать - нам же потом с ним работать.
В реальности человек через полтора-два месяца уже способен решать несложные реальные задачи. Остальное уже походу познается. Опять же, при распределении задач уровень человека все-таки учитывается. И сразу ничего сверхсложного никто не даст.
Т.е. мы не ищем людей, кто сразу все это знает - их мало. Но лучше если у человека уже есть опыт разработки - таким легче вникать во все это.
Я вот пришел с "анамнезом" в 25+ лет работы на С/С++ (если честно, С нравится больше плюсов до сих пор)... Первый месяц, конечно, очень тяжело т.к. очень много нового. Потом легче уже.
Напомнило советское "СТ ПОФ".
Написать свой простой язык для решения какой то своей нишевой задачи это в общем хорошая идея. Мне удалось такой язык придумать для управления стендами тестирования датчиков. Основа его - база данных. В профиле есть статья где я кратко описываю его как язык табличного скрипта. В операторе теста (номер операции) используется всего 2 параметра и программирование теста не напрягает. Главное надо было правильно разбить процессы на операторы языка, не мелко и не грубо. Мелко слишком затратно программировать, грубо - недостаток гибкости программирования. Золотая середина была найдена. В общем на нем реализовано уже около 100 тестов для LABVIEW в связке с SQL Server и возможностей хватает для тестирования и производства.
Такой язык имеет устоявшееся примерно лет 40 назад название: DSL.
Ну да, предметно-ориентированный. Я бы еще сказал что программно-ориентированный. Живет на 2 слонах и интерпретатор к тому же. Первые программы жили во встроенной процедуре и там же и редактировались. Но это требовало доступа к серверу и было неудобно. Потом перенес в таблицу и ввел редактирование с клиента. Редактируются только два параметра +добавление, удаление и закомментирование строки. Все ссылки, нумерация и коммментарии в программе при ее изменении генерируются автоматически. На клиенте есть контекстная помощь по операции, ее описание и параметры.
Код, который вы не поймете. Подборка вымерших языков программирования