Комментарии 11
А почему именно трансляция на Си (ЯП которому, то уже тоже читай полтинник лет) , а не на что-то более современное - Kotlin например, который и Native есть (ну на Rust было бы очень сложно) или Python (Mojo).
ИМХО, тут бы конечно лучше выбирать систему с управляемой памятью, а-ля Java (и да в статье и про этот проект тоже пара строчек есть), но всё-таки лучше выбрать современный ЯП (XXI века), а не устаревающие нишевые ЯП. Но тут уже надо глубже понимать среду выполнения - может ли она тянуть доп CLR исполнитель или нужен чистый машинный код?
Вот, приведённый мной вариант с Kotlin - вполне себе может и так и эдак.
Python (с Mojo) тоже вроде как, условно, может в любой среде исполняться
Вообще тут по сути достаточно в IR в модели LLVM компилировать - и далее уже под любое железо и среду исполнения бакэнд-комплятор сделать не проблема!
Даже C# сейчас учится в rutime компилироваться - так что выбор его, мне кажется, тоже более перспективным чем ЯП Си
Или я что-то не понимаю?
Жаль не показали содержательный пример такой трансляции!
Кстати, интересно, насколько COBOL актуален в России?
Судя по объяснениям тут: https://habr.com/ru/companies/sberbank/articles/776650/comments/ КОБОЛ это и есть некий "финансовый С".
Просто в GNU любят Си и компилировать в него, подозреваю, что для них это просто привычное решение которое они умеют.
Там ниже нсть список платформ. Т.е. сам язык крутится видио на древних платформах. И для плавного переключения, нужен си. Но я бы транслировал не в чистый си. А в какой домен спецейик набор функций на си. Чтобы визуально быдо одинаково
У Си позиция все еще гораздо сильнее чем у Kotlin, Mojo и многих других "ЯП XXI века". О них забудут, а на Си все еще будут писать.
Потому что сишное ABI - это лучший интероп на сегодняшний день
Да, два года ждал!
Неканонично! Джва года ждать надо было!
Вот интересно, а что на выходе получается? Что-то читаемое и теоретически поддерживаемое или жуткое месиво со сгенерированными именами функций и переменных?
Да f2c если кто пользовался, получается... Лучше бы сам переписал.
Сейчас, надо думать, зависимость от языка будет понемногу снижаться, поскольку инструментов для перехода на другие ЯП становится всё больше. Вероятно, осталось подождать 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 (всё тех же мэйнфреймов).
Специалисты по COBOL теперь не нужны? Появился свободный компилятор, который снижает потребность в разработчиках