Ta odpowiedź ma doskonały zasięg i linki do tego, dlaczego różne języki mogą zapewnić wyraźne korzyści dla projektu. Jednak w projektach używających wielu języków jest coś więcej niż tylko przydatność językowa.
Projekty wykorzystują wiele języków z sześciu głównych powodów:
- Korzyść z ponownego użycia kodu napisanego w innych językach;
- Konieczność uwzględnienia i dostosowania starszego kodu;
- Dostępność koderów dla określonych języków;
- Potrzeba specjalnych języków dla potrzeb specjalnych;
- Uprzedzenia językowe starszego typu; i
- Słabe zarządzanie projektem (nieplanowane użycie w wielu językach).
Powody 1-4 są pozytywnymi powodami w tym sensie, że bezpośrednie zajęcie się nimi może pomóc w szybszym, bardziej efektywnym zakończeniu projektu dzięki produktowi wyższej jakości i łatwiejszemu długoterminowemu wsparciu. Powody 5 i 6 są negatywne, objawy oporności na potrzebne zmiany, złe planowanie, nieskuteczne zarządzanie lub kombinacja wszystkich tych czynników. Te negatywne czynniki są niestety częstymi przyczynami „przypadkowego” używania wielu języków.
Powód 1 , korzyści wynikające z ponownego użycia, stał się coraz silniejszym powodem pozwalającym na użycie wielu języków w projekcie, zarówno ze względu na większą rolę oprogramowania typu open source, jak i ulepszone możliwości znalezienia odpowiednich składników kodu w Internecie. Filozofia „zróbmy to wszystko wewnętrznie” z ostatnich dziesięcioleci nadal zanika w obliczu realiów gospodarczych i zasadniczo nigdy nie jest najbardziej opłacalnym podejściem dla każdego nowego projektu. To z kolei sprawia, że możliwości ścisłego egzekwowania użycia jednego języka w ramach projektu są mniej powszechne.
Zwłaszcza w przypadku ponownego wykorzystania dobrze zarządzanych komponentów open source użycie wielu języków może przynieść ogromne korzyści w zakresie kosztów ogólnych, ponieważ ponownie wykorzystane komponenty są ukryte za dobrze zaprojektowanymi interfejsami i są niezależnie obsługiwane przez grupy zewnętrzne o zerowych kosztach. W najlepszych przypadkach mieszanie języków za pomocą tego rodzaju ponownego użycia nie jest bardziej kosztowne dla projektu niż użycie komponentów systemu operacyjnego. Nie znam lepszego przykładu wartości tego podejścia niż przyjęcie przez Microsoft na szeroką skalę oprogramowania open source w swoich przeglądarkach.
Powód 2 , konieczność dostosowania starszego kodu, jest ignorowany na ryzyko każdego dużego projektu. Jednak wiele problemów może powodować starsze kody, naiwne zakładanie, że można go łatwo zastąpić nowym kodem w nowym języku, może być niezwykle ryzykowne. Starszy kod, nawet zły, starszy kod, często obejmuje to, co stanowi dorozumiany „kontrakt” funkcji oczekiwanych przez społeczność korzystającą ze starszego produktu. Ta społeczność dość często stanowi główne źródło dochodów firmy lub główny cel wsparcia oprogramowania rządowego. Po prostu odrzucenie tej dorozumianej umowy może ścigać świadomych klientów w masie i może zbankrutować firmę z dnia na dzień, jeśli inne opcje są łatwo dostępne.
Jednocześnie, nie zastępując stary kod w starym języku może być równie niebezpieczne, jak zastąpienie go hurtowej. Najgorszym przykładem jest Administracja Weteranów USA, która ma dużą liczbę ważnych systemów zakodowanych w języku o nazwie MUMPS (bez żartów), który został zaprojektowany przez lekarzy, a nie informatyków. Nikt nie chce się uczyć MUMPS, a ci, którzy go znają, dosłownie umierają. Programiści muszą zatem uwzględniać MUMPS, nawet gdy starają się korzystać z innych, bardziej popularnych, wydajniejszych i lepiej obsługiwanych języków.
Ten rodzaj użytkowania w wielu językach wymaga starannego planowania. To planowanie musi poruszać się na krawędzi noża między utratą dziesięcioleci wiedzy klientów z jednej strony, a utratą zdolności do obsługi oprogramowania z drugiej. Pomocne mogą być techniki, które izolują stary kod za dobrze zdefiniowanymi interfejsami i które pozwalają nowemu, bardziej wydajnemu kodowi zastąpić stary kod po dobrze udokumentowanym jego zachowaniu. Jednak ten tradycyjny scenariusz nigdy nie jest łatwy i był (i nadal będzie) przyczyną upadku wielu firm i organizacji o szerokim spektrum rozmiarów.
Powód 3 , dostępność koderów dla różnych języków, jest pragmatycznym czynnikiem, który projekty ignorują na własne ryzyko. Niezależnie od tego, jak bardzo organizatorzy projektu mogą uważać (poprawnie lub niepoprawnie), że dany język jest najlepszy dla ich celów, jeśli ten język stoi w sprzeczności z dostępną pulą wiedzy specjalistycznej, zarówno harmonogram, jak i jakość produktu ucierpią na nauce zakrzywiony programistów próbujących nauczyć się nowego języka.
Bardziej racjonalnym podejściem jest analiza potrzeb językowych projektu w oparciu o obszary funkcjonalne. Na przykład dokładne przyjrzenie się projektowi może wykazać, że istnieje tylko niewielki „wierzchołek” kodu o wysokiej wartości, np. Do implementacji zastrzeżonego algorytmu, który wymaga specjalistycznej wiedzy na temat kodowania w nieco rzadziej używanym języku. Inne części każdego dużego projektu są często łatwo dostępne dla bardziej popularnych języków lub (jeszcze lepiej) dla dobrze zarządzanych produktów open source. Analiza projektu pod kątem potrzeb językowych może w ten sposób zapewnić znacznie bardziej realistyczne i opłacalne podejście do zatrudniania lub wynajmu specjalnej wiedzy specjalistycznej w językach specjalnych, a także może pomóc wyostrzyć interfejsy między językami w ramach jednego projektu.
Powód 4 , używając różnych języków dla różnych potrzeb, wynika natychmiast i bezproblemowo z przeprowadzeniem tego rodzaju analizy potrzeb projektu. Należy również zachować ostrożność, ponieważ wybranie zbyt wielu języków do wsparcia w ramach jednego projektu może spowodować kombinatoryczną eksplozję złożoności zarówno pod względem obsługi, jak i interfejsów między komponentami. Najbezpieczniejszą trasą pod względem kosztów jest zawsze znalezienie maksymalnych możliwości ponownego wykorzystania, zwłaszcza jeśli istnieją dobre pakiety, które mogą zaspokoić potrzeby projektu poprzez niewiele więcej niż dostosowanie. Następnie należy podjąć decyzję dotyczącą niewielkiej liczby języków, które mogą zaspokoić większość zidentyfikowanych potrzeb. W przypadku intensywnego ponownego wykorzystania często będzie to rodzaj kodu kleju.
Zasadniczo nie jest dobrym pomysłem wybór wielu języków o bardzo podobnych możliwościach tylko dlatego, że niektórzy członkowie projektu lubią jeden, a drugi inny. Jeśli jednak istnieje dobrze określony, dobrze zdefiniowany podzbiór możliwości, który skorzystałby ze specjalnych umiejętności językowych, może to być dobry powód do używania wielu języków do tworzenia nowego kodu.
Powód 5 , opór wobec potrzebnych zmian w używanych językach, może być przyczyną poważnych zakłóceń projektu i wewnętrznych sporów. Jako użytkownik DaveoJak wskazano w komentarzu do tej odpowiedzi, zmiana może być bardzo trudna dla niektórych pracowników projektu. Jednocześnie opór przed zmianami nigdy nie jest prostym problemem i właśnie dlatego może powodować wiele konfliktów. Wykorzystanie starszych umiejętności językowych może znacznie zwiększyć produktywność projektu, jeśli starszy język jest wystarczająco mocny i może prowadzić do produktu o doskonałej jakości w zespole, który działa płynnie i szanuje jakość. Jednak starsze umiejętności językowe muszą być zrównoważone z faktem, że wiele starszych języków nie może już uzupełniać nowszymi językami pod względem zaawansowanych funkcji, dostępności komponentów, opcji open source i obsługi inteligentnego zestawu narzędzi.
Zarówno wtedy, jak i teraz, najczęstszym (i jak na ironię, najczęściej poprawnym) argumentem za dalszym używaniem słabszego, mniej czytelnego lub mniej produktywnego starszego języka było to, że starszy język umożliwia tworzenie bardziej wydajnego kodu. Jest to stary argument, który sięga aż do lat 50. XX wieku, kiedy użytkownicy języka asemblerowego, często z goryczą, pojawiali się programowania w FORTRAN i LISP. Przykład, w którym nawet teraz argument wydajności kodu może mieć ważność, można zobaczyć w kodzie intensywnie przetwarzającym, takim jak jądro systemu operacyjnego, gdzie C pozostaje językiem wybieranym niż C ++ (choć z powodów, które wykraczają poza prostą wydajność).
Jednak w globalnie połączonych i wspieranych maszynowo środowiskach projektowych nowego tysiąclecia wydajność kodu jako główny argument za wyborem języka projektu wzrosła jeszcze bardziej. Ta sama eksplozja sprzętu komputerowego i sieciowego, która umożliwiła masowe wprowadzanie na rynek aplikacji sztucznej inteligencji, oznacza również, że koszty ludzkiego programowania mogą z łatwością przewyższyć koszty względnego nieefektywnego wykonania kodu na spektakularnie tanim sprzęcie i oprogramowaniu chmurowym. W połączeniu z większą dostępnością najnowszych bibliotek bibliotek komponentów, opcjami open source i zaawansowanymi inteligentnymi zestawami narzędzi liczba przypadków, w których utrzymanie języka tylko ze względów wydajnościowych staje się bardzo wąskie. Nawet w przypadkach, w których ma to zastosowanie,
Bardziej przekonujący powód, dla którego projekt pozostaje w dotychczasowych językach, występuje, gdy z jakichkolwiek powodów projekt nie ma wielu opcji zmiany personelu lub nie ma go wcale. Może się to zdarzyć na przykład, gdy duża starsza linia produktów jest całkowicie zakodowana w języku, w którym biegły jest tylko istniejący personel. W takich przypadkach projekt musi albo kontynuować próbę programowania w starym języku, albo próbować przeszkolić dotychczasowych pracowników w zakresie korzystania z nowego języka.
Szkolenie starszych pracowników języka w nowym języku może samo w sobie stanowić zagrożenie. Nadal pamiętam przypadek, w którym członek projektu, który właśnie został przeszkolony i przeszedł z C do C ++, szczerze narzekał, że po prostu nie rozumie zalet metod obiektowych. Kiedy spojrzałem na jego kod, przekonwertował wcześniejsze funkcje 103 C na 103 metody dla jednej klasy obiektów C ++ ... i słusznie nie widział, jak to pomogło.
Głębsze przesłanie jest takie, że kiedy ludzie programują w jednym języku i stylu językowym od lat lub dziesięcioleci, trudność zmuszenia ich do „myślenia” w nowy sposób może stać się prawie nie do pokonania, nawet przy dobrych programach szkoleniowych. W niektórych przypadkach może nie być innej opcji, jak tylko sprowadzić młodszych projektantów i programistów, którzy lepiej dostosowują się do aktualnych trendów i metod.
Powód 6 , złe zarządzanie projektem, mówi samo za siebie. Wybór języka i użycie w projekcie zawsze należy brać pod uwagę i oceniać w sposób wyraźny, a przypadek nie powinien mieć miejsca. Przynajmniej wybór języka może mieć ogromną różnicę w długoterminowym losie i kosztach wsparcia projektu, dlatego należy go zawsze brać pod uwagę i planować. Nie zostań MUMPSEM!