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

114

Я недавно учился в аспирантуре и собираюсь получить степень магистра компьютерных наук. Я сталкивался с несколькими проектами с открытым исходным кодом, которые действительно меня заинтриговывают и побуждают меня вносить в них свой вклад (CloudStack, OpenStack, moby и Kubernetes и многие другие). Одна вещь, которую я обнаружил, что у большинства из них есть общее, - это использование нескольких языков программирования (таких как Java + Python + Go или Python + C ++ + Ruby). Я уже рассмотрел этот другой вопрос, который касается того, как создаются несколько языков программирования для взаимодействия друг с другом: как взаимодействовать два разных программирования с двумя разными языками?

Я хочу понять требование, которое побуждает предприятия использовать несколько языков программирования. Какое требование или тип требования заставляет разработчика программного обеспечения или руководителя проекта сказать: «Я предлагаю использовать язык X для задачи 1 и язык Y для задачи 2»? Я не могу понять причину, почему несколько языков программирования используются в одном продукте или программном обеспечении.

Парт Патель
источник
14
Как аспирант в области компьютерной инженерии, я добавлю, что для исследовательского кода, в частности, часто возникает вопрос о том, «какой язык автор (студент) знал лучше всего, когда начинал». Исследовательские проекты, особенно одноразовые, которые не приводят к большим исследовательским проектам, имеют тенденцию оценивать результаты по сравнению с «правильностью» (по моему опыту).
tonysdg
16
@tonysdg: Я бы сказал, что «правильность» имеет тенденцию быть более актуальной в научных кругах, а не меньше. Что обычно не имеет значения, так это удобство обслуживания, пользовательский опыт и / или документация. В частности, смешивание языков влияет на удобство обслуживания; это ограничивает количество квалифицированных сопровождающих.
MSalters
2
@MSalters: ремонтопригодность - это слово, которое я искал в то время - я согласен со всем, что вы написали!
tonysdg
19
Разные инструменты для разных задач. Вы заметите, что строительные архитекторы и инженеры используют разные инструменты для строительства одного дома.
Пол Д. Уэйт
17
Когда вы отправляетесь в отпуск, из вашего дома в аэропорт, затем в иностранный аэропорт, затем в отель, а затем на пляж, вы используете один и тот же вид транспорта для каждого этапа поездки?
Гонки

Ответы:

17

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

Проекты заканчиваются использованием нескольких языков по шести основным причинам:

  1. Экономическая выгода повторного использования кода, написанного на других языках;
  2. Необходимость включать и учитывать устаревший код;
  3. Наличие кодеров для конкретных языков;
  4. Потребность в специальных языках для специальных нужд;
  5. Унаследованные языковые предубеждения; а также
  6. Плохое управление проектом (незапланированное многоязычное использование).

Причины 1-4 являются положительными причинами в том смысле, что непосредственное обращение к ним может помочь проекту быстрее, эффективнее, с более качественным продуктом и более легкой долгосрочной поддержкой. Причины 5 и 6 являются отрицательными, симптомы сопротивления необходимым изменениям, плохое планирование, неэффективное управление или некоторая комбинация всех этих факторов. К сожалению, эти негативные факторы являются частыми причинами «случайного» многоязычного использования.

Причина 1 , экономическая выгода от повторного использования, становится все более веской причиной, позволяющей использовать в проекте несколько языков, как из-за большей роли программного обеспечения с открытым исходным кодом, так и улучшенных возможностей поиска нужных компонентов кода в сети. Философия прошлых десятилетий «давайте все это закодируем» продолжает исчезать перед лицом экономических реалий и, по сути, никогда не является наиболее экономически эффективным подходом для любого нового проекта. Это, в свою очередь, делает менее строгими возможности для строгого применения единого языка в проекте.

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

