Я недавно учился в аспирантуре и собираюсь получить степень магистра компьютерных наук. Я сталкивался с несколькими проектами с открытым исходным кодом, которые действительно меня заинтриговывают и побуждают меня вносить в них свой вклад (CloudStack, OpenStack, moby и Kubernetes и многие другие). Одна вещь, которую я обнаружил, что у большинства из них есть общее, - это использование нескольких языков программирования (таких как Java + Python + Go или Python + C ++ + Ruby). Я уже рассмотрел этот другой вопрос, который касается того, как создаются несколько языков программирования для взаимодействия друг с другом: как взаимодействовать два разных программирования с двумя разными языками?
Я хочу понять требование, которое побуждает предприятия использовать несколько языков программирования. Какое требование или тип требования заставляет разработчика программного обеспечения или руководителя проекта сказать: «Я предлагаю использовать язык X для задачи 1 и язык Y для задачи 2»? Я не могу понять причину, почему несколько языков программирования используются в одном продукте или программном обеспечении.
Ответы:
Этот ответ имеет превосходное освещение и ссылки на то, почему разные языки могут обеспечить различные преимущества для проекта. Тем не менее, существует несколько больше, чем просто языковая пригодность, связанная с тем, почему проекты заканчиваются использованием нескольких языков.
Проекты заканчиваются использованием нескольких языков по шести основным причинам:
Причины 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!
источник
Это довольно просто: не существует единого языка программирования, подходящего для всех нужд и целей.
Прочитайте книгу Майкла Л. Скотта « Прагматика языка программирования»
Некоторые языки программирования предпочитают выразительность и декларативность (многие языки сценариев, но также и языки программирования высокого уровня, такие как 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: есть также социальные, организационные или исторические причины смешивать языки программирования; Я игнорирую их здесь, но я знаю, что на практике такие причины являются доминирующими. Читайте также Мифический Человек Месяц
источник
awk(это другой язык программирования) используемый в скриптах bash, просто потому, что он лучше подходит для этой задачи). @ Амон все еще остается в силе.<sup>но с сожалениемМногие проекты не построены с несколькими языками программирования. Однако для помощи с программным обеспечением обычно используются сценарии на других языках.
Несколько проектов используют несколько языков в приложении, например ядро на языке более низкого уровня, который может интегрировать плагины в язык сценариев. В некоторых экосистемах (например, JVM или .NET) конкретный используемый язык не так уж важен, поскольку несколько языков в одной среде исполнения имеют хорошую совместимость. Например, я мог бы написать проект в Scala, который бы использовал существующие библиотеки Java и интегрировал функции скриптинга с Groovy.
Если проект состоит из нескольких инструментов, они также могут быть разработаны на разных языках. Хотя согласованность была бы хорошей, особенно для проектов с открытым исходным кодом, доступная разработка может быть узким местом. Если кто-то хочет разработать полезный инструмент, но не знаком с основным языком, возможно, этот инструмент более ценен, чем последовательность.
источник
Это имеет две формы и множество организаций, которые находятся где-то между ними:
Плохая форма - организация - это беспорядок, и никто не может быть уверен, что есть единственное технологическое видение усилий. Разработчики, скорее всего, используют тот язык, на котором они наиболее удобны, или недавно экспериментировали с новой структурой или языком и решили просто начать использовать их из-за наивного оптимизма.
Хорошая форма - организация имеет действительно хорошую, чистую архитектуру, которая хорошо подходит для программирования полиглотов; разделение приложений на независимые компоненты с четко определенным ограничивающим контекстом, и эта комбинация позволяет им выбирать язык программирования, который наиболее просто позволяет им писать этот конкретный компонент.
Реальность - это обычно скорее первое, чем второе. Я видел, как несколько компаний выбирают один язык для своего бизнес-домена, а другой - для своего веб-сервера, а часто и третий для администрирования своих баз данных, что технически хорошо, но довольно скоро они испытывают недостаток технического понимания (или отказ слушать своих сотрудников) означает, что они в итоге все три размываются в большом беспорядке и часто вводят еще больше языков, подходящих для решения определенных частей беспорядка.
источник
Я могу привести пример программного проекта, который был запущен 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, с общей численностью команды около пятидесяти.
источник
В некоторых случаях есть инструмент, который вам нужно использовать (например, инструментарий пользовательского интерфейса операционной системы), который наиболее легко доступен на данном языке. Например, для iOS и macOS, если вы хотите писать приложения с графическим интерфейсом с использованием UIKit и AppKit, написание в Swift или Objective-C - самый быстрый и простой способ сделать это. (Могут быть привязки для других языков, но они могут стоять за последним выпуском ОС, против которого вы строите, поэтому могут не предлагать все функции.)
Так часто случается, когда приложение является кроссплатформенным, основная логика приложения написана на каком-то языке, доступном для обоих, и специфичные для UI / OS части написаны на том языке, на котором они работают изначально.
Поэтому, если вы пишете приложение для Windows и MacOS, вы можете написать основную логику на C ++ и использовать C # для пользовательского интерфейса в Windows и Swift для пользовательского интерфейса в macOS. Это экономит время, потому что вам не нужно писать основную логику дважды и иметь дело с различными наборами ошибок в обоих приложениях и т. Д. Но это также позволяет использовать истинный собственный интерфейс, который не обслуживает наименьший общий знаменатель между платформами, как, например, использование кроссплатформенная библиотека пользовательского интерфейса будет.
источник
Помимо того, что некоторые языки программирования могут лучше подходить для некоторых конкретных задач, существует практическая реальность.
В практической реальности необходимо учитывать 2 особенно важных момента:
И, конечно, часто есть определенные части приложения, которые имеют совершенно разные потребности, такие как:
И вдобавок ко всему, существует довольно много инструментов, используемых сложной базой кода, многие из которых допускают необходимую настройку и плагины с еще одним языком.
источник
В дополнение к правильным уже сделанным пунктам:
из опыта многие решения по языку или окружающей среде принимаются «если у вас молоток, все выглядит как гвоздь», то есть люди склонны использовать инструменты, с которыми они знакомы.
Кроме того, внедрение новой среды или даже языка является основным вложением средств в лицензии, тренинги, возможно, аппаратное обеспечение, и приводит к значительным потерям продуктивного времени - на приобретение, установку, настройку, обучение каждую неделю уходит более крупная компания, и вы в основном заканчиваете с кучей начинающих разработчиков.
В принципе, никогда не бывает времени «инвестировать» в более современную или более подходящую среду или язык, поэтому они придерживаются того, что у них есть, до тех пор, пока оно просто не сможет больше работать.
Если говорить конкретно о вашем вопросе, если в разработке решения участвуют несколько человек / групп, каждая группа стремится придерживаться того, что им лучше всего известно, поэтому общее решение потенциально содержит несколько языков и разрабатывается в нескольких средах.
источник
Этот вопрос (и некоторые ответы), кажется, предполагают, что приложения являются монолитными блоками кода - это не обязательно так.
Ваш типичный веб-сайт, такой как Stack Exchange, на самом деле представляет собой набор различных сервисов, которые работают независимо друг от друга, и между ними есть своего рода обмен сообщениями. Эти сервисы могут быть (и обычно) реализованы на разных языках, каждый со своими сильными сторонами.
Я работаю над крошечной платформой онлайн-банковской платформы, ориентированной на небольшие банки и кредитные союзы. Эта платформа состоит из нескольких компонентов - веб-интерфейса, уровня базы данных, стороннего уровня связи и т. Д. Это все независимые приложения, работающие на разных серверах с разными операционными системами. У вас есть Javascript, работающий на стороне клиента в браузере, у вас есть страницы для создания Perl на стороне сервера, у вас есть несколько сервисов, написанных на C ++, выступающих в качестве уровня абстракции между кодом Perl и основным процессором банка, еще один набор приложений C ++, которые маршрутизировать сообщения между различными уровнями, разбирать приложения C ++ и сценарии Perl для мониторинга работоспособности различных процессов и сообщать об их состоянии на внутренний монитор и т. д. и т. д. и т. д.
Монолитные приложения все еще существуют, но даже они могут использовать разные языки по разным причинам. Вы можете написать 90% приложений на Java, но используйте JNI, чтобы использовать C или C ++ для более критичных для производительности разделов.
источник
Я хотел бы указать на очень конкретный пример мотива «разные языки имеют разные сильные стороны»: FORTRAN.
Первоначально Fortran был разработан, чтобы облегчить инженерам работу по числовому анализу, и с тех пор было приложено много усилий, чтобы компиляторы Fortran создавали очень эффективный числовой код. С другой стороны, с тех первых дней использование компьютеров резко возросло в тысяче направлений, ни одно из которых не связано с численным анализом, и развитие языков программирования в значительной степени следовало примеру игнорирования «реального» мира [простите за каламбур].
SO: Это сегодня, и вы работаете в компании с довольно обширным продуктом, большая часть которого написана (скажем) на Java (я говорю из личного опыта здесь) . Но вы обнаружите, что одна из основных особенностей продукта будет собирать некоторую форму численного анализа, и все лучшие коды для этого конкретного анализа уже доступны в сети - на Фортране. Ну так что ты делаешь? Вы загружаете один из этих кодов Фортрана, выясняете его интерфейс [т.е. аргументы самой верхней подпрограммы], подбираете для него оболочку JNI в C и упаковываете его как класс Java. BAM! Вы только что должны были развиваться на трех языках одновременно. [особенно если вы обнаружите, что ваш код на Фортране использует блоки COMMON - то есть статическое хранилище - и должен быть изменен для обеспечения безопасности потоков]
источник
Потому что программирование - это не одна задача. Даже создание продукта - не единственная задача. Есть несколько типов задач, которые лучше всего выражены на разных языках.
Чтобы сделать его более конкретным, давайте предположим что-то простое, например, автономное приложение (для распределенных приложений нужно выполнить больше задач).
Продукт должен быть
Язык, который может быть полезен для написания среды выполнения продукта, вряд ли будет так же хорош для сборки продукта. И так далее.
Однако даже процесс написания продукта не может быть оптимально выполнен на одном языке.
Допустим, в продукте обрабатывается много структурированных данных. Известна ли структура данных на момент написания? Если это так, вы захотите настроить некоторую базу данных во время развертывания. Это оптимально сделано на языке, который может генерировать язык, который будет компилироваться во время выполнения.
А что если структура данных может время от времени меняться? Чем вам нужен структурированный способ превращения новых конструкций данных в код и конфигурацию базы данных. Лучше всего это сделать на другом языке.
Можете ли вы сделать все это на одном языке? Конечно. Но ваша эффективность определяется тем, насколько быстро вы можете завершить проект и насколько он устойчив к изменениям. Если большая часть вашей работы может быть автоматизирована с помощью уже существующих инструментов, то то, что вам нужно сделать за 3 месяца, может быть выполнено кем-то другим за 2 дня. Но что кто-то будет использовать другие языки для автоматизации того, что вы будете делать через повторение.
источник
Разработка программного обеспечения достигла такого уровня, что вы можете использовать разные языки программирования в одном проекте и заставить его работать.
Тогда возникает вопрос, почему вы будете использовать более одного языка.
Одна из причин заключается в том, что языки устаревают и постепенно заменяются новыми, и, если вам повезет, это можно сделать постепенно. Таким образом, ваш проект будет иметь смесь старого и нового языка.
Другой причиной является ситуация, когда язык X очень похож на то, что используется на платформе A, язык Y очень похож на то, что используется на платформе B, но язык Z поддерживается на обеих платформах. Таким образом, общий код написан на языке Z, который затем комбинируется с X или Y, в зависимости от платформы.
И людям нравится использовать код, написанный другими (другими словами, код, на который им не нужно было тратить время, чтобы написать его самостоятельно). Они могут свободно использовать код, написанный другими на любом языке, а затем добавлять код на том языке, который предпочитают.
источник