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

[Stilet]

Это единичный случай (один язык вызывает другие). А здесь более широкий взгляд - любой язык вызывает любой другой.

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

[Utkin]

В чем проблема написать в паскале вызов Си функции, если интерпретатор будет понимать что эта функция существует и в нее передаются такие-то сходные параметры?

В синтаксисе . Как это сделать красиво? Вот Стилет верно подметил, то что возможно другим не очевидно. Интерпретатор разбирает все множество языков, которые можно вызывать и использовать. То есть без всяких dll, so, каких-то оберток. Вы просто подключаете юнит на другом языке. Например, в uses пишите

uses System, Math.cpp;

И дальше в тексте уже когда Вам необходимо вызываете функции из Math.cpp, в котором уже функции представлены на c++. В момент вызова интерпретатор корректно передает параметры из Unit1.pas в Math.cpp и обратно передает корректный результат, который в Unit1.pas процедуры и функции могут использовать так как будто был вызов не сишной функции, а паскалевской.

[mv28jam]

Примерно об этом речь и идет! Просто Вы вызываете функции не глядя на чем они написаны. Если не понятно, я дам конкретный пример какой-нибудь надуманной задачки.

Уловил.

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

[Utkin]

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

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

[evg_m]

Вы просто подключаете юнит на другом языке.

КОМПИЛЯТОР разбирает все множество языков, которые можно вызывать и использовать.

И АВТОМАТИЧЕСКИ пишет СВОЮ функцию-обертку(переходник).
или ДВЕ (сначала с любого на базовый и потом с базового на любой нужный).
Для этого НУЖНЫ всего лишь знания правил описания и вызовов функций (stdcall, ....) и базовых типов переменных.( ВСЕ РАВНО базовым языком есть Assembler). и С и Pascal одинаково(почти) компилируются в obj. А если нет?

А вот с классами как быть? Передавать класс? Класс-обертка?

То есть без всяких dll, so, каких-то оберток.

В момент вызова НЕявно написанный код-обертка корректно передает параметры из Unit1.pas в Math.cpp и обратно передает корректный результат

Ассемблерный код вызовов отличается только stdcall, ....
Но вот разные менеджеры памяти (управляемые типы) ? Pascal.string.

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

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

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

PaxCompiller - ваш сферический компилятор для сферической программы нашей вселенной, чуть более чем есть.

По крайней мере JavaScript от PAX умеет использовать и Visual Basic модули и паскалевский код.

[waleri]

А почему именно интерпретатор?
В принципе идея не нова, но в свое время не взлетела.
Один из основателей Borland, некто Jensen создал TopSpeed комплятор, который поддерживал C/C++, Pascal и Modula.

По сути все нужно свести к единому ABI и формату объектных файлов.

Кстати, чтобы вы не говорили насчет сложности, но идея COM именно такова. СОМ стандартизирует разположение объектов в памяти и способы вызова методов. В своей основе нет ничего сложного и страшного. Многие путают COM и OLE из-за чего и начинают думать, что COM - это страшно.

Ref:
http://en.wikipedia.org/wiki/Turbo_Modula-2
http://www.nf-team.org/drmad/stuff/t.htm
http://alignment.hep.brandeis.edu/So...ng_Manual.html

[mv28jam]

Пока изначальный посыл в том, чтобы пользоваться готовыми исходниками (возможно с мелкими доработками). Второй - это возможность использовать не только интернациональные команды, но интерязычные.

Безусловный плюс, но мне кажется что несколько синтетический. Базовые библиотеки и функционал существуют во всех серъёзных ЯП, перенос не нужен. Конторы в которых есть свои уникальные/узкоспециализированные исходники, как правило работают на одном языке. Большинство популярных (не юзер ориентированных) программ имеют интерфейсы, опять же, для большинства ЯП и используются как отдельные процессы. Получается что такой подход нужен только если собирается некая команда программистов, которые вместе делают что-то уникальное, для которого у них уже есть нарабоки на разных ЯП - исчезающе малая величина.

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

Мне кажется что это приведёт нас к тому, что все "основные" программисты должны будут знать все основные языки проекта. Это как бы не айс.

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

Подобное будет работать есть:
1. Будет общий менеджер памяти в двух частях:
- ядро интерпретатора/компилятора всем рулит.
- подключаемый модуль предоставляет ссылку на клиентскую часть менеджера памяти.

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

3. Интерпретатор так же имеет ряд унифицированных типов данных для всех ЯП.

[Utkin]

А почему именно интерпретатор?

Потому что:
- мне они ближе;
- чтобы избежать проблем описанных до Вас в #15.

Я специально обратил внимание в первом посте - что это интерпретатор!

Кстати, чтобы вы не говорили насчет сложности, но идея COM именно такова.

Как насчет линукса? Я понимаю что добиться всего и сразу при этом преследуя противоположные цели сложно. Но хочется .

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

Потому что нет таких инструментов. Это как с длинной арифметикой. Задач для нее мало, потому что она не встроена в стандартные языки (ну большинства ЯП), в тоже время не встраивают потому что мало задач. Замкнутый круг.
Что если я как менеджер проекта изначально имея подобный инструмент (пусть не этот, это только своего рода эксперимент) буду ориентироваться на подобную команду? Каждый специалист в своем деле и использует все достоинства из своих ЯП (ну и все грабли естественно).
Базовые библиотеки действительно не нуждаются в переносе. Нуждаются как раз узкоспециализированные, решающие специфические задачи. Именно их отсутствие либо существование в неприемлимом виде увеличивают стоимость проекта.

Конторы в которых есть свои уникальные/узкоспециализированные исходники, как правило работают на одном языке.

Что и сдерживает общее развитие в тех областях.

Мне кажется что это приведёт нас к тому, что все "основные" программисты должны будут знать все основные языки проекта. Это как бы не айс.

В интернациональных командах достаточно знать английский язык, чтобы проводить обмен информацией. Я думаю здесь будет что-то аналогичное. Каждый должен поверхностно знать основной язык проект и досконально свой родной. Попробуйте собрать рульную команду явистов например. А Ява+с+паскаль? Да в лет.