Polyglot Programming: Является ли создание приложений на нескольких языках хорошей практикой?

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

Моя мысль заключается в том, что я могу использовать динамический язык, чтобы быстро получить много кода, а затем перейти на скомпилированный язык, такой как c/С++, для реализации критического кода производительности.

Я вижу много преимуществ этого подхода:

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

Но есть и некоторые недостатки:

  • Поддержание моста между двумя языками
  • Зависимость от двух языков и ошибок языка/библиотеки вместо одного

Каковы другие плюсы и минусы этого подхода? Кто-нибудь знает о каких-либо ресурсах и/или лучших практиках вокруг этого?

ОТВЕТЫ

Ответ 1

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

Кроме того, вам нужно подумать о том, хотите ли вы, чтобы ваше приложение было межплатформенным. Динамический язык, вероятно, будет гораздо менее зависимым от платформы, чем скомпилированный. Это может быть фактором при определении того, какие части приложения должны выполняться на C или С++.

Ответ 2

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

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

Ответ 3

Ja, bien sur, mein freund. На самом деле это un'idea meravigliosa. Боа сортировать.

Я шучу, конечно. Веб-разработчик делает это каждый день, даже не замечая: Java, JSP, EL/OGNL, HTML, CSS, Javascript, ant, XML, XSLT...

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

Ответ 4

Да. Многие программы представляют собой смесь высокоуровневого языка, такого как Python или Ruby, и язык низкого уровня, такой как C. Вы получаете преимущества логики кодирования на языке OO, собранном с мусором, и все еще можете вручную управлять регистрами в плотных внутренних циклах.

Ответ 5

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

В противном случае просто выберите корневой язык, perl и ruby ​​используйте c, поэтому их включение довольно просто. Вы также можете запустить python (jython) или ruby ​​(jrunby) на виртуальной машине Java, что даст вам java в качестве бэкэнд. Хотя это может привести к некоторым другим проблемам, поскольку я не знаком с разработкой против этих версий соответствующих языков.

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

Удачи,

Ответ 6

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

Ответ 7

@Зоркерман

У меня есть опыт работы с Jython и JRuby... намного больше с JRuby.

Я должен сказать, что это отличные платформы, и вы получаете огромную выгоду от динамических языков, PLUS - богатая поддержка библиотеки третьего и первого партий Java, PLUS - высокоплатформенный независимый базовый язык компиляции, сборка мусора PLUS на обоих языках (это важно понять управление памятью, но я из лагеря, что вам лучше избегать этого, если вы НЕ НЕОБХОДИМО это сделать, например, если вы делаете драйверы или вещи на уровне ядра или вещи, которые нужны каждой унции производительности, которую вы можете собрать).

Я просто хочу дать быстрый анекдот. Недавно я создавал ruby ​​ script для индексации экземпляра Solr, и мне нужно было получить доступ к базе данных DB2 (источник данных для индексирования). Straight Ruby потерпел неудачу... у него ужасная поддержка DB2, которая требует полной установки DB2 express edition... которая все еще не работает как рекламируемая (я не смог скомпилировать драйверы Ruby после завершения установки). Решение состояло в том, чтобы просто переключиться на JRuby и использовать JDBC со стороны Ruby, используя пару простых в установке банок (и намного МНОГО меньших файлов, чем установка DB2).

Я бы определенно советовал рассматривать JRuby или Jython вместо того, чтобы использовать C в качестве задней части... Я обнаружил, что алгоритм и производительность ресурсов обычно оказывают гораздо большее влияние на производительность приложения, чем язык, который вы выбираете, и Платформа Java имеет много чего предложить (и она прошла долгий путь с первых дней, когда люди осуждали ее как намного медленнее, чем C/С++). Если вы не делаете очень тяжелые вычисления, которые не могут быть реорганизованы алгоритмически, вам, скорее всего, не нужно будет сбрасываться на скомпилированный язык, независимо от вашего выбора.

PS Интеграция с Java в JRuby очень проста (от JRuby до Java-стороны в любом случае), поэтому сохранение моста не является проблемой. Jython Я думаю, что это одно и то же, но снова мой опыт с ним намного меньше.

Ответ 8

Стоит отметить, что Gambit Scheme и Chicken (и некоторые другие реализации в этом отношении) работают в интерпретируемом режиме и затем могут быть скомпилированы до C.

Ответ 9

Я думаю, что это хорошая идея.

Так как большинство (почти всех?) ОС написаны на C или С++, каждый динамический или интерпретируемый язык на некотором уровне отступает на скомпилированный оптимизированный язык для низкоуровневых материалов.

Ответ 10

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

Весь доступ к данным в SQL, представление в HTML/CSS кажется необратимым.

XML-вещь немного утомительна: некоторые люди пытаются делать все в XML, как если бы XML обладал магическими полномочиями, чтобы сделать программное обеспечение лучше.

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

Ответ 11

Это довольно часто, но убедитесь, что вы знаете, почему вы его создаете так, как вы.

Один пример - в программировании игр. Во многих играх критически важный игровой движок написан на языке C, в то время как в Python, Scheme, на родном языке и т.д. Делаются такие вещи, как уровень скриптов, или что-то еще.

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