Почему не написано больше приложений на нескольких языках? - PullRequest
9 голосов
/ 15 июля 2009

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

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

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

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

Ответы [ 24 ]

1 голос
/ 12 августа 2009

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

1 голос
/ 29 июля 2009

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

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

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

0 голосов
/ 20 ноября 2009

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

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

0 голосов
/ 20 ноября 2009

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

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

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

0 голосов
/ 20 ноября 2009

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

0 голосов
/ 20 ноября 2009

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

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

На мой взгляд, существует две основные причины включения поддержки многоязыкового языка в интерпретаторе / компиляторе:

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

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

0 голосов
/ 20 ноября 2009

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

0 голосов
/ 16 июля 2009

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

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

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

0 голосов
/ 29 июля 2009

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...