Cette réponse offre une couverture superbe et des liens sur les raisons pour lesquelles différentes langues peuvent apporter des avantages distincts à un projet. Cependant, il y a bien plus que la simple adaptation de la langue pour expliquer pourquoi les projets finissent par utiliser plusieurs langues.
Les projets finissent par utiliser plusieurs langues pour six raisons principales:
- Avantages financiers de la réutilisation de code écrit dans d'autres langues;
- La nécessité d'inclure et d'adapter le code existant;
- Disponibilité de codeurs pour des langues spécifiques;
- Le besoin de langues spéciales pour les besoins particuliers;
- Préjugés linguistiques hérités; et
- Mauvaise gestion de projet (utilisation multilingue non planifiée).
Les raisons 1 à 4 sont des raisons positives dans la mesure où leur traitement direct peut aider un projet à conclure plus rapidement, plus efficacement, avec un produit de meilleure qualité et un soutien plus facile à long terme. Les raisons 5 et 6 sont négatives, des symptômes de résistance au changement nécessaire, une mauvaise planification, une gestion inefficace ou une combinaison de tous ces facteurs. Malheureusement, ces facteurs négatifs sont des causes courantes d’utilisation multilingue «accidentelle».
Reason 1 , les avantages financiers de la réutilisation, est devenu une raison de plus en plus puissante pour autoriser l’utilisation de plusieurs langues dans un projet, à la fois en raison du rôle accru des logiciels open source et des capacités améliorées permettant de rechercher les composants de code appropriés sur le Web. La philosophie des dernières décennies consistant à «coder tout cela en interne» continue de s’affaiblir face aux réalités économiques et n’est en principe jamais l’approche la plus rentable pour tout nouveau projet. Cela rend par contre moins fréquente les possibilités d'une application stricte de l'utilisation d'une seule langue dans un projet.
Particulièrement dans le cas d’un projet réutilisant des composants Open Source bien gérés, l’utilisation de plusieurs langages peut offrir d’énormes avantages en termes de coûts globaux, car les composants réutilisés sont cachés derrière des interfaces bien conçues et gérés indépendamment par des groupes externes à coût zéro. Dans le meilleur des scénarios, le mélange de langues via ce type de réutilisation n’est pas plus coûteux pour le projet que l’utilisation de composants du système d’exploitation. Je ne connais pas de meilleur exemple de la valeur de cette approche que l'adoption à grande échelle de logiciels open source par Microsoft dans leurs navigateurs.
La raison 2 , la nécessité de prendre en compte le code existant, est ignorée aux risques de tout projet de grande envergure. Quels que soient les problèmes rencontrés par le code hérité, supposer naïvement qu’il peut être facilement remplacé par un nouveau code dans une nouvelle langue peut être extrêmement risqué. Le code hérité, même incorrect, inclut souvent ce qui constitue un "contrat" implicite de fonctionnalités attendues par la communauté qui utilise le produit hérité. Cette communauté est souvent une source majeure de revenus pour une entreprise ou la cible principale du support des logiciels gouvernementaux. Le simple fait de se défaire de ce contrat implicite peut chasser en masse des clients avertis et peut mettre une entreprise en faillite du jour au lendemain si d'autres options sont facilement disponibles.
En même temps, ne pas remplacer un ancien code dans une ancienne langue peut être aussi dangereux que de le remplacer en gros. Le pire exemple est celui de la US Veterans Administration, qui possède un grand nombre de systèmes essentiels codés dans un langage appelé MUMPS (sans blague) conçu par des médecins et non par des informaticiens. Personne ne veut apprendre MUMPS, et ceux qui le savent sont en train de mourir. Les programmeurs doivent donc prendre en charge MUMPS, même s'ils essaient d'utiliser d'autres langues plus courantes, plus puissantes et mieux conservées.
Ce type d’utilisation multilingue nécessite une planification minutieuse. Cette planification doit naviguer entre les décennies de perte de connaissance client et celle de prise en charge du logiciel, de l'autre. Des techniques qui isolent l'ancien code derrière des interfaces bien définies et permettent à un nouveau code plus puissant de remplacer l'ancien code une fois ses comportements bien documentés peuvent être utiles. Mais ce scénario hérité n’est jamais facile et a été (et continuera d’être) la cause de la disparition de nombreuses entreprises et organisations de tailles très diverses.
La raison 3 , la disponibilité de codeurs pour différentes langues, est un facteur pragmatique que les projets ignorent à leurs risques et périls. Si les organisateurs du projet peuvent estimer (correctement ou incorrectement) qu’une langue particulière est plus adaptée à leurs objectifs, si cette langue est en conflit avec le pool de compétences linguistiques dont ils disposent, le calendrier et la qualité du produit en souffriront. incurvée de programmeurs essayant d’apprendre une nouvelle langue.
Une approche plus rationnelle consiste à analyser les besoins linguistiques du projet en fonction de domaines fonctionnels. Par exemple, un examen attentif du projet peut montrer qu’il n’ya qu’un petit "sommet" de code de grande valeur, permettant par exemple de mettre en oeuvre un algorithme propriétaire, qui nécessite une expertise en matière de codage dans un langage moins communément utilisé. D'autres parties d'un grand projet sont souvent facilement prises en charge par des langages plus courants, ou (mieux encore) par des produits open source bien gérés. Analyser un projet en fonction des besoins linguistiques peut donc fournir une approche beaucoup plus réaliste et moins coûteuse d’embaucher ou de louer une expertise spécifique dans des langues spéciales, mais également contribuer à affiner les interfaces entre les langues d’un même projet.
Reason 4 , utilisant différentes langues pour différents besoins, découle immédiatement et sans à-coups de ce type d'analyse des besoins du projet. Vous devez également faire preuve de prudence, car la sélection d'un trop grand nombre de langues pour la prise en charge au sein d'un même projet peut entraîner une explosion combinatoire de complexité, à la fois en prise en charge et en interfaces entre composants. La solution la plus sûre en termes de coûts consiste toujours à rechercher d’abord le maximum d’opportunités de réutilisation, en particulier s’il existe de bons packages capables de répondre aux besoins du projet par le biais de la personnalisation. Ensuite, il convient de prendre une décision sur un petit nombre de langues pouvant répondre à la majorité des besoins identifiés. Dans les développements intensifs en réutilisation, il s’agit souvent d’un type de code collé.
Ce n’est généralement pas une bonne idée de choisir plusieurs langues avec des capacités très similaires simplement parce que certains membres du projet aiment l’un et l’autre. Cependant, s'il existe des sous-ensembles de capacités bien identifiés et bien définis qui pourraient bénéficier de compétences linguistiques particulières, cela peut constituer une bonne raison d'utiliser plusieurs langues pour le développement de nouveaux codes.
Raison 5 , la résistance aux changements nécessaires dans les langues utilisées peut être une cause de grave perturbation du projet et de conflits internes. En tant qu'utilisateur DaveoComme souligné dans un commentaire sur cette réponse, le changement peut être très difficile pour certains membres du personnel du projet. Dans le même temps, la résistance au changement n’est jamais un problème simple, c’est précisément pourquoi elle peut causer beaucoup de conflits. L'utilisation des compétences linguistiques héritées peut être un puissant stimulant pour la productivité d'un projet si le langage hérité est suffisamment puissant, et peut conduire à un produit d'excellente qualité pour une équipe qui fonctionne sans heurts et respecte la qualité. Toutefois, les compétences linguistiques existantes doivent être compensées par le fait que de nombreuses langues plus anciennes ne peuvent plus être complétées par des langues plus récentes en termes de fonctionnalités avancées, de disponibilité des composants, d’options open source et de prise en charge des kits d’outils intelligents.
Autrefois et aujourd'hui, l'argument le plus commun (et paradoxalement, le plus souvent correct) pour continuer à utiliser un langage hérité plus faible, moins lisible ou moins productif était que l'ancien langage permettait la production de code plus efficace. C'est un argument ancien, qui remonte aux années 1950, lorsque les utilisateurs du langage d'assemblage ressentaient avec amertume l'émerveillement de la programmation en FORTRAN et LISP. Un exemple où même l’argument d’efficacité du code peut avoir une validité peut être vu dans le code exigeant en traitement, tel qu’un noyau de système d’exploitation, où C reste la langue de choix par rapport à C ++ (bien que pour des raisons qui vont au-delà de la simple efficacité).
Cependant, dans les environnements de projet du nouveau millénaire, puissamment soutenus par des machines et en réseau, mondialement, l'efficacité du code comme principal argument pour choisir une langue de projet s'est encore affaiblie. La même explosion de matériel informatique et de réseau qui a permis la commercialisation en masse d’applications d’intelligence artificielle signifie également que les coûts de programmation humaine peuvent facilement être supérieurs à ceux d’une exécution de code inefficace par rapport à une exécution de code inefficace sur du matériel et des logiciels cloud spectaculairement économiques. Lorsque cela s’ajoute à la disponibilité accrue de bibliothèques de composants, d’options open source et de kits d’outils intelligents avancés dans les langages plus récents, le nombre de cas dans lesquels le maintien d’une langue pour des raisons d’efficacité seule devient très restreint. Même dans les cas où cela s'applique,
Une raison plus convaincante pour un projet de rester avec les langages hérités survient lorsque, pour quelque raison que ce soit, un projet n’a que peu ou pas d’options pour changer de personnel. Cela peut se produire, par exemple, lorsqu'une grande gamme de produits existants est entièrement codée dans une langue dans laquelle seul le personnel existant parle couramment. Dans ce cas, le projet doit soit continuer d'essayer de programmer dans l'ancienne langue, soit essayer de former le personnel en place à l'utilisation d'une nouvelle langue.
Former le personnel linguistique existant dans une nouvelle langue peut être un danger en soi. Je me souviens encore d'un cas dans lequel un membre d'un projet qui venait d'être formé et qui passait de C à C ++ s'était plaint sincèrement de ne pas comprendre les avantages des méthodes orientées objet. Lorsque j'ai examiné son code, il avait converti ses fonctions 103 C antérieures en 103 méthodes pour une seule classe d'objets C ++ ... et à juste titre, il n'avait pas vu en quoi cela pouvait aider.
Le message plus profond est que, lorsque des personnes ont programmé dans une langue et un style de langue uniques pendant des années ou des décennies, il est difficile de les amener à "penser" de nouvelles façons, même avec de bons programmes de formation. Dans certains cas, il n’ya peut-être pas d’autre option que de faire venir des designers et des programmeurs plus jeunes, plus au courant des tendances et des méthodes actuelles.
Reason 6 , mauvaise gestion de projet, parle pour lui-même. La sélection et l'utilisation de la langue dans un projet doivent toujours être considérées et évaluées de manière explicite, et ne doivent pas se produire par accident. À tout le moins, le choix de la langue peut avoir un impact considérable sur le destin à long terme et les coûts de support d'un projet, et doit donc toujours être pris en compte et planifié. Ne devenez pas un MUMPS!