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

Ответ 1

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

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

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

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

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

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

• Почему это действительно сделано? Для производительности?

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

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

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