Не так давно мы писали о том, что один из старейших языков программирования COBOL, похоже, вскоре уйдёт с рынка. И не потому, что он неактуален, наоборот, пока что этот язык востребован, главным образом в финансовой и банковской отраслях. Всё дело в том, что ему ищут замену, точнее, способ, который позволит портировать софт, написанный на COBOL, на разные ЯП. Ранее этим занималась корпорация IBM, но теперь появились и другие возможности. В частности, свободный компилятор GnuCOBOL.

Что это за проект?

Как и говорилось выше, он называется GnuCOBOL. Команда развивала его около 20 лет, не так чтобы быстро, но всё же постоянно что-то добавляла и модифицировала. Сейчас GnuCOBOL уже можно использовать в промышленности и банковской отрасли, где, собственно, и задействован софт, написанный на COBOL.

Компилятор позволяет крупным и не очень компаниям постепенно снижать зависимость от языка, которому исполнилось уже полвека. По словам разработчиков, главное достоинство GnuCOBOL — трансляция написанной на COBOL программы в представление на языке С для дальнейшей компиляции при помощи компилятора С.

У проекта, помимо бесплатности, есть ещё одно достоинство — его можно использовать в среде разных операционных систем, включая Windows, macOS, Linux, Android, BSD и другие. Важный момент: COBOL вовсе не находится в том виде, в котором он появился, язык развивается. На сегодня насчитывается пара десятков версий, «диалектов», и с большинством из них умеет работать компилятор.

GnuCOBOL уже задействован рядом крупных компаний, многие из которых предпочитают бесплатный компилятор платным проектам. Например, один из таких вариантов — проприетарный Micro Focus, который сейчас во многом проигрывает новинке. К слову, не только коммерческие организации переходят на современные технологии.

В качестве интересного кейса можно привести и Министерство финансов Франции — ведомство отказалось от старого парка серверов и даже от мейнфрейма (о них мы недавно писали), предпочтя новое оборудование и GnuCOBOL. Всё потому, что переход на GnuCOBOL позволяет добиться повышения производительности и избавиться от привязки к одному поставщику.

Из связанных с GnuCOBOL событий также можно упомянуть публикацию первой версии интегрированной среды разработки SuperBOL Studio, написанной на языке Ocaml. Она распространяется под лицензиями AGPLv3, MIT и ISC. SuperBOL Studio представляет собой расширение к редактору кода VS Code, которое работает с GnuCOBOL. Предназначено оно главным образом для разработки, отладки и профилирования проектов на языке COBOL. SuperBOL также предоставляет реализацию сервера LSP (Language Server Protocol) для интеграции в друге IDE средств навигации, анализа и редактирования кода на языке COBOL.

Кстати, есть ещё один проект — от IBM. Корпорация разработала специальный набор инструментов по автоматическому преобразованию кода COBOL в код на Java. И это не теоретическая разработка, не proof of concept, а коммерческий инструмент, который предлагается партнёрам компании. Называется он Watsonx Code Assistant.

Код, который создаётся при помощи Watsonx Code Assistant, не станет конфликтовать с остальными системами, даже если они и устаревшие. Код объектно ориентированный, а значит будет поддерживаться совместимость как с модулями, написанными на COBOL, так и с сервисами вроде CICS, IMS, DB2.

А что с самим языком программирования?

COBOL уже больше 60 лет. Несмотря на это, он до сих пор активно используется. Конечно, в подавляющем большинстве сфер его заменили современные языки программирования. Но дело в том, что в ряде стран до сих пор работают аппаратные системы с ПО на базе этого ЯП. Особенно много их в США.

Поэтому COBOL держится на плаву и в последние несколько лет даже набирал популярность. Так, например, в августе 2023 года язык вышел на 15 место по популярности среди ЯП. Год назад он находился на 31 месте. Впечатляющий рост. Но через время, возможно, он станет уже историей.

Вот инфографика от 2017 года, созданная в рамках исследования Reuters. Конечно, прошло 7 лет, но вряд ли все эти организации и системы разом перешли на новые языки — уж слишком это дорого. Кто-то да, но большинство предпочло новому хорошо работающее и проверенное временем старое.

Проблема в том, что систем, которые написаны на старом языке, ещё много, а вот программистов, хорошо в них разбирающихся и способных что-то писать на COBOL, совсем крохи. И большинству из них около 60-70 лет. Поэтому компаниям приходится искать специалистов по всему миру.

Сейчас, надо думать, зависимость от языка будет понемногу снижаться, поскольку инструментов для перехода на другие ЯП становится всё больше. Вероятно, осталось подождать 3-5 лет, но кто знает, может, и больше.

