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

Question

Даже 2 десятилетия назад можно было назвать код, написанный на одном языке, для вызова кода, написанного на другом; в школе мы называли ассемблерные графические процедуры из кода Ada для одного задания класса. Заметные исключения: запуск скомпилированного кода из сценариев или выполнение системной команды из скомпилированного кода; но редко мы пишем библиотеку на C ++ для использования в нашем приложении Java. Когда впервые появилась Java, и она все еще работала медленно, была возможность написать основное приложение на Java и переместить код узкого места в некоторую библиотеку C / C ++, которая будет вызываться с использованием JNI.

Итак, после всех этих лет, что мешает нам писать многоязычные приложения? Основной сценарий, который я имею в виду, - это когда язык считается хорошим выбором, если бы он не был узким местом для производительности (как в первые дни Java), поэтому он полностью написан на C, а не использует смесь двух языков.

Меня интересует это с точки зрения архитектуры, а также языкового дизайна. У вас есть хорошие примеры, истории успеха или цитаты?

[Изменить] Одним из лучших примеров этого была обратная реакция на Java из-за ее низкой производительности на ранних этапах. Несмотря на то, что JIT-компиляторы решили эту проблему, мой вопрос всегда был о написании программного обеспечения на языке, который облегчает написание, чтение и обслуживание. Если есть узкое место, напишите процедуру в сборке или C только для узкого места. Таким образом, вы должны получить лучшее из обоих миров, по крайней мере, теоретически.

Answer 1

Использование нескольких языков включает в себя:

• Более разнообразный набор навыков, и не каждый может решить проблемы в любой точке системы
• Часто возникают некоторые трудности с точки зрения межъязыковых вызовов, в зависимости от используемых языков. (Ваш пример JNI хорош здесь - это противный IME. P / Invoke намного проще.)
• Часто более сложная отладка
• Более сложная система сборки (например, с Java вы получаете переносимость - но если у вас есть собственная библиотека для сборки и развертывания, жизнь становится сложнее ...)

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

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

Answer 2

Самая большая проблема, которую я вижу, заключается в том, что она требует, чтобы все в команде были очень разнообразны (см. Ответ Джона Скита). Если у вас есть команда из десяти человек и трое очень хорошо знают C # и немного VB.NET, трое очень хорошо знают VB.NET и очень мало C #, а остальные четыре очень хорошо знают C ++, но подходят только на C # или VB. Нет, можете ли вы представить, какую программу они написали бы на нескольких языках? Может получиться хорошо, но что, если вы потеряете пару членов команды, время имеет существенное значение и скажет, что это были ваши ребята из C ++, а теперь кто собирается исправить этот код? Конечно, не .NET, ребята, которые не разнообразны в C ++. Это может вызвать много проблем.

Вторая причина, по которой я вижу, что приложения в основном одноязычные, заключается в том, что когда вы достигаете большого количества строк кода, очень приятно иметь возможность следовать одному и тому же потоку, шаблонам и видеть один и тот же тип кода по всей системе. Вашему мозгу не нужно переключаться между языками, чтобы что-то выяснить, потому что вы, например, «думаете на C #».

У меня есть друг, который пишет свои пользовательские интерфейсы в VB.Net и свой внутренний код, который он всегда хранит в DLL на C #. Это нормально, VB.NET и C # работают очень хорошо вместе, но говорят, что ему нужно было передать это кому-то, чтобы исправить сегмент кода, в котором была ошибка как в коде VB.NET, так и в C #, ну, он сделал это по необходимости Аутсорсинг двух разработчиков, один свободно говорит на VB.NET, а другой на C #. Это увеличивает затраты в два раза, а также накладные расходы, когда он мог бы просто сделать это за один раз.

Однако я полностью согласен с приложениями, которые могут использовать C ++ для критически важных для производительности разделов. Бывают моменты, когда просто .NET не может быть хорошим выбором для критичного к производительности сегмента кода. Этот вид микширования кода абсолютно нормален.

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

Возможно, хорошей идеей для вас (если вы ищете ответ такого типа) будет выбор языка для каждой технологии. Я лично пишу все свои веб-приложения (asp.net и т. Д.) В VB.NET. Это быстро писать, легко читать и легко поддерживать. А для Интернета это именно то, что вы хотите. Все мои настольные приложения, тем не менее, попадают в C #, потому что в некоторых аспектах это более сильный язык и предлагает несколько вещей, которых нет в VB.NET. На самом деле, это все личные предпочтения, но вы поняли.

Answer 3

Люди все время пишут многоязычные приложения. Вы упоминаете скомпилированный код, вызываемый из языков сценариев. Это происходит очень часто, например C ++ от Python, Perl, Lua или R. Или Java от Groovy. Не уверен, как часто C ++ вызывается из Java, но я уверен, что это также происходит.

Вот почему swig так популярен.

Answer 4

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

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

Answer 5

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

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

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

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

Для доступа к хранилищу данных может даже использоваться ИЛИ / М инструмент или LINQ to SQL в случае C #. Давайте не будем забывать о правильном разбрасывании регулярных выражений , встроенных в различные уровни кода. Это все разные языки. В этом смысле для создания приложений регулярно используется несколько языков .

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

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

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

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

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

Answer 6

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

• Java из C # и C # из F #
• Java от Ruby
• Python из Tcl, C ++ из Python и C из Tcl
• Java из Python и Java из схемы

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

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

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

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

Answer 7

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

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

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

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

Answer 8

«Так что же, после всех этих лет, что мешает нам писать многоязычные приложения?»

Может показаться, что слишком много ошибок с кодом вызова на языке A из кода на языке B. Выравнивание байтов, порядок байтов, порядок параметров и т. Д. Чтобы охватить все ошибки, чтобы вы могли спать ночью, требуется время .

.NET пытается решить эти проблемы, но я не уверен, насколько хорошо. Это еще одно обсуждение.

Answer 9

Что заставляет вас думать, что этого не происходит?

Мои приложения ASP.NET MVC имеют немного C #, немного VB.NET и немного JavaScript. Я мог бы довольно легко добавить немного Python и F #, но не нашел необходимости заходить так далеко.

Answer 10

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

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