Использование разных языков в одном проекте

Question

Недавно я слышал об использовании нескольких разных языков в (большом) проекте, я также читал о таких известных услугах, как Twitter с использованием Rails, как интерфейс, смешанный с некоторыми другими языками, и Scala, я думаю это было как backend.

• Это обычная практика? Кто так делает?

• Я уверен, что есть недостатки. Я думаю, что у вас будут проблемы с различными интерпретаторами/компиляторами и плавное подключение разных языков. Это правда?

• Почему это на самом деле сделано? Для исполнения?

Answer 1

Я считаю, что в случае с Twitter это было связано с производительностью; Scala немного быстрее, чем Ruby, и они используют его для питания своих систем очередей.

Помимо проблем обслуживания, использование нескольких языков вместе может помочь компенсировать недостатки на каждом языке. С помощью Twitter Ruby (on Rails) отлично подходит для работы с интерфейсом своего сайта, но имеет смысл использовать более быстрый язык для обработки второстепенных фоновых задач. Интеграция между языками не сложно, когда дело доходит до систем очередей, поскольку они могут быть полностью отделены от самого приложения и по-прежнему правильно выполнять свои задачи.

Answer 2

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

• Это обычная практика? Кто так делает?

Очень часто; Я бы сказал, что почти каждое большое приложение написано на нескольких языках.

Рассмотрите пример игры. Основной движок обычно написан на C или C++ для скорости и низкоуровневого доступа к аппаратным средствам, но поведение объектов и символов написано на языке более высокого уровня, таком как Lua.

• Уверен, что есть недостатки. Я думаю, что у вас будут проблемы с различными интерпретаторами/компиляторами и плавное подключение разных языков. Это правда?

Да, есть определенное количество накладных расходов для включения сценариев для доступа к объектам игры и тому подобные.

• Почему это на самом деле сделано? Для исполнения?

Да и нет. Если производительность не была проблемой, вся игра могла быть написана на языке сценариев.Некоторые другие причины:

• Скорость разработки; представьте себе накладные расходы, если все маленькие объекты и персонажи в игре, такой как World of Warcraft, были написаны на C++. Программа должна быть скомпилирована и перезапущена для каждого небольшого изменения.

• Модульность; новые объекты могут быть легко загружены и добавлены/удалены во время выполнения, а опытные пользователи могут даже модифицировать их.

• Переносимость; те же сценарии будут работать без изменений на разных платформах.

Answer 3

У меня есть несколько проектов со смешанными языками

В одном случае у меня есть некоторые F # смешанные с C#, потому что F # позволил мне код проблемы проще (и был вызов)

других случаях будет смешивать silverlight и .net в том же проекте - они используют разные CLR

В других случаях у меня есть vb.net и C#, когда у компаний были программисты, которые используют несколько языков - большинство людей, с которыми я работаю, не могут читать c .. любой код, сделанный в этом, вероятно, не будет n наилучшие интересы работодателя.

Основным недостатком является то, что каждый, кто работает над кодом, должен знать все языки.

Это не то, что я часто делаю, но действительно о инструментах для работы imo.

Я бы не сказал, что это делается для производительности, как правило ... хотя я связан с dll dll C++, когда мне нужно что-то сделать очень быстро (графические алгоритмы, прежде чем я смогу сделать любой cuda) ... решения окружающая производительность больше, чем время вычисления. Все, что он обычно накладные, такие как sdcalability, легкость чтения все еще попадает в него. Т.е. я думаю, что вы можете сказать свой о выполнении тех пор, пока вы не ограничивающей производительность означает Казнь программ F находит скорость вывода

Answer 4

В типичном вложенным приложении я пишу для 8051, я несколько языков участвуют:

• C - основная часть приложения находится на C, так как она намного быстрее записывается, но ее легко создать жесткий код, который вписывается в 64k (или меньше) пространства кода.
• Язык ассемблера - иногда вы не можете получить код сгенерированного компилятором. Когда каждый байт подсчитывает, правила языка ассемблера.
• Perl - Некоторые из моих инструментов сборки написаны на Perl. Мощный, гибкий, динамичный язык, такой как Perl, позволяет легко работать с изображениями ROM и обрабатывать многие аспекты процесса сборки.
• GNU make - Huh? Да, make - это язык. Это декларативный язык (который является другой категорией языка наравне с «объектно-ориентированным», «функциональным» и «императивным»). Make - основа моей системы сборки.

Я делаю это, потому что мне нравится использовать правильный инструмент для каждой работы. Я должен использовать C и ассемблер для крошечного 8-битного микро. Я использую C как можно больше, потому что получаю больше работы. Я использую Perl для обработки сложных связанных с сборкой задач, потому что он более продуктивен, чем C, и более мощный и портативный, чем bash.Я использую GNU make в качестве основы для моей сборки, потому что она очень хорошо адаптирована для обработки зависимостей и упрощает создание и поддержку этих метаданных и применяет их к процессу сборки проекта - другими словами: производительность.

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

Answer 5

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

Я знаю проекты, которые используют сочетание jQuery, Tcl, C, Fortran и SQL в одном проекте. (Это веб-приложение, движимый веб-сервер, написанный на Tcl, с вычислительными компонентами C и Fortran и доступ к базе данных с помощью SQL.)

Answer 6

Рассмотрим средний веб-проект, и сколько языков он включает в себя:

HTML, CSS, JavaScript/JQuery, Java, SQL/HSQL.

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

Я также имел данные тяжелые программы с внешними веб написана на Java , но задний конец (на самом деле хруст числа), написанный на C, размещенный на разных серверах и т. д.

И я должен сказать, не моделируйте Twitter. У вас маловероятно, что многие люди хотят этого, что не имеет никакой прибыльности, что инвесторы лишают вас денег. Они также абсолютно ужасны при посадке и отделке местами; если вы когда-либо вводили свой пароль Gmail, вероятность того, что он был передан в ясном виде, например, и, по крайней мере, два года, вы можете дружить с людьми без их разрешения через интерфейс текстовых сообщений. (Гах.)

Answer 7

Это обычная практика? Почему это действительно сделано? Для исполнения?

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

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

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

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

В противном случае первые проблемы обычно возникают либо в управлении памятью, либо в уровне VM, что мы могли бы рассмотреть примеры «управляемого кода». Например, очень сложно получить программу Haskell для обмена выделенными кучами объектами с помощью JVM. Обычно обходным решением является обработка таких вызовов, как удаленные вызовы процедур, как если бы программы выполнялись в разных процессах или даже на разных компьютерах. Такие вызовы могут потребовать существенных накладных расходов, что часто делает невозможным дорогостоящее использование двух разных языков, например, для обмена изменяемыми объектами. Однако, если вам не нужно мутировать вещи, накладные расходы не так уж плохи.

Резюме: есть веские причины, чтобы использовать различные языки для решения различных проблем, и было бы удивительно, если большая система программного обеспечения сделала не использование нескольких языков (за исключением, может быть, в одноязычных бункерах, как Squeak Smalltalk, которые просто не разговаривают с остальным миром). Конечно, есть проблемы с совместимостью, но проблема старая, и обходные решения известны.