Комментарии (11)


  1. LordDarklight
    21.03.2024 10:06
    +2

    А почему именно трансляция на Си (ЯП которому, то уже тоже читай полтинник лет) , а не на что-то более современное - Kotlin например, который и Native есть (ну на Rust было бы очень сложно) или Python (Mojo).

    ИМХО, тут бы конечно лучше выбирать систему с управляемой памятью, а-ля Java (и да в статье и про этот проект тоже пара строчек есть), но всё-таки лучше выбрать современный ЯП (XXI века), а не устаревающие нишевые ЯП. Но тут уже надо глубже понимать среду выполнения - может ли она тянуть доп CLR исполнитель или нужен чистый машинный код?

    Вот, приведённый мной вариант с Kotlin - вполне себе может и так и эдак.

    Python (с Mojo) тоже вроде как, условно, может в любой среде исполняться

    Вообще тут по сути достаточно в IR в модели LLVM компилировать - и далее уже под любое железо и среду исполнения бакэнд-комплятор сделать не проблема!

    Даже C# сейчас учится в rutime компилироваться - так что выбор его, мне кажется, тоже более перспективным чем ЯП Си

    Или я что-то не понимаю?

    Жаль не показали содержательный пример такой трансляции!

    Кстати, интересно, насколько COBOL актуален в России?


    1. Feedman
      21.03.2024 10:06

      Судя по объяснениям тут: https://habr.com/ru/companies/sberbank/articles/776650/comments/ КОБОЛ это и есть некий "финансовый С".


    1. c0r3dump
      21.03.2024 10:06
      +1

      Просто в GNU любят Си и компилировать в него, подозреваю, что для них это просто привычное решение которое они умеют.


      1. olku
        21.03.2024 10:06

        Дело не в этом. Если сравнить транслированный код с программой на Кобол, можно увидеть сниппетоподобную структуру. Просто проще.


    1. mynameco
      21.03.2024 10:06

      Там ниже нсть список платформ. Т.е. сам язык крутится видио на древних платформах. И для плавного переключения, нужен си. Но я бы транслировал не в чистый си. А в какой домен спецейик набор функций на си. Чтобы визуально быдо одинаково


    1. Gromin
      21.03.2024 10:06
      +9

      У Си позиция все еще гораздо сильнее чем у Kotlin, Mojo и многих других "ЯП XXI века". О них забудут, а на Си все еще будут писать.


    1. Rigidus
      21.03.2024 10:06
      +3

      Потому что сишное ABI - это лучший интероп на сегодняшний день


  1. Wesha
    21.03.2024 10:06
    +5

    Да, два года ждал!

    Неканонично! Джва года ждать надо было!


  1. Mmv85
    21.03.2024 10:06

    Вот интересно, а что на выходе получается? Что-то читаемое и теоретически поддерживаемое или жуткое месиво со сгенерированными именами функций и переменных?


  1. DustCn
    21.03.2024 10:06
    +1

    Да f2c если кто пользовался, получается... Лучше бы сам переписал.


  1. R0bur
    21.03.2024 10:06
    +2

    Сейчас, надо думать, зависимость от языка будет понемногу снижаться, поскольку инструментов для перехода на другие ЯП становится всё больше. Вероятно, осталось подождать 3-5 лет, но кто знает, может, и больше.

    Странно, но после беглого знакомства с GnuCOBOL 3.2 Programmers Guide у меня сложилось иное впечатление, нежели у автора этой статьи.

    Проект GnuCOBOL реализуется не для того, чтобы перейти с этого языка программирования на другой "современный", а для того, чтобы предоставить возможность выполнения программ, написанных на COBOL, на более широком спектре аппаратных платформ и операционных систем, а не только на мэйнфреймах. Об этом недвусмысленно говорит раздел "1.2.1 Why YOU Should Learn COBOL" ("Почемы Вы должны изучать COBOL"), а далее по тексту приводятся аргументы в пользу использования COBOL в его традиционной предметной области, в частности, простота изучения, читабельность программ и поддержка объектно-ориентированной парадигмы в стандартах COBOL2002 и COBOL2014.

    А то, что GnuCOBOL транслирует текст COBOL-программы в Си-программу, является только техническим элементом: The GnuCOBOL compiler generates C code from your COBOL source programs; that C code is then automatically compiled and linked using your system’s C compiler (typically, but not limited to, gcc).

    Компилятор позволяет крупным и не очень компаниям постепенно снижать зависимость от языка, которому исполнилось уже полвека

    Это надо понимать не как зависимость от языка COBOL, а как зависимость от конкретных реализаций трансляторов с языка COBOL (всё тех же мэйнфреймов).