Pourquoi plusieurs langages de programmation sont-ils utilisés dans le développement d'un produit ou d'un logiciel?
Je suis un étudiant récemment diplômé visant à démarrer ma maîtrise en informatique. J'ai rencontré plusieurs projets open source qui m'intriguent vraiment et m'encouragent à y contribuer (CloudStack, OpenStack, moby et Kubernetes pour n'en nommer que quelques-uns). Une chose que j'ai trouvée que la majorité d'entre eux ont en commun est l'utilisation de plusieurs langages de programmation (comme Java + Python + Go ou Python + C++ + Ruby). J'ai déjà examiné cette autre question, qui traite de la façon dont plusieurs langages de programmation sont faits pour communiquer entre eux: Comment avoir deux programmations différentes avec deux différentes les langues interagissent?
Je veux comprendre l'exigence qui incite les entreprises à utiliser plusieurs langages de programmation. Quelle exigence ou type d'exigence oblige l'architecte logiciel ou le chef de projet à dire: "Je propose d'utiliser le langage X pour la tâche 1 et le langage Y pour la tâche 2"? Je n'arrive pas à comprendre la raison pour laquelle plusieurs langages de programmation sont utilisés dans le même produit ou logiciel.
Cette réponse a une superbe couverture et des liens sur les raisons pour lesquelles différentes langues peuvent offrir des avantages distincts à un projet. Cependant, il y a beaucoup plus que la pertinence linguistique impliquée dans la raison pour laquelle les projets finissent par utiliser plusieurs langues.
Les projets finissent par utiliser plusieurs langues pour six raisons principales:
- Avantages économiques de la réutilisation de code écrit dans d'autres langues;
- La nécessité d'inclure et d'accommoder le code hérité;
- Disponibilité de codeurs pour des langues spécifiques;
- Le besoin de langues spéciales pour les besoins spécialisés;
- Les 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 le sens où les aborder directement peut aider un projet à se conclure plus rapidement, plus efficacement, avec un produit de meilleure qualité et avec un support à long terme plus facile. Les raisons 5 et 6 sont négatives, des symptômes de résistance aux changements nécessaires, une mauvaise planification, une gestion inefficace ou une combinaison de tous ces facteurs. Ces facteurs négatifs sont malheureusement des causes courantes d'utilisation "accidentelle" de plusieurs langues.
La raison 1 , les avantages économiques de la réutilisation, est devenue une raison de plus en plus puissante pour permettre l'utilisation de plusieurs langues dans un projet en raison à la fois du rôle plus important de logiciel open source et capacités améliorées pour trouver les bons composants de code sur le Web. La philosophie "codons tout en interne" des dernières décennies continue de s'estomper face aux réalités économiques et n'est essentiellement jamais l'approche la plus rentable pour de nouveaux projets. À son tour, cela réduit les possibilités d'application stricte de l'utilisation d'une seule langue dans un projet.
En particulier dans le cas d'un projet réutilisant des composants open source bien gérés, l'utilisation de plusieurs langues peut offrir d'énormes avantages sur le plan des coûts globaux, car les composants réutilisés sont à la fois cachés derrière des interfaces bien conçues et gérés indépendamment par des groupes externes à coût nul. Dans le meilleur des cas, le mélange des langues via ce type de réutilisation n'est pas plus coûteux pour le projet que l'utilisation des 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é d'adapter le code hérité, est ignorée aux risques et périls de tout grand projet. Quel que soit le problème que le code hérité peut causer, supposer naïvement qu'il peut être remplacé facilement par un nouveau code dans une nouvelle langue peut être extrêmement risqué. Le code hérité, même le mauvais code hérité, comprend souvent ce qui équivaut à un "contrat" implicite de fonctionnalités attendu par la communauté qui utilise le produit hérité. Cette communauté est assez souvent une source majeure de revenus pour une entreprise, ou la principale cible du support pour les logiciels gouvernementaux. Le simple fait de rejeter ce contrat implicite peut chasser des clients en masse et peut mettre en faillite une entreprise du jour au lendemain si d'autres options sont facilement disponibles.
En même temps, pas remplacer l'ancien code dans une ancienne langue peut être aussi dangereux que le remplacer en gros. Le pire exemple est celui de la US Veterans Administration, qui possède un grand nombre de systèmes vitaux codés dans un langage appelé MUMPS (sans blague) qui a été conçu par des médecins et non par des informaticiens. Personne ne veut apprendre MUMPS, et ceux qui le savent meurent littéralement. Les programmeurs doivent donc s'adapter à MUMPS alors même qu'ils essaient d'avancer vers l'utilisation d'autres langages plus courants, plus puissants et mieux entretenus.
Ce type d'utilisation multilingue nécessite une planification minutieuse. Cette planification doit naviguer dans le couteau entre perdre des décennies de connaissances client d'une part et perdre la capacité de prendre en charge le logiciel de l'autre. Les techniques qui isolent l'ancien code derrière des interfaces bien définies et qui permettent à un nouveau code plus puissant de remplacer l'ancien code après que ses comportements ont été bien documentés peuvent aider. 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 dans un large éventail de tailles.
La raison 3 , la disponibilité de codeurs pour différentes langues, est un facteur pragmatique que les projets ignorent à leurs risques et périls. Quelle que soit la façon dont les organisateurs du projet peuvent estimer (correctement ou incorrectement) qu'une langue particulière convient le mieux à leurs objectifs, si cette langue est en conflit avec le bassin d'expertise linguistique à leur disposition, le calendrier et la qualité du produit souffriront de l'apprentissage incurvé de programmeurs essayant d'apprendre une nouvelle langue.
Une approche plus rationnelle consiste à analyser les besoins linguistiques du projet en fonction des domaines fonctionnels. Par exemple, un examen attentif du projet peut montrer qu'il n'y a qu'un petit "sommet" de code de grande valeur, par ex. pour implémenter un algorithme propriétaire, qui nécessite une expertise en codage dans un langage moins couramment utilisé. D'autres parties de tout grand projet sont souvent facilement prises en charge par des langages plus courants, ou (encore mieux) par des produits open source bien gérés. L'analyse d'un projet en fonction des besoins linguistiques peut ainsi fournir une approche beaucoup plus réaliste et rentable de l'embauche ou de la location d'expertise spéciale dans des langues spéciales, et peut également aider à affiner les interfaces entre les langues au sein d'un même projet.
Reason 4 , en utilisant différentes langues pour différents besoins, découle immédiatement et sans heurts de ce type d'analyse des besoins du projet. Il convient également de faire attention à cela, car la sélection d'un trop grand nombre de langues pour la prise en charge au sein d'un même projet peut provoquer une explosion combinatoire de la complexité à la fois dans la prise en charge et dans les interfaces entre les composants. Le chemin le plus sûr en termes de coûts est toujours de trouver les opportunités maximales de réutilisation en premier, surtout s'il existe de bons packages qui peuvent répondre aux besoins du projet par le biais de la personnalisation. Ensuite, une sorte de décision devrait être prise sur un petit nombre de langues pouvant répondre à la majorité des besoins identifiés. Dans le développement à réutilisation intensive, ce sera souvent un type de code de colle.
C'est généralement pas une bonne idée de choisir plusieurs langues avec des capacités très similaires juste parce que certains membres du projet aiment l'un et d'autres. Cependant, s'il existe un sous-ensemble de capacités bien identifié et bien défini qui bénéficierait de compétences linguistiques particulières, cela peut être une bonne raison d'utiliser plusieurs langues pour le développement de nouveaux codes.
La raison 5 , la résistance aux changements nécessaires dans les langues utilisées, peut être une cause de perturbation grave du projet et de conflits internes. Comme l'utilisateur Daveo l'a 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 provoquer de nombreux conflits. L'utilisation des compétences linguistiques héritées peut être un puissant stimulant pour la productivité d'un projet si la langue héritée est suffisamment puissante, et peut conduire à un produit d'excellente qualité dans une équipe qui fonctionne bien et respecte la qualité. Cependant, les compétences linguistiques héritées doivent être équilibrées avec le fait que de nombreuses langues plus anciennes ne peuvent plus rivaliser avec les langues plus récentes en termes de fonctionnalités avancées, de disponibilité des composants, d'options open source et de prise en charge de la boîte à outils intelligente.
À l'époque et maintenant, l'argument le plus commun (et ironiquement, le plus souvent correct) pour continuer à utiliser un langage hérité plus faible, moins lisible ou moins productif a été que l'ancien langage permet la production de code plus efficace. C'est un vieil argument, qui remonte aux années 1950 lorsque les utilisateurs du langage d'assemblage ressentaient, souvent amèrement, l'émergence de la programmation en FORTRAN et LISP. Un exemple où même maintenant l'argument de l'efficacité du code peut avoir une validité peut être vu dans le code à forte intensité de traitement tel qu'un noyau de systèmes d'exploitation, où C reste le langage de choix par rapport à C++ (bien que pour des raisons allant au-delà de la simple efficacité).
Cependant, dans les environnements de projet en réseau mondial et puissamment pris en charge par les machines du nouveau millénaire, l'efficacité du code comme principal argument pour choisir un langage de projet s'est encore affaiblie. La même explosion de matériel informatique et de mise en réseau qui a permis la commercialisation en masse d'applications d'intelligence artificielle signifie également que les coûts de la programmation humaine peuvent facilement éclipser ceux de l'exécution de code inefficace en termes de relativité sur du matériel et des cloudwares incroyablement bon marché. Lorsque cela est combiné avec une plus grande disponibilité pour dans les langues plus récentes des bibliothèques de composants, des options open source et des kits d'outils intelligents avancés, le nombre de cas où la conservation d'une langue pour des raisons d'efficacité seule devient très étroite. Même dans les cas où cela s'applique, l'accent devrait être mis sur l'utilisation de langages tels que le C qui continuent d'avoir un large soutien communautaire.
Une raison plus impérieuse pour un projet de rester avec les langues héritées se produit lorsque, pour quelque raison que ce soit, un projet a peu ou pas d'options pour changer son personnel. Cela peut se produire, par exemple, lorsqu'une importante gamme de produits hérités est entièrement codée dans une langue avec laquelle seul le personnel existant parle couramment. Dans de tels cas, le projet doit soit continuer sur la voie d'essayer de programmer dans l'ancienne langue, soit tenter de former le personnel existant à l'utilisation d'une nouvelle langue.
La formation du personnel linguistique hérité dans une nouvelle langue peut être un danger en soi. Je me souviens encore d'un cas où un membre d'un projet qui venait de se former et de passer du C au C++ s'est plaint sincèrement à moi qu'il ne comprenait tout simplement pas les avantages des méthodes orientées objet. Quand j'ai regardé son code, il avait converti ses précédentes fonctions 103 C en 103 méthodes pour une seule classe d'objets C++ ... et à juste titre ne voyait pas comment cela aidait quoi que ce soit.
Le message le plus profond est que lorsque les gens ont programmé dans une seule langue et un seul style de langue pendant des années ou des décennies, la difficulté à les amener à "penser" de nouvelles façons peut devenir presque insurmontable, même avec de bons programmes de formation. Dans certains cas, il ne peut y avoir d'autre option que de faire appel à des concepteurs et des programmeurs plus jeunes qui sont plus en phase avec les tendances et les méthodes actuelles.
Raison 6 , mauvaise gestion de projet, parle d'elle-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, la sélection de la langue peut faire une énorme différence dans le sort à long terme et les coûts de support d'un projet, et doit donc toujours être prise en compte et planifiée. Ne devenez pas un MUMPS!
Je n'arrive pas à comprendre la raison pour laquelle plusieurs langages de programmation sont utilisés dans le même produit ou logiciel?
C'est assez simple: il n'y a pas de langage de programmation unique adapté à tous les besoins et objectifs.
Lire le livre de Michael L. Scott Programming Language Pragmatics
Certains langages de programmation favorisent l'expressivité et déclarativité (beaucoup de langages de script, mais aussi des langages de programmation de haut niveau comme Agda , Prolog , LISP , Haskell, Ocaml, ...). Lorsque le coût de développement est important (temps humain et coût des développeurs), il convient de les utiliser (même si les performances d'exécution ne sont pas optimales).
D'autres langages de programmation favorisent les performances d'exécution (de nombreux langages de bas niveau, avec des implémentations généralement compilées, comme C++, Rust, Go, C, assembleur, également des langages spécialisés comme OpenCL ...); souvent leur spécification autorise certains comportement indéfini . Lorsque les performances du code sont importantes, il est préférable d'utiliser ces langages.
Certaines bibliothèques externes sont écrites dans et pour une langue particulière et ABI et conventions d'appel à l'esprit. Vous devrez peut-être utiliser cet autre langage et suivre les conventions interface de fonction étrangère , peut-être en écrivant quelques code de colle .
En pratique, il est peu probable d'avoir un langage de programmation très expressif (améliore donc la productivité du développeur, en supposant une équipe de développeurs suffisamment compétente) et très performant à l'exécution. En pratique, il y a un compromis entre expressivité et performance.
Remarque: cependant, il y a eu quelques progrès lent dans les langages de programmation: Rust = est plus expressif que C ou peut-être même C++ mais son implémentation est presque aussi performante, et s'améliorera probablement pour générer des exécutables tout aussi rapides. Vous devez donc apprendre de nouveaux langages de programmation au cours de votre vie professionnelle; cependant il y a Pas de Silver Bullet
Notez que le coût du développement est de plus en plus important aujourd'hui (ce n'était pas le cas dans les années 1970 -à cette époque les ordinateurs étaient très coûteux- ou dans certains applications embarquées -avec un grand volume de produit ). La règle générale (très approximative) est qu'un développeur qualifié est capable d'écrire environ 25 000 lignes de code source (débogué et documenté) chaque année, et cela ne dépend pas beaucoup du langage de programmation utilisé.
Une approche courante consiste à intégrer certains langage de script (ou certains langage spécifique au domaine ) dans une grande application. Cette idée de conception (liée au langage spécifique au domaine) est utilisée depuis des décennies (un bon exemple est le code source Emacséditeur , utilisant Elisp pour l'écriture de scripts depuis les années 1980). Ensuite, vous utiliserez un interpréteur facilement intégrable (comme Guile , Lua , Python , ...) dans une application plus grande. La décision d'intégrer un interprète dans une grande application doit être prise très tôt et a de fortes implications architecturales. Vous utiliserez ensuite deux langages: pour les trucs de bas niveau qui doivent s'exécuter rapidement, certains langages de bas niveau comme C ou C++; pour les scripts de haut niveau, l'autre langage DSL ou de script.
Notez également qu'un logiciel donné peut fonctionner, dans la plupart des --- systèmes d'exploitation (y compris Linux, Windows, Android, MacOSX, Hurd, ...), dans plusieurs coopérant processus utilisant une sorte de communication inter-processus techniques. Il peut même fonctionner sur plusieurs ordinateurs (ou plusieurs d'entre eux), en utilisant informatique distribuée techniques (par exemple cloud computing , HPC, serveur client, applications Web =, etc ...). Dans les deux cas, il est facile d'utiliser plusieurs langages de programmation (par exemple coder chaque programme exécuté sur un processus ou un ordinateur dans son propre langage de programmation). Lisez Systèmes d'exploitation: trois pièces faciles pour en savoir plus. Aussi, interfaces de fonctions étrangères (par exemple JNI ), ABI s, conventions d'appel , etc ... facilitent le mélange de plusieurs langues dans le même programme (ou exécutable ) - et vous trouverez des générateurs de code comme SWIG pour vous aider.
Dans certains cas, vous devez mélanger plusieurs langages de programmation: les applications Web ont besoin de Javascript ou de Webassembly (les seuls langages exécutés dans la plupart des navigateurs Web) pour la partie exécutée dans le navigateur (il existe des cadres generating ceux-ci, par exemple ocsigen ). Le code du noyau a besoin de certaines choses (par exemple le planificateur ou la gestion de bas niveau des interruptions) pour être partiellement écrites dans l'assembleur, car C ou C++ ne peut pas exprimer ce qui est nécessaire, les requêtes RDBMS doivent utiliser SQL, GPGPU s besoin noyaux informatiques codé en OpenCL ou CUDA géré par le code hôte C ou C++, etc .... Certains langages sont conçus pour faciliter un tel mélange (par exemple asm instructions en C, morceaux de code dans ma fin GCC MELT , etc ...).
Dans certains cas, vous utilisez des techniques métaprogrammation : certaines parties de votre grand projet logiciel auraient du code (par exemple en C ou C++) généré par d'autres outils (peut-être des outils spécifiques au projet) à partir d'une formalisation ad hoc: des générateurs d'analyseurs (appelés à tort compilateurs-compilateurs) comme bison ou ANTLR viennent à l'esprit, mais aussi SWIG ou RPCGEN. Et notez que GCC contient plus d'une douzaine de générateurs de code C++ spécialisés (un pour chaque DSL interne à l'intérieur de GCC). Voir aussi l'exemple this . Notez que metabugs sont difficiles à trouver. Lisez aussi à propos de compilateurs d'amorçage , et à propos de homoiconicité et réflexion (il vaut la peine d'apprendre LISP , jouez avec SBCL , et lisez SICP ; regardez aussi dans les bibliothèques compilation JIT comme GCCJIT ; dans certains grands programmes, vous pouvez générer du code lors de l'exécution en les utilisant; soyez conscient de dixième règle de Greenspun ). Regardez aussi le Circuit moins parcouru au FOSDEM2018.
Parfois, vous souhaitez fournir des annotations formelles de votre code (par exemple pour aider les prouveurs, les analyseurs statiques, les compilateurs), en utilisant un langage d'annotation spécialisé (qui peut être considéré comme du DSL). Regardez dans ACSL avec Frama-C pour annoter les programmes C (critiques pour la sécurité), ou OpenMP = pragmas pour HPC. Attention: la rédaction de telles annotations peut nécessiter beaucoup de compétences et de temps de développement.
BTW, cela suggère que certaines compétences sur les compilateurs et les interprètes sont utiles pour chaque développeur (même sans travailler à l'intérieur des compilateurs). Alors lisez Dragon Book même si vous ne travaillez pas sur les compilateurs. Si vous codez votre propre interprète (ou si vous concevez votre DSL), lisez aussi LISP en petits morceaux .
Voir aussi this & that & that & that mes réponses en rapport avec votre question.
Étudiez également le code source de plusieurs grands projets logiciels libres (sur github ou de votre distribution Linux ) pour l'inspiration et l'illumination.
De plus, certains langages de programmation ont évolué en ajoutant des annotations (sous forme de pragmas ou commentaires ) aux langages existants. Par exemple, pensez à ACSL (une extension de commentaire pour annoter les programmes C pour permettre leurs preuves par Frama-C ) ou à OpenCL (un dialecte C pour programmer les GPGPU) ou OpenMP ou OpenACC#pragmas ou annotations communes de type LISP .
PS: il y a aussi des raisons sociales ou organisationnelles ou historiques pour mélanger les langages de programmation; Je les ignore ici, mais je sais qu'en pratique, de telles raisons sont dominantes. Lisez aussi Le mois de l'homme mythique
De nombreux projets sont pas construits avec plusieurs langages de programmation. Cependant, il est courant d'utiliser des scripts dans d'autres langues pour aider avec le logiciel.
- Les outils d'administration qui sont des programmes distincts sont parfois écrits dans une langue différente.
- Les bibliothèques et les API proposent fréquemment des liaisons pour plusieurs langues, afin que les développeurs puissent utiliser la langue de leur choix.
- Les scripts de construction et les scripts de développement associés utilisent souvent des langages spécialisés.
- Les tests de bout en bout d'une application n'ont pas besoin d'utiliser le même langage.
Quelques projets utilisent plusieurs langues dans l'application, par exemple un noyau dans un langage de niveau inférieur qui peut intégrer des plugins dans un langage de script. Dans certains écosystèmes (par exemple JVM ou .NET), la langue exacte utilisée n'est pas trop importante car plusieurs langues sur le même langage d'exécution ont une bonne interopérabilité. Par exemple, je pourrais écrire un projet dans Scala qui utilise les bibliothèques Java Java existantes et intègre la fonctionnalité de script avec Groovy).
Si un projet se compose de plusieurs outils, ceux-ci peuvent également être développés dans différentes langues. Bien que la cohérence soit bonne, en particulier pour les projets open source, l'effort de développement disponible peut être un goulot d'étranglement. Si quelqu'un souhaite développer un outil utile mais ne connaît pas la langue principale, cet outil est peut-être plus précieux que la cohérence.
Cela a deux formes et beaucoup d'organisations se situent quelque part entre les deux:
La mauvaise forme - l'organisation est un gâchis, et personne ne s'assure qu'il n'y a qu'une seule vision technologique pour l'effort. Les développeurs utilisent probablement le langage dans lequel ils se sentent le plus à l'aise, ou ont récemment expérimenté un nouveau cadre ou langage et ont décidé de simplement commencer à l'utiliser en raison d'un optimisme naïf.
La bonne forme - l'organisation a une architecture vraiment bonne et propre qui se prête bien à la programmation polyglotte; découplage des applications en composants indépendants avec un contexte de délimitation bien défini, et cette combinaison leur permet de sélectionner le langage de programmation qui leur permet le plus simplement d'écrire ce composant particulier.
Réalité - c'est normalement plus l'ancien que le second. J'ai vu quelques entreprises choisir une langue pour leur domaine d'activité et une autre pour leur serveur Web, et souvent la troisième pour l'administration de leur base de données, ce qui est techniquement correct mais très vite leur manque de compréhension technique (ou refus d'écouter leur personnel) signifie qu'ils se retrouvent avec les trois flous ensemble dans un gros gâchis, et introduisent souvent encore plus de langues qui sont appropriées pour résoudre des parties particulières du gâchis.
Je peux vous donner un exemple d'un projet de programmation qui dure depuis 32 ans et qui semble avoir encore beaucoup de vie. C'est commercial plutôt que open-source.
Le noyau est écrit dans un langage spécifique au domaine, créé spécifiquement pour le projet. Cela s'est avéré extrêmement utile, notamment parce qu'il intègre la restauration dans l'architecture de base, mais il se compile en code C, que nous compilons ensuite avec le compilateur de la plateforme. Il a pris en charge une vingtaine de plates-formes au cours de cette période, sans compter les variations 32 vs 64 bits, et est actuellement livré sur six d'entre elles.
Il a un module complémentaire, écrit en C++, qui a été lancé lorsqu'un ancien chef du projet est devenu convaincu que C++/MFC/Windows/x86 allait déplacer toutes les autres architectures et plates-formes, il était donc nécessaire d'offrir du travail C++ à pouvoir embaucher du personnel. Les choses ne se sont pas déroulées comme il s'y attendait.
En plus du langage de domaine et de C++, les développeurs travaillent dans LISP, qui est utilisé pour écrire des cas de test, en utilisant un interpréteur intégré dans le faisceau de test. Nous avons envisagé de remplacer LISP par Java à un moment donné, mais il s'est avéré que nous ne l'avons pas fait.
Il a également un wrapper pour son API principale, écrit en C #. Cela a été fait lorsque les clients l'ont demandé, afin qu'ils puissent réécrire leurs applications en C #. Il est créé par un script Perl, qui lit les fichiers d'en-tête C pour l'API, plus un fichier de configuration significatif, et écrit le code C # pour l'encapsuleur. Faire tout ce traitement de texte en Perl était juste plus facile que le faire en C++.
Il possède ses propres systèmes de génération et en a besoin, car le langage de domaine n'est pas compatible avec les systèmes de génération basés sur la création. Celui pour les plates-formes de type UNIX est écrit en scripts Shell, Perl et certains petits programmes dans le langage du domaine. Celui pour les plates-formes Windows est écrit en langage batch, Perl, et les mêmes petits programmes dans la langue du domaine. L'ancien système de construction VMS a été écrit en DCL, mais il n'a pas été utilisé depuis plus d'une décennie.
Il y a une programmation YACC/Bison dans le compilateur pour le langage de domaine. Il existe du code de test pour les plates-formes Apple écrites en Objective-C++. Certains des sites Web internes de l'équipe (utilisés pour la gestion de projet, ne faisant pas partie des livrables) sont écrits en ASP, et d'autres en CGI- scripts en Perl.
Fondamentalement, cela a commencé comme un projet pour résoudre un problème difficile, il valait donc la peine de créer des outils spécialisés, qui semblent toujours plus adaptés à ce travail que tout autre élément disponible. L'équipe considère que la programmation est une compétence quelque peu indépendante de la langue utilisée, elle est donc prête à utiliser une nouvelle langue si cela facilite la tâche. Cependant, la mode ne figure pas en tête de leur liste de priorités, de sorte qu'ils ne fragmenteront pas une tâche en introduisant gratuitement un nouveau langage.
La fonction de ce code est la modélisation mathématique, utilisée sur les postes de travail et les serveurs (je peux parler un peu plus librement si je n'identifie pas le produit). Il s'agit actuellement d'environ 25 millions de LoC, avec une équipe totale d'une cinquantaine.
Dans certains cas, il existe un outil que vous devez utiliser (comme la boîte à outils de l'interface utilisateur d'un système d'exploitation) qui est le plus facilement accessible à partir d'une langue donnée. Par exemple, sur iOS et macOS, si vous souhaitez écrire des applications GUI en utilisant UIKit et AppKit, écrire en Swift ou Objective-C est le moyen le plus rapide et le plus simple de le faire. (Il peut y avoir des liaisons pour d'autres langues, mais ils peuvent être à l'origine de la dernière version du système d'exploitation sur laquelle vous construisez, donc peuvent ne pas offrir toutes les fonctionnalités.)
Si souvent, ce qui se passe, c'est lorsqu'une application est multiplateforme, la logique de base de l'application est écrite dans un langage accessible aux deux, et les éléments spécifiques à l'interface utilisateur/au système d'exploitation sont écrits dans la langue dans laquelle ils travaillent en natif.
Donc, si vous écrivez une application Windows et macOS, vous pouvez écrire la logique principale en C++ et utiliser C # pour l'interface utilisateur sous Windows et Swift pour l'interface utilisateur sous macOS. Cela vous fait gagner du temps car vous pas besoin d'écrire la logique de base deux fois et de traiter différents ensembles de bogues dans les deux applications, etc. Mais cela permet également une véritable interface utilisateur native qui ne répond pas au plus petit dénominateur commun entre les plates-formes, comme l'utilisation d'une interface utilisateur multiplateforme bibliothèque le ferait.
En plus du fait que certains langages de programmation peuvent être mieux adaptés à certaines tâches spécifiques, il y a la réalité pratique.
Dans la réalité pratique, il y a 2 points particulièrement importants à considérer:
- Les gens ont une expérience et des niveaux d'intérêt différents dans différents langages de programmation. - Permettre aux gens de travailler dans les langues qu'ils aiment et qu'ils maîtrisent peut, dans certaines circonstances, conduire à un meilleur résultat final que de les forcer à utiliser une langue commune.
- De grandes bases de code sont construites sur de longues périodes par différentes personnes. - Il n'y a aucun moyen d'obtenir le financement ou le nombre de bénévoles nécessaires pour réécrire un projet entier une fois que la langue qui lui convient le mieux sortira.
Et bien sûr, il existe souvent des parties spécifiques d'une application qui ont des besoins entièrement différents, tels que:
- Zones sensibles aux performances développées dans un langage compilé. Exemple de langage: C++
- Les domaines qui doivent être bon marché, faciles à modifier et potentiellement personnalisables, développés dans un langage de script. Exemple de langue: Lua.
- Disposition de l'interface graphique. Exemple de langage: HTML
- Installateur. Exemple de langue/outil: WiX.
- Construire. Exemple de langage/outil: trop nombreux pour être répertoriés, généralement plusieurs à la fois.
Et en plus de cela, il y a quelques outils utilisés par une base de code sophistiquée, dont beaucoup permettent la personnalisation et les plugins nécessaires avec encore un autre langage.
Cette question (et certaines des réponses) semblent supposer que les applications sont des blocs de code monolithiques - ce n'est pas nécessairement le cas.
Votre site Web typique comme Stack Exchange est en fait un tas de services différents fonctionnant tous indépendamment les uns des autres, avec une sorte de messagerie entre eux. Ces services peuvent être (et sont généralement) mis en œuvre dans différentes langues, chacune avec ses propres atouts.
Je travaille sur une toute petite partie d'une plateforme de banque en ligne, destinée aux petites banques communautaires et coopératives de crédit. Cette plate-forme comprend plusieurs composants - une interface Web, une couche de base de données, une couche de communication tierce, etc. Ce sont toutes des applications indépendantes fonctionnant sur différents serveurs avec différents systèmes d'exploitation. Vous avez Javascript en cours d'exécution côté client dans le navigateur, vous avez des pages de construction Perl côté serveur, vous avez plusieurs services écrits en C++ agissant comme une couche d'abstraction entre le code Perl et le processeur principal de la banque, un autre ensemble d'applications C++ qui acheminer les messages entre les différentes couches, une poignée d'applications C++ et de scripts Perl pour surveiller la santé de divers processus et signaler leur état à un moniteur interne, etc., etc., etc. Les systèmes tiers avec lesquels ma couche interagit sont généralement COBOL les applications s'exécutant sur des ordinateurs centraux quelque part.
Les applications monolithiques existent toujours, mais même elles peuvent tirer parti de différentes langues pour différentes raisons. Vous pouvez écrire 90% d'une application en Java, mais utilisez JNI pour exploiter C ou C++ pour des sections plus critiques pour les performances.
En plus des autres points déjà corrects:
D'après l'expérience, de nombreuses décisions linguistiques ou environnementales sont prises par "si vous avez un marteau, tout ressemble à un clou", ce qui signifie que les gens ont tendance à utiliser les outils qu'ils connaissent.
De plus, l'introduction d'un nouvel environnement ou même d'un langage est un investissement majeur dans les licences, les formations, peut-être le matériel, et s'accompagne de grandes pertes de temps productif - procurez-vous, installez, configurez, entraînez chaque prise semaines dans un plus grande entreprise, et vous vous retrouvez avec un tas de développeurs débutants.
Il n'y a pratiquement jamais le temps "d'investir" dans un environnement ou un langage plus moderne ou mieux adapté, alors ils s'en tiennent à ce qu'ils ont jusqu'à ce qu'il ne puisse plus fonctionner.
Plus précisément à votre question, si plusieurs personnes/équipes participent au développement d'une solution, chaque groupe a tendance à s'en tenir à ce qu'il connaît le mieux, de sorte que la solution globale contient potentiellement plusieurs langues et est développée dans plusieurs environnements.
Je voudrais souligner un exemple très spécifique du motif "différentes langues ont des forces différentes": FORTRAN.
Fortran a été initialement développé pour faciliter le travail d'analyse numérique des ingénieurs, et beaucoup d'efforts ont depuis été déployés pour que les compilateurs Fortran émettent du code numérique très efficace. D'un autre côté, depuis ces premiers jours, l'utilisation des ordinateurs a explosé dans mille directions, dont aucune n'implique une analyse numérique, et le développement de langages de programmation a largement emboîté le pas en ignorant le monde `` réel '' (pardonnez le jeu de mots).
SO: C'est aujourd'hui, et vous vous retrouvez à travailler pour une entreprise avec un produit assez tentaculaire, la plupart écrit en (disons) Java (je parle d'expérience personnelle ici)). Mais vous constatez que l'une des principales caractéristiques du produit va nécessiter une nouvelle forme d'analyse numérique, et tous les meilleurs codes pour cette analyse particulière sont déjà disponibles sur le net - à Fortran. Alors, que faites-vous ? Vous téléchargez l'un de ces codes Fortran, découvrez son interface [c'est-à-dire les arguments du sous-programme le plus haut], créez un wrapper JNI pour lui en C et empaquetez-le comme une classe Java Java. BAM! Vous venez de devoir développer en trois langues à la fois. [Surtout si vous trouvez que votre code Fortran utilise des blocs COMMUNS - c'est-à-dire un stockage statique - et doit être modifié pour la sécurité des threads]
Parce que la programmation n'est pas une tâche. Même la création d'un produit n'est pas une tâche. Il existe plusieurs types de tâches qui s'expriment mieux dans différentes langues.
Pour le rendre plus concret, supposons quelque chose de simple comme une application autonome (il y a plus de tâches à effectuer pour les applications distribuées).
Un produit doit être
- écrit
- ensemble (cela implique à la fois la compilation et la collecte de ressources telles que des images, des polices, etc. pour le déploiement)
- déployé
- configuré
- surveillé
Il est très peu probable qu'un langage qui soit bon pour écrire le temps d'exécution d'un produit soit aussi bon pour assembler un produit. Etc.
Cependant, même le processus d'écriture d'un produit peut ne pas être effectué de manière optimale dans 1 langue.
Disons qu'il y a beaucoup de données structurées qui sont traitées dans le produit. La structure des données est-elle connue au moment de la rédaction? Si c'est le cas, vous voudrez configurer une base de données au moment du déploiement. Cela se fait de manière optimale dans une langue qui peut générer la langue qui se compilera dans votre temps d'exécution.
Et si la structure des données pouvait changer de temps en temps? Vous avez besoin d'une manière structurée de transformer de nouvelles constructions de données en configuration de code et de base de données. Il vaut mieux le faire dans une autre langue.
Pouvez-vous tout faire dans la même langue? Sûr. Mais votre efficacité dépend de la rapidité avec laquelle vous pouvez terminer un projet et de sa résistance aux changements. Si une grande partie de votre travail peut être automatisée avec des outils déjà existants, alors ce que vous prenez 3 mois peut être fait par quelqu'un d'autre en 2 jours. Mais que quelqu'un utiliserait d'autres langues pour automatiser ce que vous feriez par répétition.
Le développement logiciel a progressé au point où vous pouvez utilisez différents langages de programmation dans le même projet, et vous pouvez le faire fonctionner.
Ensuite, il y a la question pourquoi vous utiliseriez plus d'une langue.
L'une des raisons est que les langues deviennent obsolètes et lentement remplacées par des nouvelles, et si vous êtes chanceux, cela peut se faire petit à petit. Votre projet aura donc un mélange d'ancien et de nouveau langage.
Une autre raison est la situation où la langue X est très utilisée sur la plate-forme A, la langue Y est très utilisée sur la plate-forme B, mais la langue Z est prise en charge sur les deux plates-formes. Le code commun est donc écrit en langage Z, qui est ensuite combiné avec X ou Y, selon la plate-forme.
Et les gens aiment utiliser du code écrit par d'autres (en d'autres termes, du code sur lequel ils n'ont pas eu à passer du temps pour l'écrire eux-mêmes). Ils se sentent libres d'utiliser du code écrit par d'autres dans n'importe quelle langue, puis d'ajouter du code dans la langue de leur choix.