Почему больше приложений не записано на нескольких языках?

В моих домашних проектах я вызываю процедуры Fortran из C или процедуры C из C ++.

В моем рабочем коде мы смешиваем Java с небольшим количеством C.

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

Немного другой аспект:

В 1980-х было несколько языков, способных выполнять полный набор функций. Бизнес-приложение может быть написано на COBOL, но если оно требует сложных числовых подпрограмм, они могут быть написаны на FORTRAN с помощью специального ассемблера, используемого для управления вызовами функций из COBOL в FORTRAN. В настоящее время существует множество вариантов языков и связанных библиотек, которые могут обеспечить полную функциональность на одном языке.

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

The way I see it, there were two main reason for including multiple-langage support in an interpreter/compiler:

• to allow developers to write a function in assembly, in those rare cases when performance is critical to the app
• to ease the introduction to the new language to developers who may be familiar with some other language

The first one is rarely seen today, mostly due to the use of shared libraries (such as dlls) and increased abstraction (the abstraction layer between your code and the assembly underneath is pretty thick), while the second one is mostly a marketing thing, and marketing is usually not the main interest of the guy writing the language spec (.Net being the first exception coming to mind right now).

People write multi-language apps all the time. You mention compiled code called from script languages. That happens really often, e.g. C++ from Python, Perl, Lua or R. Or Java from Groovy. Not sure how often C++ is called from Java, but I'm sure it happens as well.

That's why swig is so popular.

What makes you think this isn't happening?

My ASP.NET MVC applications have some C#, some VB.NET and some JavaScript. I could quite easily throw in some Python and F#, but haven't found the need to go that far.

"So, after all these years, what keeps us from writing multi-language apps?"

It might be perceived that there are too many gotchas with calling code in Language A from code in Language B. Byte alignment, endianness, order of parameters, etc. Covering all of the gotchas so that you can sleep at night takes time.

.NET tries to address these, but I'm not sure how well. That's another discussion.

Using multiple languages involves:

