Теория использования разных ЯП в одной программе

[Stilet]

Вот я и говорю из своего опыта - вызов в виде строки. Пример как это у меня крутится я дал выше. А скептики и любители святых скрежалий пусть остаются на своих каннонах. Мешает им что ли новая разработка? Их же насильно никто на новое не переводит?

[MihalNik]

Сообщение от Utkin

Ну вот я не одинок .
Сейчас это не принципиально. В теории да, и как предлагалось Выше писать свою виртуальную машину на очень мегакрутом (типа Руби или Питона), а все остальное незаметно для программиста сводить к нему. Да и про CLR уже упоминали.

Я подразумевал вовсе не это: не вижу особой выгоды интерпретировать С++ для Паскаля или наоборот. Компилировать - да, но тут не требуется ВМ.
Интерпретировать традиционно компилируемые (а также иные) языки будет иметь смысл скорее для скриптовых. Но и тут был хороший профит при возможности скомпилировать.
А виртуальная машина - это целый новый язык, долго и дорого.

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

Только:
1) Через интерфейс (оболочку) на самом языке. Вообще очень полезным был бы инструмент для создания таких оболочек.
2) Через явное обращение к интерпретатору (передача строкой, как указал Stilet) - тот же SQL большей частью таким образом применяется, но первый способ, когда весь код родной для среды - привлекательнее.

[Utkin]

Мешает им что ли новая разработка? Их же насильно никто на новое не переводит?

Я понял и оценил Вашу идею. Новая разработка пока больше теория и никому не мешает. Но когда она будет воплощаться в жизнь (если будет), то хочется сразу сделать механизм наиболее приближенный к большинству. А этого можно добиться только услышав в свой адрес конструктивную критику, за что собственно и спасибо всем кто выразил свое мнение. Конечно удовлетворить потребности всех нельзя, но можно отдать предпочтение большинству. А большинство пока только Стилет

[the_deer_one]

Сообщение от Utkin

Плюсы такого подхода в том, что каждый программист пишет на том языке, который ему нравится, но имеет больше возможностей использовать чужой код, дабы не писать свои грабли. Кроме того, есть некоторые традиции - библиотеки для решения одного круга задач пишутся на одних языках, другие на других. Конечно в целом и общем все языки программирования так или иначе обладают широким кругом библиотек. Но программисту вдруг станет очевидно, что именно эту библиотеку использовать наиболее удобней в данном проекте.

Это не плюсы а минусы. И такое надо городить если иначе совсем никак. Хорошо если нужно вызвать какой нибудь статический метод, не имеющий явного состояния(типа WinApi). То всё просто, запускаем нужную среду с нужной командой или, скриптик ей подсовываем.

А если функционал в виде модуля, который проинициализирован должен быть, сконфигурён, да ещё если им надо рулить, то нужный функционал можно засунуть в сервис и рулить им через WCF интерфейс например.

Но в любом случае это медленно. Ещё можно в сторону COM например посмотреть, он для этого и создан.

[Utkin]

А если функционал в виде модуля, который проинициализирован должен быть, сконфигурён, да ещё если им надо рулить, то нужный функционал можно засунуть в сервис и рулить им через WCF интерфейс например.

Я не предлагаю панацею. И это частный случай не отменяющий все остальные.

Ещё можно в сторону COM например посмотреть, он для этого и создан.

И прям вот кроссплатформенен?

А виртуальная машина - это целый новый язык, долго и дорого.

Это детали. Общий принцип очевиден.

Вообще очень полезным был бы инструмент для создания таких оболочек.

Расскажите подробней суть идеи.

[Человек_Борща]

В том, что Вам сложно представить сам процесс?

Не сложно, каждый день в этом процессе. Только построено все сложнее.

[Utkin]

Не сложно, каждый день в этом процессе. Только построено все сложнее.

А хочется сделать проще. Чтобы не напрягаясь - рр-р-а-аз и в дамках.

[Человек_Борща]

Проще это когда есть 1 макро-язык вобравший в себя все возможности других ЯП, однако он один, являет собой высокий уровень. На нижнем же существует некий SDK для C/C++, Delphi, Lazarus и Assembler и всех прочих, с пом. которого решаются проблемы менеджера памяти, а классы и структуры экспортируются из библиотек и работают как интерфейсные ссылки.

Иначе это хаос. Да можно писать на 3х ЯП даже сразу или делать вкрапления одного ЯП в другой напрямую в коде. Но это уже пипец как неудобно ни читать ни писать, ни понимать, ни тем более документировать. Просто компилятор так написан и понимает. А потому все пишем на 1 ЯП, остальные 2 только читаем и переписываем если находим.

Потому что так удобно целой команде разработчиков, млин.

[Utkin]

Иначе это хаос.

Да нет там никакого хаоса и смешивать разные языки не нужно. Об этом и тема собственно. Как писать так, чтобы языки были отдельно, понимаете? Изначально стоит вопрос избегать смешения Вавилонской башни.

Проще это когда есть 1 макро-язык вобравший в себя все возможности других ЯП, однако он один, являет собой высокий уровень. На нижнем же существует некий SDK для C/C++, Delphi, Lazarus и Assembler с пом. которого решаются проблемы менеджера памяти, а классы и структуры экспортируются из библиотек и работают как интерфейсные ссылки.

Вы цепляетесь за детали реализации вместо того, чтобы посмотреть на саму идею. Оторвитесь от всяких с++ и делфей, сейчас это не принципиально. Всякие там проблемы менеджера памяти... Это в компиляторах проблема, но и она решаема ибо если смотреть не с позиций компилятор/интерпретатор (а в интерпретаторе никаких проблем с памятью нет и не предвидится), а с позиций транслятора (то есть более высоким уровнем абстракции не цепляясь за детали известных Вам решений), то все гораздо проще. Понятно что дьявол-то как раз и кроется в деталях, но до него пока далеко еще. Просто освободите свой образ мышления от известных шаблонов. Это не означает, что прям вот все, вот оно гениальное спасение человечества. Это просто еще один подход к созданию программ, эффект от которого не просчитан (и многим видится и вовсе сомнительным). Но Ваш опыт цепляется за известные наработанные технологии (от которых никто не призывает отказываться) и соответственно не дает Вам увидеть еще и другие варианты.

[the_deer_one]

Сообщение от Utkin

Я не предлагаю панацею. И это частный случай не отменяющий все остальные.

Это не частный случай, а вообще все случаи минус WinApi. )

Тут нормального решения не сделать.

Для WinApi будет удобнее использовать встроенные средства для вызова сишных функций.

Если все языки на .NET, то там общий рантайм и DLLки совместимы. Можно в F# спокойно оперировать C#нутыми dll ки, выгружать из них типы и делать с ними всё что угодно.

Если надо сишные функции юзать(OpenGL например). Для этого в каждом языке есть спец приблуды.

Если рантаймы разные там так просто уже с ними не пообщаешься. Например ява и .NET. Тут нужно запускать в отдельном процессе и как то перетаскивать данные. Например через сериализацию.

Если нужно вызвать powershell из .NETа, то есть специальная приблуда в стандартной библиотеке.

Сообщение от Utkin

И прям вот кроссплатформенен?

Самое кросплатформенное это веб сервисы. Тулзы которые по WSDLке сгенерят обёртки вокруг сервиса должны в каждом языке найтись.