Нет, ничто не мешает взаимодействию.
Основная причина (это мнение, не основанное на известных фактах), что у Фортрана, кажется, больше взаимодействия из коробки, была то, что было бесплатное программное обеспечение GNU / Fortran для заинтересованных сторон для работы. COBOL был очень поздно в игре, чтобы получить жизнеспособный компилятор свободного программного обеспечения. Это больше не проблема для GnuCOBOL, и люди наконец начинают писать код, необходимый, чтобы наверстать упущенное.
Добавление к ответу Саймона; доказательство концепции прямого встраивания в ветке для GnuCOBOL; intrinsi c функции, добавленные для поддержки FUNCTION TCL, FUNCTION PYTHON, FUNCTION REXX, FUNCION LUA и FUNCTION JVM. С тестами FUNCTION JVM для Scala, Groovy, Java, Frink, все работало. Это позволяет передавать данные между рабочим хранилищем COBOL и другим языковым движком, используя простой синтаксис COBOL. Включая настройки для обратных вызовов в и из. Эти функции встроены в компилятор и среду выполнения libcob при использовании этой ветви.
Для других испытаний интерфейса, не встроенных в компилятор, но все же допускающих взаимодействие; в FAQ GnuCOBOL есть десятки примеров. Шекспир? Ага. Фалькон? Ага. C, ну, GnuCOBOL испускает промежуточный C, так что это покрыто пиками. Существует также версия компилятора C ++, поэтому C ++ также рассматривается в пиках. Javascript; Jsi sh, Duktape, Spidermonkey, Quick js, чтобы назвать несколько испытаний.
Ada, D, Vala, Gen ie, S-Lang, ROOT / CINT, J, Gambas, Forth, Perl, Postscript, Pure, Icon и Unicon, Nim, BaCon, SWIG (который открывает многократные числа), PARI / GP, Gretl, R, Red, Ruby, Haxe / Neko, Pascal, Erlang , Elixir, SQLite, Rust, Go, more ..., включая достаточное количество esolangs, и GNU Lightning для модулей сборки на лету. Испытания, задокументированные в GnuCOBOL FAQ.
Взаимодействие фреймворка для AWT / Swing, GTK, Agar и таких вещей, как ZeroMQ, CGI и веб-сокеты, также оказалось успешным и эффективно используется. Наряду с не менее чем 7 препроцессорами EXE C SQL, успешно протестированными и используемыми.
Все сводится к тому, что кто-то хочет попробовать и написать какой-нибудь клей или правильно выровнять кадры вызова. Ни одна попытка, которую я пытался предпринять, не дала удовлетворительных результатов, , хотя Perl 5 - это распутывание макрослоев . (Хорошо, я просто соврал, пытаясь встроить jq, который использует C вызов и возврат по функциям структуры, мне пришлось бы оставить чистое кодирование интерфейса на языке COBOL и не беспокоиться о промежуточном программном обеспечении C, которое сделал бы это легко). ;-) Это когда-нибудь произойдет, поскольку jq - довольно мощный маленький обработчик JSON.
Используйте поисковую систему, которой вы меньше всего не доверяете, и ищите "gnu-cobol-builtin-script" и "GnuCOBOL" FAQ ", и посетите хиты на SourceForge.
В моих конкретных исследованиях я обычно сосредотачиваюсь на языках с C двоичным интерфейсом приложения, но другие ABI будут в том же духе. Требуется только сесть и написать некоторое промежуточное программное обеспечение или понять, как правильно синхронизировать кадры вызова.
Являются ли эти текущие выборки идеальными? Не всегда, есть крайние и угловые случаи с некоторыми типами данных и данными ИЗОБРАЖЕНИЯ КОБОЛ, которые потребовали бы больше работы, но это все; немного работы и испытаний, чтобы сгладить неровности. При исследовании я не всегда go так далеко, пока не возникнет реальная потребность. Эти эксперименты по начальной работе просто для того, чтобы получить некоторое доказательство в пудинге, все сделано для простой радости этого.
Один из ведущих разработчиков GnuCOBOL только что добавил однонаправленный и двунаправленный трубопровод, используя простые имена файлов, что обеспечивает доступ ко всему, что предлагает базовая ОС, с помощью операторов basi c COBOL OPEN / READ / WRITE / CLOSE (и других файловых операций ввода-вывода). Код был передан в транк всего за несколько часов до того, как я начал набирать этот ответ.
По сути, ответ на главный вопрос - громкий номер