Причина 2 , необходимость размещения устаревшего кода, игнорируется в опасности любого крупного проекта. Как бы много проблем ни создавал устаревший код, наивно полагать, что его можно легко заменить новым кодом на новом языке, может быть невероятно рискованно. Устаревший код, даже плохой унаследованный код, часто включает в себя то, что составляет неявный «контракт» функций, ожидаемых сообществом, использующим унаследованный продукт. Это сообщество довольно часто является основным источником дохода для компании или основной целью поддержки правительственного программного обеспечения. Просто отказ от этого подразумеваемого контракта может преследовать осведомленных клиентов в массовом порядке и может обанкротить компанию в одночасье, если другие варианты будут легко доступны.

В то же время, не заменять старый код на старом языке так же опасно, как и заменять его оптом. Наихудшим примером является Администрация ветеранов США, которая имеет большое количество жизненно важных систем, закодированных на языке MUMPS (без шуток), который был разработан врачами, а не учеными-компьютерщиками. Никто не хочет изучать MUMPS, и те, кто знает это, буквально отмирают. Поэтому программисты должны приспосабливать MUMPS даже тогда, когда они пытаются перейти на использование других более распространенных, более мощных и лучше поддерживаемых языков.

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

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

Более рациональный подход заключается в анализе языковых потребностей проекта на основе функциональных областей. Например, внимательный взгляд на проект может показать, что существует только небольшая «вершина» ценного кода, например, для реализации какого-то запатентованного алгоритма, который требует опыта кодирования на менее распространенном языке. Другие части любого крупного проекта часто легко приспосабливаются более распространенными языками или (что еще лучше) хорошо управляемыми продуктами с открытым исходным кодом. Таким образом, анализ проекта по языковым потребностям может обеспечить гораздо более реалистичный и экономически эффективный подход к найму или аренде специальных знаний по специальным языкам, а также может помочь улучшить взаимодействие между языками в рамках одного проекта.

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

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

Причина 5 , устойчивость к необходимым изменениям в используемых языках, может быть причиной серьезного нарушения проекта и внутренних раздоров. Как пользователь DaveoКак отмечается в комментарии к этому ответу, изменения могут быть очень сложными для некоторых сотрудников проекта. В то же время, сопротивление переменам никогда не бывает простым вопросом, и именно поэтому оно может вызвать много раздоров. Использование унаследованных языковых навыков может стать мощным стимулом для повышения производительности проекта, если унаследованный язык достаточно мощный и может привести к продукту с отличным качеством в команде, которая работает бесперебойно и уважает качество. Тем не менее, унаследованные языковые навыки должны быть сбалансированы с тем фактом, что многие более старые языки больше не могут дополнять более поздние языки с точки зрения расширенных функций, доступности компонентов, опций с открытым исходным кодом и поддержки интеллектуального набора инструментов.

И тогда, и сейчас единственным наиболее распространенным (и по иронии судьбы, наиболее часто правильным) аргументом для продолжения использования более слабого, менее читаемого или менее производительного унаследованного языка было то, что более старый язык позволяет создавать более эффективный код. Это старый аргумент, который восходит к 1950-м годам, когда пользователи языка ассемблера возмущались, часто с горечью, появлением программирования на FORTRAN и LISP. Пример, в котором даже сейчас аргумент эффективности кода может иметь достоверность, можно увидеть в интенсивно обрабатывающем коде, таком как ядро ​​операционной системы, где C остается языком выбора по сравнению с C ++ (хотя по причинам, которые выходят за рамки простой эффективности).

Однако в глобальных сетевых и мощно поддерживаемых машинами проектных средах нового тысячелетия эффективность кода в качестве основного аргумента для выбора языка проекта стала еще слабее. Тот же взрыв вычислительного и сетевого оборудования, который позволил массово продвигать приложения для искусственного интеллекта, также означает, что затраты на человеческое программирование могут легко превзойти затраты на неэффективное выполнение относительного кода на невероятно дешевом оборудовании и облачном программном обеспечении. Когда это сочетается с большей доступностью для более поздних языков библиотек компонентов, опций с открытым исходным кодом и расширенных наборов интеллектуальных инструментов, число случаев, когда сохранение языка только по причинам эффективности становится очень узким. Даже в тех случаях, когда это применимо,

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

