Questa risposta ha una superba copertura e collegamenti sul perché diverse lingue possono offrire vantaggi distinti a un progetto. Tuttavia, c'è molto di più della semplice idoneità linguistica per cui i progetti finiscono per usare più lingue.
I progetti finiscono per utilizzare più lingue per sei motivi principali:
- Vantaggi economici del riutilizzo del codice scritto in altre lingue;
- La necessità di includere e accogliere il codice legacy;
- Disponibilità di programmatori per lingue specifiche;
- La necessità di lingue speciali per esigenze speciali;
- Pregiudizi linguistici legacy; e
- Cattiva gestione del progetto (uso multilingue non pianificato).
Le ragioni 1-4 sono ragioni positive nel senso che affrontarle direttamente può aiutare un progetto a concludersi più velocemente, in modo più efficiente, con un prodotto di qualità superiore e con un supporto a lungo termine più semplice. I motivi 5 e 6 sono negativi, sintomi di resistenza ai cambiamenti necessari, scarsa pianificazione, gestione inefficace o una combinazione di tutti questi fattori. Sfortunatamente, questi fattori negativi sono cause comuni dell'uso multilingue "accidentale".
La ragione 1 , i vantaggi in termini di costi del riutilizzo, è diventata una ragione sempre più potente per consentire l'uso di più lingue in un progetto sia per il ruolo maggiore del software open source sia per le migliori capacità di trovare i giusti componenti di codice sul web. La filosofia "decifriamo tutto internamente" degli ultimi decenni continua a svanire di fronte alle realtà economiche e non è sostanzialmente l'approccio più conveniente per qualsiasi nuovo progetto. Ciò a sua volta rende meno comuni le opportunità per un'applicazione rigorosa dell'uso di una sola lingua all'interno di un progetto.
Soprattutto nel caso di un progetto che riutilizzi componenti open source ben gestiti, l'uso di più lingue può offrire enormi vantaggi in termini di costi complessivi poiché i componenti riutilizzati sono entrambi nascosti dietro interfacce ben progettate e gestiti indipendentemente da gruppi esterni a costo zero. Negli scenari migliori, la miscelazione delle lingue tramite questo tipo di riutilizzo non è più costosa per il progetto rispetto all'utilizzo dei componenti del sistema operativo. Non conosco un esempio migliore del valore di questo approccio rispetto all'adozione su larga scala di software open source da parte di Microsoft nei loro browser.
Il motivo 2 , la necessità di inserire il codice legacy, viene ignorato a rischio di qualsiasi progetto di grandi dimensioni. Per quanto possano causare molti problemi il codice legacy, assumere ingenuamente che possa essere facilmente sostituito con un nuovo codice in una nuova lingua può essere incredibilmente rischioso. Il codice legacy, anche un codice legacy errato, spesso include ciò che equivale a un "contratto" implicito di funzionalità previste dalla comunità che utilizza il prodotto legacy. Quella comunità abbastanza spesso è una delle principali fonti di entrate per un'azienda o il principale obiettivo di supporto per i software governativi. Scartare semplicemente quel contratto implicito può inseguire i clienti consapevoli a frotte e può far fallire una società durante la notte se altre opzioni sono prontamente disponibili.
Allo stesso tempo, non sostituire il vecchio codice in una vecchia lingua può essere pericoloso quanto sostituirlo all'ingrosso. Un esempio nel caso peggiore è l'amministrazione americana dei veterani, che ha un gran numero di sistemi vitali codificati in una lingua chiamata MUMPS (senza scherzi) progettata da medici, non da informatici. Nessuno vuole imparare MUMPS e quelli che lo sanno stanno letteralmente morendo. I programmatori devono quindi adattarsi a MUMPS anche se cercano di passare ad altri linguaggi più comuni, più potenti e meglio gestiti.
Questo tipo di uso multilingue richiede un'attenta pianificazione. Tale pianificazione deve superare il limite tra la perdita di decenni di conoscenza dei clienti da un lato e la capacità di supportare il software dall'altro. Le tecniche che isolano il vecchio codice dietro interfacce ben definite e che consentono a un nuovo codice più potente di sostituire il vecchio codice dopo che i suoi comportamenti sono stati ben documentati, possono aiutare. Ma questo scenario ereditario non è mai facile ed è stato (e continuerà ad essere) la causa della scomparsa di molte aziende e organizzazioni in un ampio spettro di dimensioni.
La ragione 3 , la disponibilità di programmatori per varie lingue, è un fattore pragmatico che i progetti ignorano a loro rischio e pericolo. Per quanto gli organizzatori del progetto possano ritenere (correttamente o erroneamente) che una determinata lingua sia la migliore per i loro obiettivi, se tale lingua è in conflitto con il pool di competenze linguistiche a loro disposizione, sia il programma che la qualità del prodotto subiranno l'apprendimento curvo di programmatori che cercano di imparare una nuova lingua.
Un approccio più razionale è quello di analizzare le esigenze linguistiche del progetto sulla base di aree funzionali. Ad esempio, osservare attentamente il progetto può mostrare che esiste solo un piccolo "apice" di codice di alto valore, ad esempio per l'implementazione di un algoritmo proprietario, che richiede competenze di codifica in un linguaggio meno comunemente usato. Altre parti di qualsiasi grande progetto sono spesso facilmente adattate da linguaggi più comuni o (anche meglio) da prodotti open source ben gestiti. L'analisi di un progetto in base alle esigenze linguistiche può quindi fornire un approccio molto più realistico ed economico all'assunzione o al noleggio di competenze speciali in lingue speciali e può anche aiutare ad affinare le interfacce tra le lingue all'interno di un singolo progetto.
Il motivo 4 , utilizzando lingue diverse per esigenze diverse, segue immediatamente e senza intoppi l'esecuzione di quel tipo di analisi delle esigenze del progetto. Anche in questo caso occorre prestare attenzione, poiché la selezione di troppe lingue per il supporto all'interno di un singolo progetto può causare un'esplosione combinatoria di complessità sia nel supporto che nelle interfacce tra i componenti. Il percorso più sicuro dal punto di vista dei costi è sempre quello di trovare prima le massime opportunità di riutilizzo, soprattutto se esistono buoni pacchetti in grado di soddisfare le esigenze del progetto attraverso poco più della personalizzazione. Successivamente, dovrebbe essere presa una qualche decisione su un numero limitato di lingue in grado di soddisfare la maggior parte delle esigenze individuate. Nello sviluppo ad alta intensità di riutilizzo, questo sarà spesso un tipo di codice colla.
In genere non è una buona idea scegliere più lingue con capacità molto simili solo perché alcuni membri del progetto gradiscono l'uno e l'altro. Tuttavia, se esistono sottoinsiemi di capacità ben identificati e ben definiti che trarrebbero vantaggio da abilità linguistiche speciali, ciò può essere un buon motivo per utilizzare più lingue per lo sviluppo di nuovi codici.
Il motivo 5 , la resistenza ai cambiamenti necessari nelle lingue utilizzate, può essere causa di gravi interruzioni del progetto e conflitti interni. Come utente Daveosottolineato in un commento su questa risposta, il cambiamento può essere molto difficile per alcuni membri del personale del progetto. Allo stesso tempo, la resistenza al cambiamento non è mai un problema semplice, motivo per cui può causare molti conflitti. L'uso delle competenze linguistiche legacy può essere un forte impulso alla produttività di un progetto se il linguaggio legacy è sufficientemente potente e può portare a un prodotto di eccellente qualità in un team che opera senza intoppi e rispetta la qualità. Tuttavia, le competenze linguistiche legacy devono essere bilanciate dal fatto che molte lingue meno recenti non possono più essere completate con lingue più recenti in termini di funzionalità avanzate, disponibilità dei componenti, opzioni open source e supporto di kit di strumenti intelligenti.
Sia allora che ora, il singolo argomento più comune (e ironicamente, il più spesso corretto) per continuare a usare un linguaggio legacy più debole, meno leggibile o meno produttivo è stato che il linguaggio più vecchio consente la produzione di codice più efficiente. Questo è un vecchio argomento, che risale agli anni '50 quando gli utenti del linguaggio assembly si risentirono, spesso amaramente, dell'emergere della programmazione in FORTRAN e LISP. Un esempio in cui anche ora l'argomento sull'efficienza del codice può avere validità può essere visto nel codice ad alta intensità di elaborazione come un kernel di sistemi operativi, in cui C rimane il linguaggio di scelta su C ++ (anche se per ragioni che vanno oltre la semplice efficienza).
Tuttavia, negli ambienti di progetto del nuovo millennio collegati in rete e fortemente supportati dalle macchine, l'efficienza del codice come argomento principale per la scelta di un linguaggio di progetto è diventata ancora più debole. La stessa esplosione dell'hardware informatico e di rete che ha permesso il marketing di massa di applicazioni di intelligenza artificiale significa anche che i costi della programmazione umana possono facilmente sminuire quelli dell'inefficienza della relatività nell'esecuzione di codice su hardware e cloud incredibilmente economici. Quando questo è combinato con la maggiore disponibilità in linguaggi più recenti di librerie di componenti, opzioni open source e kit di strumenti intelligenti avanzati, il numero di casi in cui il mantenimento di una lingua per motivi di efficienza da sola diventa molto limitato. Anche nei casi in cui si applica,
Una ragione più convincente per un progetto di rimanere con i linguaggi legacy si verifica quando per qualsiasi motivo un progetto ha poche o nessuna opzione per cambiare il suo staff. Ciò può accadere, ad esempio, quando una linea di prodotti legacy principale è codificata interamente in una lingua con la quale solo il personale esistente parla fluentemente. In tali casi, il progetto deve continuare a cercare di programmare nella vecchia lingua o tentare di formare il personale esistente sull'uso di una nuova lingua.
Formare il personale linguistico legacy in una nuova lingua può essere un pericolo da solo. Ricordo ancora un caso in cui un membro di un progetto appena addestrato e passato da C a C ++ si lamentava con sincerità del fatto che non capiva i vantaggi dei metodi orientati agli oggetti. Quando ho guardato il suo codice, aveva convertito le sue precedenti 103 funzioni C in 103 metodi per una singola classe di oggetti C ++ ... e giustamente non vedevo come ciò potesse aiutare qualcosa.
Il messaggio più profondo è che quando le persone hanno programmato in una sola lingua e stile linguistico per anni o decenni, la difficoltà nel farle "pensare" in nuovi modi può diventare quasi insormontabile, anche con buoni programmi di formazione. In alcuni casi potrebbe non esserci altra opzione se non quella di coinvolgere designer e programmatori più giovani che siano più in sintonia con le tendenze e i metodi attuali.
Motivo 6 , cattiva gestione del progetto, parla da sé. La selezione e l'uso della lingua in un progetto devono essere sempre considerati e valutati in modo esplicito e non devono avvenire per caso. Per lo meno, la selezione della lingua può fare un'enorme differenza nel destino a lungo termine e nei costi di supporto di un progetto, e quindi dovrebbe sempre essere presa in considerazione e pianificata. Non diventare un MUMPS!