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

[Stilet]

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

Дружище, я тебе вот что скажу. Это из собственного опыта кстати. Пока какая-то разработка будет идти в массы раки свистеть научатся. Времени пройдет ого-го сколько, появятся новые тенденции. Ну кто еще лет скажем 10 назад готов был сказать что LINQ убедит настолько удобен, что заменит в шарпе циклы? Критики 1С извергали тонны "Лучей Бобра", и при этом 1С разработки достаточно окупаются (при наличии мозгов ессно )
Не надо прогибаться под этот мир. Делай для себя. "Любить себя - начхать на всех" - хорошее между прочим кредо тому, кто хочет что-то сделать достаточно продуктивно, ибо все равно найдутся люди, которые будут отрицать по тем или иным соображениям. Не важно.
Вернее важно не это - важен сам факт попытки сделать такую унию языковую.
Лично я, вот именно я - самсабялюбимый собираюсь свой ЯВУ доводить до "полного абсурда" помещая в него разнообразные возможности по эксплуатации разных ВМ. ДотНет, Джава машины, командники операционки, SQL, WQL, EQL... И прочие якобы "несовместимости". Себе я уже доказал что они могут уживаться не то что бы в одном проекте, а даже в одном операторе. И мне для развития этого хватает. И далее я буду следовать этому пути что бы там кто ни говорил. Быдлокод? - ну и пес с ним. Пусть будет быдлкод. Я уже привык к ярлыкам в жизни.
Зато проблемы, которые я сейчас решаю с помошью такого вот гибрида гермоафродитного во-первых решаются (к моему кстати удивлению) быстро (имею ввиду затраты на создание ПО) а во-вторых, что самое главное - качественно.
И это все, что меня интересует, чего и остальным желаю.
Развивайтесь, господа, никого не слушайте. Все в ваших руках. (только не я, хи хи)

[Utkin]

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

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

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

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

Если, если, если.
Если надо из Питона заюзать Руби? Ваш ход? Вы все ограничены своими если. Это те если с которыми Вы работаете каждый день. И ни на секунду не можете себе представить жизнь без них. Отсюда Ваши проблемы .

Самое кросплатформенное это веб сервисы.

Ну пупец, еще и сеть разводить. Это классически прикрыть грабли костылями вместо поиска нового решения .

Развивайтесь, господа, никого не слушайте.

Спасибо за здоровый подход к проблеме .

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

Как писать так, чтобы языки были отдельно, понимаете?

язык программирования Шредингера?
тут уж от написания умного интерпретатора никак не обойтись...

[Stilet]

от написания умного интерпретатора никак не обойтись...

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

[the_deer_one]

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

Это классически прикрыть грабли костылями вместо поиска нового решения .

Ну а чем ты собрался грабли прикрывать?

Если надо из Питона заюзать Руби? Ваш ход? Вы все ограничены своими если. Это те если с которыми Вы работаете каждый день. И ни на секунду не можете себе представить жизнь без них.

Ок, представляем что у нас нет старых граблей, типа рубей, питонов, яв, с++ов. А раз у нас нет того, что нам надо сопрячь, значит нет самой проблемы сопряжения.

А для новых языков проблема уже решена явой и .NETом(если бы майкрософт не тупил, был бы один .NET), надо реализовывать новые языки на этой платформе и все дела.

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

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

Я бы сказал, вынести синтаксис в разряд шаблонов описания действий. Захотел вместо "exception" писать "пипец", залез в шаблон и изменил слово.
Но придется вбирать в себя все функции других ЯП. Но тогда мы будем иметь просто ещё один ЯП который поддерживает синтаксис как шаблон, а не как неизменяемый стандарт, не более.

Подобные уникальные ЯП есть, и даже функционируют уже долгие годы) Но что толку?

Вы хоите компилятор который понимает все языки, или 1 язык программирования для всех систем и платформ? Будущее за LLVM, пол мира на С написано. чтобы там не говорили.

А для новых языков проблема уже решена явой и .NETом(если бы майкрософт не тупил, был бы один .NET), надо реализовывать новые языки на этой платформе и все дела.

Фишку с вирт. машиной просекли они не так давно в отличии от дальновидных людей из Sun.

[Utkin]

Захотел вместо "exception" писать "пипец", залез в шаблон и изменил слово.

Эту тему я уже поднимал. И даже проводил практические изыскания.

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

Эту тему я уже поднимал. И даже проводил практические изыскания.

Данная фича не имеет силы если синтаксис B не расширяется как должен в обычном смысле, а полностью клон синтаксиса A. Значит шаблон не шаблон вовсе а кроме syntax.xml ещё и плагин к компилятору, который научит понимать конструкцию foreach и транслировать её в конечный бинарный вид.

Я хочу сказать, что если мы имеем шаблонный компилятор паскаля, то конструкция вида

procedure p() 
begin

end;

при изменении шаблона на тот же C++:

void p() {
 for(int i = 0; i < 10; ++i)
   writeln('Ы');
}

просто не имеет смысла. Мы будем иметь тот же паскаль, если научить его понимать {} как begin end получится, то про иную конструкцию for компилятор знать не будет.
Соответственно плюшки C++ я мспользовать не смогу.

Вы знаете как реализовать компилятор который расширяет свои возможности за счет модулей и расширений? Ввести какой-нибудь foreach в паскаль к примеру, или переменные без типов данных как php или ещё что-то... я вот не имею представления как это должно реализовываться...

И самый цимис:
Каждый аддон нового синтаксиса это новый цикл генерации бинарных данных из текста.
Что это? Фабрика компиляторов? Зачем?!

Все это уже есть, GCC, MinGW, PascalABC, PascalABC.Net, Borland, Delphi, FPC, Java... тысячи их.

Может тогда писать умный парсер-конвертер код из одного ЯП в другой? Который поменяет конструкции и объявления и укажет на места которые не приемлемы в целевом ЯП?
Тогда "Convert to C++(MinGW)" и build.

Но это сложно, да и проблематично. Кто этим будет заниматься? Это львиная доля сборки кода в бинарный вид. Снова фабрика компиляторов под другим соусом. Нафиг нафиг.

Итог: Виртуальные машины с уникальным псевдо-кодом и есть решение "универсальности ЯП". LLVM точно в теме.

Не в том ключе котором вы хотите, мысли в код транслировать научатся не скоро.

Вы можете написать компилятор который будет поддерживать несколько языков программирования(но это ещё один язык программирования, не более), но не сможете пока что создать 1 язык программирования для всех. В принципе он и так есть, уже лет 100 наверное, assembler с перфокартами

буду рад услышать и другие мысли.

[Stilet]

Но придется вбирать в себя все функции других ЯП

Всмысле? Речь идет о интерпретаторе. Тут уже полюбому нужны модули содержащие функции других языков. Ну а что такого? Не вижу проблемы.

Соответственно плюшки C++ я мспользовать не смогу.

Почему не сможешь? А как же тогда SQL используется в других ЯВУ?

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

Почему не сможешь? А как же тогда SQL используется в других ЯВУ?

SQL вообще не язык программирования, разве что в оракле может быть.

Речь идет о интерпретаторе. Тут уже полюбому нужны модули содержащие функции других языков.

И снова фабрика парсеров-генераторов кода. И снова, зачем?