Обучение сотрудников языкового наследия на новом языке само по себе может представлять опасность. Я до сих пор вспоминаю случай, когда участник проекта, который только что прошел обучение и перешел с C на C ++, искренне жаловался мне на то, что он просто не понимает преимуществ объектно-ориентированных методов. Когда я посмотрел на его код, он преобразовал свои более ранние 103 C-функции в 103 метода для одного класса объектов C ++ ... и по праву не видел, как это помогло.

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

Причина 6 , плохое управление проектами, говорит само за себя. Выбор и использование языка в проекте всегда следует рассматривать и оценивать в явном виде, а не допускать случайности. По крайней мере, выбор языка может иметь огромное значение для долгосрочной судьбы и стоимости поддержки проекта, и поэтому всегда должен учитываться и планироваться. Не становись MUMPS!

Терри Боллинджер
источник
Я согласен со всем этим. В то время как ответ Basile сосредоточен в основном на проблемах производительности и выразительности, ваш ответ помогает любому понять точку зрения управления, стоящую за выбором программирования полиглотов.
Парт Патель
@ParthPatel Я думаю, что вы должны принять этот ответ, это лучшее отдельное заключение здесь.
оставил около
2
+1: но вы забыли Эго. Многие люди отказываются изучать новые языки и придерживаются того, что они знают. Этот разный уровень зрелости в нескольких командах может привести к появлению множества разных технологий в одном проекте
Daveo
1
Причина 7 - попытаться заставить ИТ-отдел выглядеть сексуально в рекрутинговых целях. Не шучу, в проекте .Net мы закончили тем, что нам пришлось заменить одну конечную точку из существующего сервиса, чтобы использовать совершенно новый сервис в Go, просто чтобы они могли добавить «полиглот» в дополнение к работе!
Крис Ли
1
Хех! Я не могу не согласиться с тем, что использование нескольких языков привлекает людей, которые обеспокоены тем, что они могут попасть в тупик, только на COBOL. Это первый раз, когда я слышал, что язык добавляется только специально для этой цели, но, безусловно, есть много сред, в которых наличие большего количества инструментов и языков рассматривается как признак того, что они работают с новейшими технологиями, и, таким образом, это более прогрессивное место для работы. Хороший пример, спасибо!
Терри Боллинджер,
158

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

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

Прочитайте книгу Майкла Л. Скотта « Прагматика языка программирования»

Некоторые языки программирования предпочитают выразительность и декларативность (многие языки сценариев, но также и языки программирования высокого уровня, такие как Agda , Prolog , Lisp , Haskell, Ocaml, ...). Когда важна стоимость разработки (человеческое время и затраты разработчиков), целесообразно использовать их (даже если производительность во время выполнения не оптимальна).

Другие языки программирования предпочитают производительность во время выполнения (многие языки низкого уровня с обычно скомпилированными реализациями, такими как C ++, Rust, Go, C, ассемблер, также специализированными языками, такими как OpenCL ...); часто их спецификация допускает некоторое неопределенное поведение . Когда производительность кода имеет значение, предпочтительно использовать эти языки.

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

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

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

Обратите внимание, что сегодня стоимость разработки становится все более и более значительной (это не имело место в 1970-е годы - в то время компьютеры, которые были очень дорогими - или в некоторых встраиваемых приложениях - с большим объемом продукта). Практическое правило (очень приблизительное) заключается в том, что опытный разработчик может писать около 25 тысяч строк (отлаженного и документированного) исходного кода каждый год, и это мало зависит от используемого языка программирования.

