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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Является ли это обычной практикой? Кто так делает?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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