Использование разных языков в одном проекте - PullRequest
10 голосов
/ 17 мая 2010

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

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

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

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

Ответы [ 7 ]

2 голосов
/ 17 мая 2010

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

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

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

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

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

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

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

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

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

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

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

1 голос
/ 17 мая 2010

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

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

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

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

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

0 голосов
/ 18 мая 2010

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

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

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

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

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

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

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

0 голосов
/ 17 мая 2010

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

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

0 голосов
/ 17 мая 2010

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

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

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

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

0 голосов
/ 17 мая 2010

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

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

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

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

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

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

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

0 голосов
/ 17 мая 2010

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

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

...