Обычный подход заключается в том, чтобы внедрить некоторый язык сценариев (или некоторый предметно-ориентированный язык ) в большое приложение. Эта идея дизайна (связанная с предметно-ориентированным языком) использовалась десятилетиями (хорошим примером является редактор исходного кода Emacs , использующий Elisp для создания сценариев с 1980-х годов). Тогда вы будете использовать легко встраиваемый интерпретатор (например, Guile , Lua , Python...) внутри большего приложения. Решение о включении интерпретатора в большое приложение должно быть принято очень рано и имеет серьезные архитектурные последствия. Затем вы будете использовать два языка: для вещей низкого уровня, которые должны работать быстро, некоторые языки низкого уровня, такие как C или C ++; для сценариев высокого уровня - другой DSL или язык сценариев.

Обратите также внимание на то, что данное программное обеспечение может работать в большинстве современных операционных систем (включая Linux, Windows, Android, MacOSX, Hurd, ...) в нескольких взаимодействующих процессах с использованием методов межпроцессного взаимодействия . Он даже может работать на нескольких компьютерах (или на многих из них), используя методы распределенных вычислений (например, облачные вычисления , HPC, клиент-сервер, веб-приложения и т. Д.). В обоих случаях легко использовать несколько языков программирования (например, кодировать каждую программу, выполняющуюся на одном процессе, или компьютер на своем собственном языке программирования). Прочитайте Операционные системы: Три Легких Части для больше. Кроме того, интерфейсы сторонних функций(например, JNI ), ABI , соглашения о вызовах и т. д. ... облегчают смешивание нескольких языков в одной и той же программе (или исполняемом файле ) - и вам помогут такие генераторы кода, как SWIG .

В некоторых случаях вам приходится смешивать несколько языков программирования: веб-приложениям требуется Javascript или Webassembly (единственные языки, работающие в большинстве веб-браузеров) для части, выполняемой в браузере (существуют платформы, генерирующие их, например, ocsigen ). Коду ядра нужно, чтобы некоторые вещи (например, планировщик или низкоуровневая обработка прерываний) были частично написаны на ассемблере, потому что C или C ++ не могут выразить то, что там нужно, запросы RDBMS должны использовать SQL, GPGPU нужны компьютерные ядра, закодированные в OpenCL или CUDA, управляемый хост-кодом C или C ++ и т. д. .... Некоторые языки предназначены для облегчения такого сочетания (например, asmоператоры в C,куски кода в моем позднем GCC MELT и т.д ...).

В некоторых случаях вы используете методы метапрограммирования : некоторые части вашего большого программного проекта будут иметь код (например, на C или C ++), сгенерированный другими инструментами (возможно, специальными инструментами проекта) из некоторой специальной формализации: генераторы синтаксического анализатора (неправильно называемые compiler- на ум приходят компиляторы), такие как Bison или ANTLR , но также SWIG или RPCGEN. И обратите внимание, что в GCC есть более десятка специализированных генераторов кода C ++ (по одному на каждый внутренний DSL внутри GCC). Смотрите также этот пример. Обратите внимание, что метабагов трудно найти. Читайте также о загрузочных компиляторах , а также о гомоконичности и рефлексии(стоит изучить Lisp , поиграть с SBCL и прочитать SICP ; посмотрите также на библиотеки JIT-компиляции, такие как GCCJIT ; в некоторых больших программах вы можете генерировать некоторый код во время выполнения, используя их; знайте о десятом правиле Гринспуна ). Загляните также в выступление на Circuit Less Traveled на FOSDEM2018.

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

Кстати, это говорит о том, что некоторые навыки работы с компиляторами и интерпретаторами полезны для каждого разработчика (даже без работы внутри компиляторов). Так что читайте Книгу Дракона, даже если вы не работаете над компиляторами. Если вы пишете свой собственный интерпретатор (или разрабатываете свой DSL), прочитайте также Lisp In Small Pieces .

Смотрите также это и что и что и что ответы на мои относящиеся к данному вопросу.

Изучите также исходный код нескольких крупных проектов свободного программного обеспечения (на github или из вашего дистрибутива Linux ) для вдохновения и просвещения.

