Comments 14
Поправка. GnuCOBOL компилятором не является, он транспилит в С, который компилируется тем что есть в системе. Без расширений (диалектов), на COBOL85 написать можно разве что обработку файлов с данными фиксированной ширины. В десятичной математике, декларативной валидации и представлении язык хорош. Остальное прикручивается вызовами Сишных библиотек. В этом смысле можно и микросервис на нем собрать... Но зачем.
Ну строго говоря, да, это такая реализация языка. Поправил, спасибо.
Но зачем.
Дык он и для игрушек не предназначен, поэтому «троллейбус, буханка, джейпег». А автор в первую очередь хотел показать свою квалификацию — смотри, как я умею. Ну и отчасти явно хотел почувствовать себя игрописателем первого поколения, когда из языков выского уровня были «Кобол» да «Фортран». На чем хочешь — на том и пиши.
Кстати, на чем-то подобном и для ЕС игрушки писали, только без шикарной графики.
подрутины (subroutines)
Обычно это слово переводится как подпрограммы.
С такими знаниями может смело устраиваться на работу в какой-нибудь банк, ковырять что-то древнее.
Но по меркам 60-х и даже 70-х годов 243 КБ - это просто колоссальный объем памяти, это на каком-то очень мощном мейнфрейме только запускать. Понятно, что это чисто ради прикола - на ассемблере-то любой дурак напишет, а вот на Коболе - это надо попотеть…
Разработчик оценил легковесное ощущение Кобола, которое ему дали подпрограммы (subroutines), объявляемые в виде абзацев. Разработчик даже пожелал, чтобы схожие структуры были в других языках.
Есть такой язык - RPG. Современник COBOLа но в экосистеме коммерческих серверов IBM развивается до сих пор и развился в нормальный Паскалеподобный процедурный язык. Имеет ряд особенностей, ориентированных на коммерчески вычисления (богатый набор функций работы с датой и временем во всевозможных форматах, объявление перекрывающихся полей в структурах, типы данных с фиксированной точкой и т.п.).
Так вот в нем, несмотря на современную "процедурность" подпрограммы (сабрутины, subroutines) сохранились до сих пор. И, если первая реакция обычно достаточно негативная - "фу-у-у, как в бейсике древнем, да зачем это надо когда есть нормальные процедуры", то потом возникает понимание, что иногда использование сабрутин внутри процедур и уместно и удобно. Во-первых, это еще один способ структурирования кода, во-вторых - способ не дублировать один и тот же код кусок кода в тех случаях, когда требуется его повторение более одного раза в рамках одной процедуры.
Более того, на сабрутине там реализован перехват необработанного в рамках процедуры исключения - достаточно добавить к процедуре сабрутину со служебным именем *pssr
begsr *pssr;
// какие-то действия, связанные с исключением, например dump - вывод дампа
endsr;и будете уверены, что вылет из процедуры по необработанному по каким-то причинам исключению произойдет через эту сабрутину.
Так что в общем и целом достаточно полезная конструкция на самом деле. Даже с точки зрения структурирования кода типа такого:
select;
when Client.ClTp = 'F';
exsr srCheckF;
when Client.ClTp = 'U';
exsr srCheckU;
endsl;Если тип клиента F (физлицо) - идем по ветке обработке ФЛ, если U (юрлицо) - по ветке обработки ЮЛ. Т.е. общая канва алгоритма видна сразу, а за подробностями см. соотв. сабрутину.
Области видимости сабрутины ограничена той процедурой, в рамках которой она описана (аналогично локальным переменным). Вызов сабрутины "эконмически" более выгоден т.к. не образует лишнего уровня стека.
И да, это просто один из инструментов - в каких-то случаях лучше оформить кусок кода процедурой, а в каких-то - сабрутиной. И лучше когда выбор есть чем когда его нет.
80 символов в строке у Кобола -- это не ограничение бумажного бланка, это ограничение перфокарты. Но, честно говоря, удивлён таким использованием сего языка. Вот экономические задачи, решаемые в пакетном режиме, на нём было писать весьма приятно.
Автор игры на Коболе рассказал, что ему понравилось в языке