Ця відповідь має чудове висвітлення та посилання на те, чому різні мови можуть надати певні переваги проекту. Однак у тому, чому проекти закінчуються використанням декількох мов, є дещо більше, ніж просто відповідність мові.
Проекти з шести основних причин використовують декілька мов:
- Вигідні переваги повторного використання коду, написаного іншими мовами;
- Необхідність включення та розміщення застарілого коду;
- Наявність кодерів для певних мов;
- Потреба у спеціальних мовах для спеціальних потреб;
- Спадкові упередження мови; і
- Погане управління проектами (незаплановане багатомовне використання).
Причини 1-4 є позитивними причинами в тому сенсі, що звернення до них безпосередньо може допомогти проекту укластись швидше, ефективніше, з якіснішим продуктом та легшою довгостроковою підтримкою. Причини 5 і 6 негативні, симптоми стійкості до необхідних змін, поганого планування, неефективного управління або певного поєднання всіх цих факторів. На жаль, ці негативні фактори є поширеними причинами "випадкового" багатомовного використання.
Причина 1 , вигідна витрата на повторне використання, стала все більш вагомою причиною дозволити використання декількох мов у проекті, що пояснюється як більшою роллю програмного забезпечення з відкритим кодом, так і вдосконаленими можливостями пошуку потрібних компонентів коду в Інтернеті. Філософія "давайте кодимо все це внутрішньо" останніх десятиліть продовжує згасати перед економічними реаліями і, по суті, ніколи не є найбільш рентабельним підходом до будь-якого нового проекту. Це, в свою чергу, робить менш чіткими можливості для суворого дотримання використання однієї мови в рамках проекту.
Особливо у випадку, коли проект використовує добре керовані компоненти з відкритим кодом, використання декількох мов може забезпечити величезні загальні переваги за витратами, оскільки багаторазово використані компоненти приховані за добре розробленими інтерфейсами і незалежно підтримуються зовнішніми групами з нульовою вартістю. У найкращих сценаріях змішування мов за допомогою такого повторного використання не є більш дорогим для проекту, ніж використання компонентів операційної системи. Я знаю не кращий приклад цінності цього підходу, ніж широкомасштабне впровадження програмного забезпечення з відкритим кодом Microsoft у своїх браузерах.
Причина 2 , необхідність розміщення застарілого коду, ігнорується в небезпеці будь-якого великого проекту. Хоча скільки завданих проблем може викликати спадковий код, наївно припускаючи, що його можна легко замінити новим кодом новою мовою, може бути неймовірно ризиковано. Спадковий код, навіть поганий застарілий код, часто включає те, що означає неявний «контракт» функцій, очікуваних громадою, яка використовує спадщину. Ця спільнота досить часто є головним джерелом доходу для компанії або основною ціллю підтримки урядового програмного забезпечення. Просто відмовившись від того, що мається на увазі контракт, може переслідувати обізнаних клієнтів у сукупності, і може банкрутувати компанію протягом ночі, якщо інші варіанти легко доступні.
У той же час, НЕ замінюючи старий код на старому мовою може бути настільки ж небезпечно , як замінити його оптовий продаж. Найгірший приклад - Адміністрація ветеранів США, яка має велику кількість життєво важливих систем, кодованих мовою MUMPS (не жартуючи), яку розробили медики, а не комп'ютери. Ніхто не хоче вчитися МУМП, і ті, хто це знає, буквально відмирають. Тому програмісти повинні вміщувати MUMPS навіть тоді, коли вони намагаються рухатися вперед до використання інших більш поширених, більш потужних і краще підтримуваних мов.
Цей тип багатомовного використання вимагає ретельного планування. Це планування має орієнтуватися на край ножа між втратою десятиліть знань клієнтів, з одного боку, та втратою здатності підтримувати програмне забезпечення з іншого. Можуть допомогти методи, які виділяють старий код за чітко визначеними інтерфейсами та дозволяють новому більш потужному коду замінити старий код після того, як його поведінка була добре зафіксована. Але цей спадковий сценарій ніколи не є простим, і став (і надалі буде) причиною припинення багатьох компаній та організацій у широкому спектрі.
Причина 3 , наявність кодерів для різних мов, є прагматичним фактором, який проекти ігнорують з їхньої небезпеки. Хоча організатори проекту можуть відчути (правильно чи неправильно), що певна мова найкраще відповідає їхнім цілям, якщо ця мова суперечить доступному для них мовному експертному пулу, і графік, і якість продукту постраждають від навчання. вигнута програмістами, які намагаються вивчити нову мову.
Більш раціональний підхід полягає в аналізі мовних потреб проекту на основі функціональних областей. Наприклад, при уважному огляді проекту може виявитись, що існує лише невеликий «вершина» коду високої вартості, наприклад, для реалізації якогось власного алгоритму, що вимагає знань з кодування на деякій менш поширеній мові. Інші частини будь-якого великого проекту часто легко розміщуються більш поширеними мовами або (ще краще) добре керованими продуктами з відкритим кодом. Аналіз проекту відповідно до мовних потреб може забезпечити набагато більш реалістичний та економічно ефективний підхід до найму або оренди спеціальних знань на спеціальних мовах, а також може допомогти загострити інтерфейси між мовами в рамках одного проекту.
Причина 4 , використовуючи різні мови для різних потреб, негайно і безперебійно випливає з виконання такого аналізу потреб проекту. У цьому слід також дотримуватися обережності, оскільки вибір занадто багато мов для підтримки в рамках одного проекту може спричинити комбінаторний вибух складності як у підтримці, так і в інтерфейсах між компонентами. Найбезпечніший маршрут - це завжди знайти максимальні можливості для повторного використання, особливо якщо існують хороші пакети, які можуть задовольнити потреби проекту за рахунок трохи більше, ніж налаштування. Далі слід прийняти якесь рішення щодо якоїсь невеликої кількості мов, яка може задовольнити більшість виявлених потреб. При інтенсивному використанні це буде часто типом коду клею.
Як правило, не дуже зручно обирати декілька мов із дуже схожими можливостями лише тому, що деякі члени проекту люблять одну, а іншу іншу. Однак, якщо є чітко визначені, чітко визначені підмножини можливостей, які б виграли від спеціальних мовних навичок, це може бути вагомою причиною для використання декількох мов для розробки нового коду.
Причина 5 : опір необхідним змінам у використаних мовах може стати причиною серйозного зриву проекту та внутрішньої суперечки. Як користувач Daveoзазначив у коментарі до цієї відповіді, зміни можуть бути дуже складними для деяких працівників проекту. У той же час, опір змінам ніколи не є простим питанням, саме тому це може спричинити великі чвари. Використання застарілих мовних навичок може стати потужним підвищенням продуктивності проекту, якщо застаріла мова є достатньо потужною і може призвести до продукту з відмінною якістю в команді, яка працює безперебійно і поважає якість. Однак застарілі знання мови повинні бути збалансовані з тим, що багато старих мов більше не можуть комплектуватися більш новими мовами з точки зору розширених функцій, доступності компонентів, опцій з відкритим кодом та інтелектуальної підтримки набору інструментів.
І тоді, і зараз єдиним найпоширенішим (і за іронією долі, найчастіше правильним) аргументом для продовження використання більш слабкої, менш читабельної чи менш продуктивної застарілої мови є те, що старша мова дозволяє створювати більш ефективний код. Це старий аргумент - той, що сягає аж до 1950-х років, коли користувачі асемблерної мови обурювались, часто з гіркістю, появою програмування у FORTRAN та LISP. Приклад, коли навіть аргумент ефективності коду може мати дійсність, можна побачити в інтенсивно оброблюваному коді, такому як ядро операційної системи, де C залишається мовою вибору над C ++ (хоча з причин, що виходять за рамки простої ефективності).
Однак у глобальних мережах та потужних машинно підтримуваних проектних середовищах нового тисячоліття ефективність коду як основного аргументу вибору мови проекту стала ще слабшою. Той самий вибух обчислювальних та мережевих апаратних засобів, що дав можливість масового маркетингу програм штучного інтелекту, також означає, що витрати на людське програмування можуть легко змінити витрати на неефективне виконання коду на надзвичайно дешевому апаратному та хмарному програмному забезпеченні. Коли це поєднується з більшою доступністю для більш сучасних мов бібліотек компонентів, опцій з відкритим кодом та розширених наборів інтелектуальних інструментів, кількість випадків, коли зберігання мови лише з міркувань ефективності стає дуже вузьким. Навіть у випадках, коли це застосовується,
Більш вагома причина того, що проект залишається зі застарілими мовами, виникає тоді, коли з будь-яких причин проект має мало або взагалі не має можливості змінити штат. Це може статися, наприклад, коли основна застаріла лінійка продуктів кодується повністю мовою, якою вільно володіє лише наявний персонал. У таких випадках проект повинен або продовжувати вниз шляхом спроб програмування старою мовою, або намагатися навчити наявний персонал, як використовувати нову мову.
Навчання штатних мовних службовців новою мовою може становити небезпеку само по собі. Я все ще пригадую випадок, коли учасник проекту, який щойно пройшов навчання та перехід з C на C ++, з усією щирістю скаржився на мене, що він просто не розуміє переваг об'єктно-орієнтованих методів. Коли я переглянув його код, він перетворив свої попередні 103 C функції в 103 методи для одного об’єктного класу C ++ ... і справедливо не бачив, як це нічого допомагає.
Більш глибоке повідомлення полягає в тому, що, коли люди роками або десятиліттями програмували в одній мові та мовному стилі, труднощі змусити їх «мислити» по-новому можуть стати майже непереборними навіть при хороших навчальних програмах. У деяких випадках може бути інший варіант, крім залучення молодих дизайнерів та програмістів, які більше співзвучні сучасним тенденціям та методам.
Причина 6 , погане управління проектами, говорить само за себе. Вибір мови та використання у проекті завжди слід розглядати та оцінювати чітко, а не допускати їх випадково. Принаймні, вибір мови може призвести до величезної зміни в довгостроковій долі та витратах на підтримку проекту, і тому його завжди слід враховувати та планувати. Не станьте МУМПОМ!