Кроме того, некоторые языки программирования развивались путем добавления аннотаций (в виде прагм или комментариев ) к существующим языкам. Для примера, подумайте о ACSL (прим-расширение для аннотирования программы C , чтобы включить их доказательство по Фраму-C ) или OpenCL (С диалектом к программе GPGPUs) или OpenMP или OpenACC #pragmas или Common Lisp аннотаций типа .

PS: есть также социальные, организационные или исторические причины смешивать языки программирования; Я игнорирую их здесь, но я знаю, что на практике такие причины являются доминирующими. Читайте также Мифический Человек Месяц

Василий Старынкевич
источник
6
Для меня это правильный ответ. Вы можете взять, например, процедуры сборки в программах на Си. Оболочка UNIX изобилует несколькими языками программирования, и вы часто найдете awk(это другой язык программирования) используемый в скриптах bash, просто потому, что он лучше подходит для этой задачи). @ Амон все еще остается в силе.
MayeulC
8
Кстати, великий программист иногда может удалить строки кода ... (заменив множество дрянных строк кода на несколько хороших строк)
Василий Старынкевич,
12
Хороший ответ, но одна просьба: я ценю желание указать «в стороне», представляя их менее заметно, но, пожалуйста, не злоупотребляйте тегом HTML SUP просто потому, что он имеет побочный эффект рендеринга более мелким шрифтом. Это должен быть кошмар доступности, и, как гласит стандарт HTML5, «эти элементы должны использоваться только для разметки типографских соглашений с определенным значением, а не для типографского представления ради презентации. [...] используйте эти элементы только в том случае, если Отсутствие этих элементов изменит смысл контента ".
февраля
4
@FeRD: удалено, <sup>но с сожалением
Василий Старынкевич
6
@BasileStarynkevitch приветствуется. Как я уже сказал, я ценю это намерение, и как сам чрезмерно многословный писатель, склонный к касательным, я определенно хотел бы, чтобы StackExchange предоставил поддерживаемый метод стилизации текста меньшего размера или, возможно, свалился в контейнере «нажми и открывай». Но верхние индексы длины абзаца не являются решением этой проблемы.
FERD
29

Многие проекты не построены с несколькими языками программирования. Однако для помощи с программным обеспечением обычно используются сценарии на других языках.

  • Инструменты администрирования, которые являются отдельными программами, иногда пишутся на другом языке.
  • Библиотеки и API часто предлагают привязки для нескольких языков, так что разработчики могут использовать любой язык, который они предпочитают.
  • Сценарии сборки и связанные сценарии разработки часто используют специализированные языки.
  • Сквозные тесты приложения не должны использовать один и тот же язык.

Несколько проектов используют несколько языков в приложении, например ядро ​​на языке более низкого уровня, который может интегрировать плагины в язык сценариев. В некоторых экосистемах (например, JVM или .NET) конкретный используемый язык не так уж важен, поскольку несколько языков в одной среде исполнения имеют хорошую совместимость. Например, я мог бы написать проект в Scala, который бы использовал существующие библиотеки Java и интегрировал функции скриптинга с Groovy.

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

Амон
источник
3
Это дополняет ответ @ Basile. Perl-скрипты из ядра Linux не являются частью ядра, как и Makefile. Нет ничего выгодного в использовании C для этих целей. Более того, эти Perl-скрипты могут использоваться независимо от ядра Linux. Довольно часто о них можно думать как о тесно связанном проекте, хотя и обособленном . Обычно вы будете использовать один язык для одной задачи.
MayeulC
20

Это имеет две формы и множество организаций, которые находятся где-то между ними:

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

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

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

Бен
источник
20

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

Ядро написано на предметном языке, созданном специально для проекта. Это оказалось чрезвычайно полезным, в частности потому, что он интегрирует откат в базовую архитектуру, но компилирует в код C, который мы затем компилируем с помощью компилятора платформы. За это время он поддерживал около двадцати платформ, не считая 32- и 64-битных вариаций, и в настоящее время поставляется на шести из них.

