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

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

С другой стороны, использование множества разных языков кажется очень неловким делом, когда вы пытаетесь элегантно решить множество небольших подзадач. Другими словами, ИМХО, языки общего назначения, которые приличны во всем, все еще имеют значение. В качестве тривиального примера предположим, что вам нужно сделать следующее:

  1. Считать из файла несколько данных в произвольном формате. Проверьте его на наличие ошибок и т. Д. (Лучше всего делать что-то вроде Perl).
  2. Загрузите эти данные в матрицы, сделайте кучу хардкорных операций с матрицами (лучше всего сделать что-то вроде Matlab).
  3. Запустите на нем нестандартную, требующую большого объема вычислений подпрограмму, которая должна быть быстрой и компактной (лучше всего это делать на C или C ++).

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

Что мне здесь не хватает? Как эффективно использовать несколько языков, чтобы использовать преимущества каждого из них?

Ответы [ 6 ]

3 голосов
/ 27 января 2009

Я работал над многими проектами, которые содержат довольно разнообразное сочетание языков. Если это не проект .NET, вы обычно используете эти разные языки на разных уровнях или в разных процессах. Возможно, ваше веб-приложение на PHP, а сервер приложений на Java. Таким образом, вы на самом деле не «смешиваете и сопоставляете» на уровне метода.

В .NET и для некоторых языков java vm правила немного меняются, так как вы можете смешивать гораздо более свободно. Но особенности этих языков в основном определяются библиотеками классов - которые являются общими. Таким образом, мотивация для переключения языков в .net обычно определяется другими факторами, такими как язык, который знают разработчики. F # на самом деле предоставляет довольно много языковых функций, специфичных для этого языка, так что, похоже, это немного исключение в .NET. Некоторые из языков Java Java VM также добавляют методы в стандартные библиотеки Java, добавляя функции, недоступные в Java.

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

1 голос
/ 27 января 2009

Встроенные языки, такие как Lua, делают это довольно легко. Lua - отличный динамический язык, похожий на Ruby или Python и позволяющий быстро разрабатывать высококачественный код. Он также тесно интегрирован с C, что означает, что вы можете воспользоваться библиотеками C / C ++ и оптимизировать критически важные для производительности разделы, написав их на C или C ++.

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

0 голосов
/ 16 февраля 2009

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

Большинство работающих программистов выбирают вариант c: делайте все возможное с языками, которые их ИТ-отделы поддерживают в производстве. Обычно у программистов есть некоторый ограниченный выбор языка в конкретной среде, такой как JVM или CLR - так что это не утопия набора инструментов и не моноязыковое гетто.

Даже LAMP и Rails поддерживают (требуют, действительно) разные языки на разных уровнях - HTML, Javascript, Ruby, C в случае Rails. Если вы пишете программные сервисы (именно там сейчас происходит большая часть интересной работы), то вы вряд ли когда-либо будете писать только на одном языке. Но и ваш выбор не безграничен.

0 голосов
/ 28 января 2009

Моя работа на нескольких языках включала простое сочетание C # и C ++ / CLI (это похоже на C ++ с .NET, если вы еще не слышали об этом). Я действительно думаю, что стоит сказать, что способ .NET и Visual Studio позволяет комбинировать много разных языков, что означает, что вы не будете иметь таких высоких издержек, как вы обычно ожидаете при объединении двух языков - Visual Studio сохраняет все это все вместе. Учитывая, что существует множество клонов .NET различных языков - например, F #, IronPython, IronRuby, JScript.NET - Visual Studio - это неплохой способ объединения разных языков.

На техническом уровне, который звучит как то, что вас интересует, то, как это делается в Visual Studio, заключается в том, что у вас должен быть один проект для каждого отдельного языка, и каждый проект компилируется в сборку - в основном это означает, что он становится библиотека для других проектов для использования. У вас будет один главный проект, который управляет всем и вызывает другие библиотеки. Требование, чтобы каждый отдельный язык был отдельным проектом, означает, что вы не будете менять языки на уровне метода, но если вы создаете достаточно большое приложение, которое можно логически разделить на несколько проектов, это может быть весьма полезно. В частности, разделение и абстракция могут сделать вещи проще в целом.

0 голосов
/ 28 января 2009

Я думаю, что все в порядке. Если вы настроите его как n-уровневую настройку, где каждый слой будет получать доступ к тому, что находится под ним одинаково (SOAP / XML / COM и т. Д.), Я обнаружу, что он в конце концов невидим.

Для вашего примера я бы выбрал один язык для внешнего интерфейса, который будет простым, быстрым, гибким и может совершать много, много, много, много, много типов вызовов для различных интерфейсов, таких как com, corba, xml, .net, пользовательские библиотеки dll, ftp и пользовательские шлюзы событий. Это гарантирует, что вы можете легко звонить или взаимодействовать с любым другим языком.

Мой инструмент для этого - Coldfusion, работающий с ASP / PHP / Java и немного Ruby. Вроде бы все это в одном месте и очень просто. Для вашего конкретного случая COldfusion позволит вам скомпилировать свой собственный тег библиотеки, который вы можете вызвать в своем веб-коде. Внутри тега вы можете поместить весь код C, который вам нравится, и заставить его делать все, что вы хотите.

Существуют бесплатные версии Coldfusion с открытым исходным кодом, и это прекрасно для наивного выполнения вызовов Java и .NET из одной базы кода. Проверьте это, я действительно чувствую, что это может быть лучше всего подходит, поскольку это сделано для такого рода корпоративных решений.

Я знаю, что PHP тоже может быть достаточно хорош для этого в зависимости от вашей ситуации, и я уверен, что Asp.net не слишком отстает.

0 голосов
/ 27 января 2009

Рассмотрим самую сложную часть вашей задачи. Разбирать файл - самая сложная часть? Хороший язык для чтения файлов, а затем манипулирования ими может быть наиболее подходящим выбором.

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

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

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

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

...