• A more diverse skillset, and not everyone can fix problems anywhere in the system
• Often some pain in terms of cross-language calls, depending on the languages involved. (Your example of JNI is good here - it's nasty IME. P/Invoke is a lot simpler.)
• Often more difficult debugging
• A more complicated build system (for instance, with Java you get portability - but then if you've got a native library to build and deploy as well, life gets harder...)

Yes, it can sometimes be worth it - but I wouldn't do it until I had a really good reason.

.NET and Java both make this a lot easier, of course - using different languages on one platform is a lot easier than interoperating between (say) managed and native code.

Я не уверен, в чем причина, но я полагаю, что это во многом связано с менталитетом "языкового дежурства", который у нас возник в конце 90-х. Я собираюсь начать сводящий с ума проект, который я хочу написать на C ++, но я хочу быть доступным на многих других языках. Я, вероятно, использую для этого комбинацию Swig и SpiderMonkey.

Но многое в действительности сводится к тому, что никто не создает унифицированный интерфейс объекта / повторного использования, кроме .DLL. COM отлично работал в Windows. IDispatch сделал доступным все, что говорит IDispatch. Было здорово писать наши компоненты на C ++ и использовать их из VBScript в ASP. Но ничего подобного никогда не было портативным. Конечно, попытки были предприняты через CORBA и полдюжины других недоработанных и часто плохо принимаемых технологий - но все они имеют проблемы с маршалингом данных, проблемы с вызовами, проблемы с производительностью, проблемы с порядком следования байтов. Никто на самом деле не тратил время на ее решение, и теперь индустрия развивается в сторону SOAP, чтобы заменить его там, где производительность не имеет значения (и придерживается CORBA там, где она есть).

Я думаю, что большая часть причины кроется в том, что для этого нет веских причин. Если в языке есть функция, достаточно привлекательная для использования (например, объектная ориентация), то ее, вероятно, достаточно для использования во всем проекте. BITD, раньше вы переписывали части своего кода на языке ассемблера, если он был недостаточно быстрым, или писали адаптеры, чтобы вы могли вызывать статистический пакет FORTRAN из C. В настоящее время особого давления нет. сделать это. Многие проблемы с производительностью не могут быть исправлены в коде (например, задержка в сети), и большинство компаний, которые предоставляют программные компоненты, предоставляют их в нескольких «разновидностях» (например, jar-файлы Java или компоненты .NET). Как уже упоминали другие, там ' Кроме того, многие разработчики проявляют значительную инерцию, которая не позволяет им изучать новый язык, особенно если он другой. И, конечно, если язык не отличается , то, вероятно, нет веских причин для его изучения.

Даже будучи начинающим программистом, я обнаружил, что мне нужно немного использовать язык ассемблера в C код для ускорения работы. (Это было сделано для отслеживания линии с помощью камеры с использованием довольно медленной процессорной платы для класса)

Я бы посоветовал, если кто-то пишет статью на определенном языке, он, вероятно, наиболее комфортно владеет этим языком.

В недавних проектах я использовал смесь C и Lua (или C ++ и Lua). Мне кажется, что два языка с разными плюсами и минусами освобождают, чтобы сбалансировать их. Код Lua в основном компилируется (запекается) в один и тот же exe, поэтому конечный результат - всего лишь один двоичный файл.

Комментарии о сложности отладки и понимания всего этого действительны. Тем не менее, он сохраняет низкое количество строк исходного кода.

Apple Objective-C использует в значительной степени тот же подход «амальгамы», но меняет образ мышления построчно. Я нахожу эту трудность. Lua и C (++) позволяют мне переключать мышление с помощью исходного файла.

Один случай - это когда библиотеки или другой стандартный код поступают на языке, отличном от языка приложения. Многие из этих вещей написаны на C, и многие приложения в настоящее время не написаны на C. Числовые данные часто пишутся на Фортране (в аспирантуре мне пришлось связать подпрограмму Fortran с приложением Common Lisp).

Когда важные части уже написаны, намного проще использовать дополнительные языки, чем переписывать и проверять чужой код.

В UNIX эта проблема уже решена. Стиль UNIX при написании небольших утилит, которые можно связать вместе, чтобы сформировать решение, является одной из форм написания приложения на нескольких языках. Вместо определения интерфейса и / или механизма взаимодействия между языками, например, JNI, среда командной строки или оболочки стала стандартом де-факто.

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

В зависимости от того, как вы смотрите на эту проблему, существует или нет много приложений, написанных на нескольких языках.

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

В качестве альтернативы вы можете посмотреть на «простой», не смешанный веб-сайт. приложение , которое может использовать:

• SQL для сохранения состояния ,
• C # / Groovy / RoR / и т. д. для логики приложения ,
• и JavaScript / CSS / (X) HTML для представления .

Может быть даже инструмент OR / M или ] LINQ to SQL в случае C # для доступа к хранилищу данных. Позволять' s не забывайте здоровое количество регулярных выражений , встроенных на различных уровнях кода. Это все разные языки. В этом смысле несколько языков регулярно используются для создания приложений .

Но я не думаю, что вы это имеете в виду. Я думаю, что ваша предполагаемая область действия - это «основная часть» кода, созданного одной командой проекта . Вы задаетесь вопросом, почему проект не пишет, скажем, один компонент на Java, другой на Lisp и третий на Erlang, а затем не связывает их все вместе в виде некоего единого конечного результата.

Некоторые ответы были предложены, например сборка / развертывание сложнее, иначе не каждый сможет работать со всеми частями системы из-за недостатка навыков в определенных языках. Меня не устраивают такие ответы. Я' Мы видели неприятные сценарии сборки / развертывания в проектах, написанных в основном на одном языке. И по моему опыту, когда почти любой проект достигает определенного размера, особенно если он был написан многими умами, каждому становится трудно хорошо разбираться в каждой части системы. Кроме того, переход с одного языка на другой (при наличии достаточно опытного разработчика) на самом деле не такое большое препятствие, как некоторые думают.

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

Тем не менее, наличие «правильного» языка для решения правильной проблемы очень ценно . Если вы действительно считаете, что у вас есть три компонента, которые лучше всего выражаются, скажем, в Java, Lisp и Erlang, тогда вам будет выгодно писать эти компоненты на этих языках. Если вы ожидаете, что работа, необходимая для их связывания и поддержания этих ссылок, не будет больше, чем ценность, которую вы получаете от написания на нескольких языках .

Итак, тогда все сводится к сокращению затраты на сборку комплектующих. Это немного другое понятие, чем просто выражение «сборка становится сложнее». С четко определенными общедоступными интерфейсами, правильным сокрытием информации,

Мы часто пишем на нескольких языках. Это зависит от поставленной задачи. В недавнем веб-приложении я написал веб-фреймворк на PHP, клиентские скрипты - на JavaScript, серверную часть и плагины PHP - на Delphi, а базу данных - на MS-SQL.

В настоящее время я работаю в среде, где мы выполняем быстрое прототипирование в Delphi, а затем отправляем его в производство для кодирования на MS C #. Компания также использует множество других языков.

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

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

Мои последние 4 работы были приложениями, которые вызывали:

• Java из C # и C # из F #
• Java из Ruby
• Python из Tcl, C ++ из Python и C из Tcl
• Java из Python и Java из Scheme

(И это даже не считая SQL, JS, OQL и т. д.)

По моему опыту, сдвиг был противоположным: больше языков. Причины этого включают:

• стандартные виртуальные машины, такие как JVM и CLR, позволяют языкам непреднамеренно взаимодействовать
• объектные системы на C, такие как GLib, предоставляют аналогичные функции для языков, скомпилированных в собственном коде.
• Компьютерные системы теперь большие и быстрые достаточно, чтобы все использовали базу данных с языком запросов (даже SQLite сейчас считается крошечным!)
• Самая популярная новая платформа, Интернет, требует, чтобы вы использовали JS, если вы хотите гибкого взаимодействия на стороне клиента, и вы ' Если вы, вероятно, не используете JS на сервере
• , Интернет также предоставляет естественный способ интеграции совершенно разных программ в одну и ту же систему, например, программа Python и программа Ruby с правильным CSS / JS / темами могут выглядеть одинаково и связываются друг с другом так, что пользователь даже не догадывается, что это 2 отдельные программы

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

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

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

Разработчики были обеспокоены производительностью, такой как оптимизация вызовов виртуальных методов в C ++ или компиляция среды выполнения Java с байтовым кодом, с тех пор, как был изобретен ассемблер. В их природе ставить под сомнение все, что не является очевидным.

Я пишу на python, который вызывается из C, запрашивает его базу данных с помощью SQL, выполняет ввод-вывод с помощью HTTP, обслуживает документы, описанные с помощью TEI, преобразует их с помощью XSLT, отображает его вывод на стороне клиента с использованием HTML и CSS, форматирование вывода, не являющегося документом, на специальном языке шаблонов и добавление функциональности к пользовательскому интерфейсу с помощью javascript.

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

Для многих классов приложений просто нет необходимости в «классических» многоязыковых проектах (включающих язык высокого уровня и язык низкого уровня), а дополнительные затраты на сложность значительны:

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

OTOH, многие современные приложения уже используют много разных языков, например, Java, JSP, XSLT , и Javascript можно использовать в одном проекте.

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

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

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

• сколько недавних интернет-приложений написано на C? почти нет.
• сколько стеков IP написано на языке, отличном от C? почти нет.

Я полностью согласен с предпосылкой этого вопроса.

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

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

Мы написали систему, которая заменила 10 000 строк кода Java общего назначения на 750 строк. кода написан на двух DSL и склеен с Java. Мы написали его в 10 раз меньше времени исходной системы, включая время обучения DSL.