У него есть надстройка, написанная на C ++, которая была запущена, когда бывший руководитель проекта убедился, что C ++ / MFC / Windows / x86 собирается вытеснить все другие архитектуры и платформы, поэтому было необходимо предложить C ++ работу для быть в состоянии нанять персонал. Все оказалось не так, как он ожидал.

В дополнение к языку предметной области и C ++ разработчики работают в LISP, который используется для написания тестовых случаев с использованием интерпретатора, встроенного в тестовую систему. В какой-то момент мы подумали о замене LISP на Java, но, к счастью, мы этого не сделали.

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

Он имеет собственные системы сборки и нуждается в них, потому что язык домена не поддается системам сборки на основе. Один для UNIX-подобных платформ написан на языке сценариев оболочки, Perl и некоторых небольших программах. Один для платформ Windows написан на пакетном языке, Perl и тех же небольших программах на доменном языке. Старая система сборки VMS была написана на DCL, но она не использовалась более десяти лет.

В компиляторе есть язык программирования YACC / Bison для языка предметной области. Есть некоторый тестовый код для платформ Apple, написанный на Objective-C ++. Некоторые из внутренних веб-сайтов группы (используемые для управления проектами, а не часть результатов) написаны на ASP, а другие - как CGI-скрипты на Perl.

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

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

Джон Даллман
источник
Было бы неплохо рассказать немного больше об этом программном продукте: в какой промышленной области (например, нейрохирургические роботы не похожи на высокочастотную торговлю)? Какой примерный размер (в миллионах строк кода)? Какой размер команды?
Василий Старынкевич,
@BasileStarynkevitch: добавлены подробности.
Джон Даллман
Этот. Именно поэтому в проектах есть несколько языков, от хороших до плохих и безобразных.
Джаред Смит
15

В некоторых случаях есть инструмент, который вам нужно использовать (например, инструментарий пользовательского интерфейса операционной системы), который наиболее легко доступен на данном языке. Например, для iOS и macOS, если вы хотите писать приложения с графическим интерфейсом с использованием UIKit и AppKit, написание в Swift или Objective-C - самый быстрый и простой способ сделать это. (Могут быть привязки для других языков, но они могут стоять за последним выпуском ОС, против которого вы строите, поэтому могут не предлагать все функции.)

Так часто случается, когда приложение является кроссплатформенным, основная логика приложения написана на каком-то языке, доступном для обоих, и специфичные для UI / OS части написаны на том языке, на котором они работают изначально.

Поэтому, если вы пишете приложение для Windows и MacOS, вы можете написать основную логику на C ++ и использовать C # для пользовательского интерфейса в Windows и Swift для пользовательского интерфейса в macOS. Это экономит время, потому что вам не нужно писать основную логику дважды и иметь дело с различными наборами ошибок в обоих приложениях и т. Д. Но это также позволяет использовать истинный собственный интерфейс, который не обслуживает наименьший общий знаменатель между платформами, как, например, использование кроссплатформенная библиотека пользовательского интерфейса будет.

user1118321
источник
MVC FTW! Даже переходя к одному кроссплатформенному ядру с приложениями-оболочками для каждой ОС / среды ... или в современном мире связности, переводя его на архитектуру клиент / сервер
ivanivan
1
Это соответствует моему собственному опыту. Каждый проект большого размера, над которым я работал, использовал несколько языков, и никогда не было такого разнообразия языков. Причина всегда заключалась в том, что отдельные части должны были быть написаны на определенных языках, чтобы взаимодействовать с конкретными инструментами.
Оуэн
Как бывший разработчик iOS, я могу подтвердить, что мы сделали это. У нас был API, написанный на PHP, который взаимодействовал с JSON, веб-интерфейсом, написанным на PHP, который также содержал часть JavaScript / HTML5, интерфейс Android, написанный на Java, и интерфейс iOS, написанный на Objective-C , Позже новые проекты были написаны на Swift, но наша внутренняя структура была написана на Objective-C. Так что в какой-то момент одно из наших приложений было написано на PHP, Java, Objective-C, Swift, JavaScript и HTML5 и доступно на 3 платформах.
Belle-Sophie
10

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

