Этот ответ имеет превосходное освещение и ссылки на то, почему разные языки могут обеспечить различные преимущества для проекта. Тем не менее, существует несколько больше, чем просто языковая пригодность, связанная с тем, почему проекты заканчиваются использованием нескольких языков.
Проекты заканчиваются использованием нескольких языков по шести основным причинам:
- Экономическая выгода повторного использования кода, написанного на других языках;
- Необходимость включать и учитывать устаревший код;
- Наличие кодеров для конкретных языков;
- Потребность в специальных языках для специальных нужд;
- Унаследованные языковые предубеждения; а также
- Плохое управление проектом (незапланированное многоязычное использование).
Причины 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!