В практической реальности необходимо учитывать 2 особенно важных момента:

  1. У людей разный опыт и уровни интереса к разным языкам программирования. - Предоставление людям возможности работать на языках, которые им нравятся и которыми они владеют, в некоторых случаях может привести к лучшему конечному результату, чем принуждение их к общему языку.
  2. Большие кодовые базы создаются разными людьми в течение длительного времени. - Нет никакого способа получить финансирование или количество добровольцев, необходимое для переписывания всего проекта, как только появится язык, который лучше подходит для него.

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

  • Чувствительные к производительности области разработаны на скомпилированном языке. Язык примера: C ++
  • Области, которые должны быть дешевыми, легко изменяемыми и потенциально настраиваемыми, разработаны на языке сценариев. Пример языка: Lua.
  • Макет GUI. Пример языка: HTML
  • Установщик. Пример языка / инструмента: WiX.
  • Построить. Пример языка / инструмента: слишком много, чтобы перечислить, обычно несколько из них одновременно.

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

Питер
источник
8
HTML не является языком программирования
Bergi
1
@ Берги Верно. Питер не утверждает, что это так. Это язык разметки.
Белль-Софи
1
HTML, XAML, QML и т. Д. - это языки, используемые программистами в программных проектах для указания компьютеру, что делать - языки обычно не являются строго необходимыми, поскольку теоретически программисты могут написать весь проект, включая пользовательский интерфейс, на одном языке. Вот что делает его актуальным в контексте этого вопроса.
Питер
5

В дополнение к правильным уже сделанным пунктам:
из опыта многие решения по языку или окружающей среде принимаются «если у вас молоток, все выглядит как гвоздь», то есть люди склонны использовать инструменты, с которыми они знакомы.

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

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

Aganju
источник
5

Этот вопрос (и некоторые ответы), кажется, предполагают, что приложения являются монолитными блоками кода - это не обязательно так.

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

Я работаю над крошечной платформой онлайн-банковской платформы, ориентированной на небольшие банки и кредитные союзы. Эта платформа состоит из нескольких компонентов - веб-интерфейса, уровня базы данных, стороннего уровня связи и т. Д. Это все независимые приложения, работающие на разных серверах с разными операционными системами. У вас есть Javascript, работающий на стороне клиента в браузере, у вас есть страницы для создания Perl на стороне сервера, у вас есть несколько сервисов, написанных на C ++, выступающих в качестве уровня абстракции между кодом Perl и основным процессором банка, еще один набор приложений C ++, которые маршрутизировать сообщения между различными уровнями, разбирать приложения C ++ и сценарии Perl для мониторинга работоспособности различных процессов и сообщать об их состоянии на внутренний монитор и т. д. и т. д. и т. д.

Монолитные приложения все еще существуют, но даже они могут использовать разные языки по разным причинам. Вы можете написать 90% приложений на Java, но используйте JNI, чтобы использовать C или C ++ для более критичных для производительности разделов.

Джон Боде
источник
Я удивлен, что никто не упомянул SQL (или язык запросов по вашему выбору), большинство приложений в наши дни имеют хотя бы какую-то «стековую» архитектуру для них.
user3067860
3

Я хотел бы указать на очень конкретный пример мотива «разные языки имеют разные сильные стороны»: FORTRAN.

Первоначально Fortran был разработан, чтобы облегчить инженерам работу по числовому анализу, и с тех пор было приложено много усилий, чтобы компиляторы Fortran создавали очень эффективный числовой код. С другой стороны, с тех первых дней использование компьютеров резко возросло в тысяче направлений, ни одно из которых не связано с численным анализом, и развитие языков программирования в значительной степени следовало примеру игнорирования «реального» мира [простите за каламбур].

SO: Это сегодня, и вы работаете в компании с довольно обширным продуктом, большая часть которого написана (скажем) на Java (я говорю из личного опыта здесь) . Но вы обнаружите, что одна из основных особенностей продукта будет собирать некоторую форму численного анализа, и все лучшие коды для этого конкретного анализа уже доступны в сети - на Фортране. Ну так что ты делаешь? Вы загружаете один из этих кодов Фортрана, выясняете его интерфейс [т.е. аргументы самой верхней подпрограммы], подбираете для него оболочку JNI в C и упаковываете его как класс Java. BAM! Вы только что должны были развиваться на трех языках одновременно. [особенно если вы обнаружите, что ваш код на Фортране использует блоки COMMON - то есть статическое хранилище - и должен быть изменен для обеспечения безопасности потоков]

PMar
источник
4
Или ваше хорошо протестированное вычислительное ядро ​​FORTRAN будет улучшено, если в какой-то момент вызвать новый алгоритм, который зависит от выполнения сортировки кучи по указателям, которые вы уже написали на C. И у вас есть сложные входные файлы для сканирования, поэтому вы пишете сканер в флекс. О, и, может быть, вам нужен графический интерфейс сверху, который вы должны вызывать из C ++. Или клиент действительно хотел бы назвать все это подпрограммой Matlab ...
jamesqf
3

Потому что программирование - это не одна задача. Даже создание продукта - не единственная задача. Есть несколько типов задач, которые лучше всего выражены на разных языках.

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

Продукт должен быть

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

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

Однако даже процесс написания продукта не может быть оптимально выполнен на одном языке.

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

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

Можете ли вы сделать все это на одном языке? Конечно. Но ваша эффективность определяется тем, насколько быстро вы можете завершить проект и насколько он устойчив к изменениям. Если большая часть вашей работы может быть автоматизирована с помощью уже существующих инструментов, то то, что вам нужно сделать за 3 месяца, может быть выполнено кем-то другим за 2 дня. Но что кто-то будет использовать другие языки для автоматизации того, что вы будете делать через повторение.

grovkin
источник
«Язык, который может быть полезен для написания среды выполнения продукта, вряд ли будет таким же хорошим» ... языки программирования не выходят из случайного процесса, поэтому немного странно говорить о вероятности таким образом. Языки программирования предназначены для решения некоторых задач. Теперь ваша точка зрения заключается в том, что язык вряд ли также случайно решит еще одну проблему, которую он не предназначен для решения. Я бы сказал, однако, что суть программирования состоит в том, чтобы абстрагироваться от всех проблем, которые можно пожелать решить, и поэтому действительно хорошо разработанный язык должен быть таким же хорошим для любой задачи.
оставил около
@ leftaroundabout - это распространенная ошибка - путать, что может делать язык и что он хорошо выражает. Цель языка высокого уровня - не решить проблему. Он должен выступать в качестве синтаксиса для выражения решения проблемы таким образом, чтобы какой-то инструмент мог превратить это выражение в задачу для компьютера. Учитывая это, важно помнить, что фактическая работа выражения делается людьми. И люди используют разные абстракции для описания решений проблем из разных областей.
Гровкин
Конечно, люди используют разные абстракции. Я хочу сказать, что хороший язык должен быть в состоянии выразить все эти абстракции.
оставил около
@ leftaroundabout, совсем нет. Чтобы выразить что-либо хорошо, нужно уметь направить внимание на вещь. Попытка хорошо выразить все типы абстракций будет означать привлечение внимания ко всем из них. И это рассеет внимание и приведет к тому, что идеи будут плохо выражены. Нет ничего плохого в выборе того, что нужно подчеркнуть, и концентрации на этом.
Гровкин
Возможность направить внимание куда-то - это не то же самое, что сделать это на самом деле.
оставлено около
1

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

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

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

Другой причиной является ситуация, когда язык X очень похож на то, что используется на платформе A, язык Y очень похож на то, что используется на платформе B, но язык Z поддерживается на обеих платформах. Таким образом, общий код написан на языке Z, который затем комбинируется с X или Y, в зависимости от платформы.

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

gnasher729
источник
8
О первом предложении: программы на разных языках существуют уже более 50 лет.
Blrfl