Pourquoi plusieurs langages de programmation sont-ils utilisés dans le développement d'un produit ou d'un logiciel?


114

Je suis un étudiant récemment diplômé visant à commencer 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 commune à la majorité d'entre eux est l'utilisation de plusieurs langages de programmation (tels que Java + Python + Go ou Python + C ++ + Ruby). J'ai déjà examiné cette autre question, qui concerne la manière dont plusieurs langages de programmation sont conçus pour communiquer les uns avec les autres: comment faire interagir deux programmations différentes avec deux langages différents?

Je souhaite comprendre l’obligation qui incite les entreprises à utiliser plusieurs langages de programmation. Quelle exigence ou quel type d’exigence oblige l’architecte du logiciel ou le responsable du 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 pourquoi plusieurs langages de programmation sont utilisés dans le même produit ou logiciel.


14
En tant qu'étudiant diplômé en génie informatique, j'ajouterai que pour le code de recherche en particulier, il s'agit souvent de "quelle langue l'auteur (l'étudiant) connaissait-il le mieux quand il a commencé". Les projets de recherche, en particulier les projets ponctuels qui ne conduisent pas à des projets de recherche plus importants, ont tendance à privilégier les résultats plutôt que leur "exactitude" (selon mon expérience).
tonysdg

16
@tonysdg: Je dirais que la "correction" a tendance à être plus pertinente dans le monde universitaire, pas moins. Ce qui n'est généralement pas pertinent est la maintenabilité, l'expérience utilisateur et / ou la documentation. Le mélange des langues en particulier affecte la maintenabilité; il limite le nombre de mainteneurs qualifiés.
MSalters

2
@MSalters: La facilité d'entretien est le mot que je crois que je cherchais à l'époque --- je suis d'accord avec tout ce que vous avez écrit!
tonysdg

19
Différents outils pour différentes tâches. Vous remarquerez que les architectes et les ingénieurs du bâtiment utilisent différents outils pour construire une maison.
Paul D. Waite

17
Lorsque vous partez en vacances, de votre domicile à l'aéroport puis de l'aéroport étranger puis de l'hôtel à la plage, utilisez-vous le même mode de transport pour chaque étape du voyage?
Courses de légèreté en orbite

Réponses:


17

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:

  1. Avantages financiers de la réutilisation de code écrit dans d'autres langues;
  2. La nécessité d'inclure et d'adapter le code existant;
  3. Disponibilité de codeurs pour des langues spécifiques;
  4. Le besoin de langues spéciales pour les besoins particuliers;
  5. Préjugés linguistiques hérités; et
  6. 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!


Je suis d'accord avec tout. Bien que la réponse de Basile soit principalement axée sur les problèmes de performances et d’expressibilité, elle aide tout le monde à comprendre le point de vue de la direction derrière le choix de la programmation polyglotte.
Parth Patel

@ParthPatel Je pense que vous devriez accepter cette réponse, c'est la meilleure conclusion autonome ici.
gauche autour

2
+1: mais vous avez oublié l'ego. Beaucoup de gens refusent d'apprendre de nouvelles langues et s'en tiennent à ce qu'ils savent. Ce niveau de maturité différent avec des équipes multiples peut mener à de nombreuses technologies différentes sur un seul projet
Daveo

1
Reason 7 tente de rendre sexy le service informatique à des fins de recrutement. Sans blague, sur un projet .Net, nous avons fini par remplacer un seul terminal d'un service existant, pour utiliser un tout nouveau service dans Go, juste pour pouvoir ajouter le mot "polyglotte"!
Chris Lee

1
Il h! Je ne peux pas ne pas être en désaccord avec le fait que l'utilisation de plusieurs langues est une attraction pour les personnes qui craignent de se retrouver dans une impasse, un type de travail uniquement en COBOL. C’est la première fois que j’entends parler d’un langage ajouté uniquement et spécifiquement à cette fin, mais dans de nombreux environnements, le fait de disposer d’une plus grande variété d’outils et de langages est considéré comme une indication de leur utilisation des dernières technologies, et sont donc un lieu de travail plus progressif. Bel exemple, merci!
Terry Bollinger

158

Je n'arrive pas à comprendre pourquoi 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 la 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 (beaucoup de langages de bas niveau, avec des implémentations généralement compilées, comme C ++, Rust, Go, C, assembleur, ainsi que des langages spécialisés comme OpenCL ...); souvent, leurs spécifications permettent un comportement indéfini . Lorsque la performance du code est importante, il est préférable d’utiliser ces langages.

Certaines externes bibliothèques sont écrites dans et pour une langue particulière et ABI et les conventions d' appel à l' esprit. Vous devrez peut-être utiliser cet autre langage et respecter les conventions d' interface de fonction étrangère , peut-être en écrivant du code collant .

En pratique, il est peu probable que le langage de programmation soit très expressif (améliore donc la productivité du développeur, en supposant une équipe de développeurs suffisamment qualifiée) et très performant au moment de l'exécution. En pratique, il existe un compromis entre expressivité et performance.

Remarque: toutefois, les langages de programmation ont progressé lentement : Rust est plus expressif que le C ou peut-être même le C ++, mais son implémentation est presque aussi performante et devrait permettre de générer des exécutables aussi rapides. Vous devez donc apprendre de nouveaux langages de programmation au cours de votre vie professionnelle. mais il n'y a pas d'argent balle

Notez que le coût de 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 certaines applications embarquées - avec un grand volume de produit). La règle de base (très approximative) est qu'un développeur expérimenté 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 à incorporer un langage de script (ou un langage spécifique à un domaine ) dans une application volumineuse. Cette idée de conception (liées à la langue spécifique au domaine) a été utilisé pendant des décennies (un bon exemple est le Emacs code source éditeur , en utilisant Elisp pour les 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 application volumineuse doit être prise très tôt et a de fortes implications architecturales. Vous utiliserez ensuite deux langages: pour les tâches de bas niveau nécessitant une exécution rapide, un langage de bas niveau comme C ou C ++; pour les scripts de haut niveau, l’autre langage de script ou DSL.

Notez également qu'un logiciel donné peut fonctionner, dans la plupart des systèmes d'exploitation actuels (y compris Linux, Windows, Android, MacOSX, Hurd, ...), dans plusieurs processus en coopération utilisant certaines techniques de communication inter-processus . Il peut même fonctionner sur plusieurs ordinateurs (ou plusieurs), en utilisant des techniques informatiques distribuées (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 les systèmes d'exploitation: Trois pièces faciles pour plus. En outre, les interfaces de fonctions étrangères(par exemple, JNI ), les ABI , les 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 nécessitent Javascript ou 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 frameworks les générant , par exemple ocsigen ). Le code du noyau ont besoin des choses (par exemple , le planificateur ou le traitement à faible niveau d'interruptions) à partie en assembleur, parce que C ou C ++ ne peut pas exprimer ce qui est nécessaire là - bas, les requêtes SGBDR doivent utiliser SQL, GPGPU besoin de les noyaux informatiques codés 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, les asminstructions en C,morceaux de code dans mon GCC MELT , etc ...).

Dans certains cas, vous utilisez des techniques de métaprogrammation : certaines parties de votre grand projet logiciel auraient un code (par exemple en C ou C ++) généré par d’autres outils (des outils spécifiques au projet, par exemple) à partir d’une formalisation ad-hoc: des générateurs d’analyseurs (appelés à tort compilateur). des compilateurs) comme le bison ou ANTLR viennent à l’esprit, mais aussi SWIG ou RPCGEN. Et remarquez que GCC contient plus d’une douzaine de générateurs de code C ++ spécialisés (un pour chaque DSL interne de GCC). Voir aussi cet exemple. Notez que les métabogues sont difficiles à trouver. Lisez aussi sur le démarrage des compilateurs , l' homoiconicité et la réflexion(Cela vaut la peine d'apprendre Lisp , de jouer avec SBCL et de lire SICP ; regardez aussi dans les bibliothèques de compilation JIT telles que GCCJIT ; dans certains grands programmes, vous pourriez générer du code à l'exécution; utilisez la dixième règle de Greenspun ). Consultez également la discussion sur le circuit moins fréquentée à 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 un DSL). Examinez ACSL avec Frama-C pour annoter des programmes C (programmes critiques pour la sécurité) ou des pragmas OpenMP pour HPC. Mise en garde: écrire de telles annotations peut nécessiter beaucoup de compétences et de temps de développement.

En passant, 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 le Livre du Dragon même si vous ne travaillez pas sur des compilateurs. Si vous codez votre propre interprète (ou si vous concevez votre DSL), lisez également Lisp In Small Pieces .

Voir aussi ce et que et que et que les réponses de mes liées à votre question.

Etudiez également le code source de plusieurs grands projets de logiciels libres (sur github ou de votre distribution Linux ) pour vous inspirer et vous éclairer.

En outre, certains langages de programmation ont évolué en ajoutant des annotations (sous forme de pragmas ou de commentaires ) aux langages existants. Pour des exemples, pensez à ACSL (extension un commentaire pour annoter les programmes C pour permettre à leurs preuves par Frama-C ) ou de OpenCL (un dialecte C pour programmer GPGPU) ou OpenMP ou OpenACC #pragmas ou annotations communes de type Lisp .

PS: il existe également des raisons sociales, organisationnelles ou historiques de mélanger des langages de programmation; Je les ignore ici, mais je sais que dans la pratique, ces raisons sont dominantes. Lire aussi le mois de l'homme mythique


6
Pour moi, c'est la bonne réponse. Vous pouvez par exemple prendre des routines d’assemblage dans les programmes C. Le shell UNIX est jonché de plusieurs langages de programmation, et vous trouverez souvent awk(ce qui est un autre langage de programmation) utilisé dans les scripts bash, simplement parce que cela convient mieux à la tâche). Le point de @ amon est toujours valable.
MayeulC

8
BTW, un bon programmeur est parfois capable de supprimer des lignes de code ... (en remplaçant un grand nombre de lignes de code de merde par un tout petit nombre de bonnes lignes)
Basile Starynkevitch

12
Excellente réponse, mais une demande: j'apprécie le désir d'indiquer "apart" en les présentant moins clairement, mais n'abusez pas de la balise HTML SUP simplement parce qu'elle a pour effet secondaire de rendre le texte dans une police plus petite. C’est un cauchemar d’accessibilité, et comme le préconise le standard HTML5: "Ces éléments ne doivent être utilisés que pour baliser les conventions typographiques avec des significations spécifiques, et non pour la présentation typographique, mais pour des raisons de présentation. Utilisez ces éléments uniquement si l'absence de ces éléments changerait le sens du contenu ".
FeRD

4
@FeRD: supprimé <sup>mais avec regret
Basile Starynkevitch

6
@BasileStarynkevitch apprécié. Comme je l'ai dit, j'apprécie l'intention et, en tant qu'écrivain trop bavard et sujet aux tangences, je souhaite vraiment que StackExchange fournisse une méthode prise en charge permettant de styliser moins le texte, voire de le réduire au sein d'un conteneur clic-pour-révéler. Mais les exposants d'une longueur de paragraphe ne sont pas la solution à cette lacune.
FeRD

29

De nombreux projets ne sont pas construits avec plusieurs langages de programmation. Cependant, il est courant d'utiliser des scripts dans d'autres langues pour faciliter l'utilisation du 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 souvent 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 d'une application à l'autre ne sont pas obligés d'utiliser le même langage.

Quelques projets utilisent plusieurs langues au sein de l'application, par exemple un noyau dans un langage de niveau inférieur pouvant intégrer des plug-ins dans un langage de script. Dans certains écosystèmes (JVM ou .NET, par exemple), le langage exact utilisé n’est pas très important, car plusieurs langages exécutés sur le même langage sont parfaitement interopérables. Par exemple, je pourrais écrire un projet dans Scala qui utilise les bibliothèques Java existantes et intègre la fonctionnalité de script avec Groovy.

Si un projet comprend plusieurs outils, ceux-ci peuvent également être développés dans différentes langues. Si la cohérence serait bonne, en particulier pour les projets open source, l’effort de développement disponible peut constituer un goulot d’étranglement. Si quelqu'un est prêt à 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.


3
Ceci est complémentaire à la réponse de @ Basile. Les scripts Perl du noyau Linux ne font pas partie du noyau, pas plus que le Makefile. Il n'y a rien à gagner à utiliser C pour ceux-ci. De plus, ces scripts Perl peuvent être utilisés indépendamment du noyau Linux. Très souvent, ceux-ci peuvent être considérés comme un projet étroitement lié, mais distinct . Vous utiliserez généralement une seule langue pour une tâche unique.
MayeulC

20

Cela a deux formes, et beaucoup d'organisations qui se situent quelque part entre les deux:

La mauvaise forme - l'organisation est un gâchis, et personne ne s'assure qu'il existe une vision technologique unique pour l'effort. Les développeurs utilisent très probablement la langue dans laquelle ils sont le plus à l'aise, ou ont récemment expérimenté un nouveau langage ou une nouvelle structure et ont décidé de commencer simplement à 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écoupler des applications en composants indépendants avec un contexte de délimitation bien défini. Cette combinaison leur permet de sélectionner le langage de programmation qui leur permet le plus simplement d'écrire ce composant particulier.

La réalité - c'est normalement plus le premier que le dernier. 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 leurs bases de données, ce qui est techniquement satisfaisant, mais très vite, leur manque de compréhension technique (ou leur refus d'écouter leurs employés) signifie qu'ils se retrouvent avec les trois flous ensemble dans un grand désordre, et introduisent souvent encore plus de langues qui sont appropriées pour résoudre des parties particulières du désordre.


20

Je peux donner un exemple de projet de programmation en cours depuis 32 ans et qui semble avoir encore beaucoup de vie. C'est commercial plutôt qu'open source.

Le noyau est écrit dans un langage spécifique au domaine, créé spécifiquement pour le projet. Cela s'est révélé extrêmement utile, notamment parce qu'il intègre l'annulation dans l'architecture de base, mais qu'il est compilé dans le code C, que nous compilons ensuite avec le compilateur de la plate-forme. Il a pris en charge une vingtaine de plates-formes au cours de cette période, sans compter les variantes 32 bits / 64 bits, et est actuellement livré avec six d'entre elles.

Il possède un module complémentaire, écrit en C ++, qui a été lancé lorsqu'un ancien responsable du projet est devenu convaincu que C ++ / MFC / Windows / x86 allait remplacer toutes les autres architectures et plates-formes. Il était donc nécessaire d'offrir du travail en C ++. pouvoir engager du personnel. Les choses ne se sont pas passées comme il s'y attendait.

En plus du langage de domaine et du langage C ++, les développeurs travaillent dans LISP, qui permet d'écrire des scénarios de test, à l'aide d'un interpréteur intégré au faisceau de tests. Nous avons envisagé de remplacer LISP par Java à un moment donné, mais nous avons eu la chance de ne pas le faire.

Il possède également un wrapper pour sa principale API, écrite 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 de l'API, ainsi qu'un fichier de configuration important, et écrit le code C # du wrapper. Faire tout ce traitement de texte en Perl était tout simplement plus facile que de le faire en C ++.

Il a ses propres systèmes de construction, et en a besoin, car le langage de domaine ne se prête pas aux systèmes de construction basés sur la création. Celui destiné aux plates-formes de type UNIX est écrit dans des scripts shell, Perl et quelques petits programmes dans la langue du domaine. Celui pour les plates-formes Windows est écrit en langage de traitement par lots, Perl, et les mêmes petits programmes dans la langue du domaine. L'ancien système de compilation VMS était écrit en DCL, mais il n'a pas été utilisé depuis plus de dix ans.

Il y a des programmes YACC / Bison dans le compilateur pour le langage de domaine. Il existe un code de test pour les plates-formes Apple écrit en Objective-C ++. Certains des sites Web internes de l'équipe (utilisés pour la gestion de projet, ne faisant pas partie des produits livrables) sont écrits en ASP, et d'autres en tant que scripts CGI en Perl.

Fondamentalement, il s’agissait d’un projet visant à résoudre un problème difficile; il était donc intéressant 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 du langage utilisé. Elle est donc prête à utiliser un nouveau langage si cela facilite la tâche. Cependant, la mode ne figure pas en tête de leurs priorités, ils ne fragmenteront donc pas une tâche en introduisant un nouveau langage gratuitement.

La fonction de ce code est la modélisation mathématique, utilisée sur les stations de travail et les serveurs (je peux parler un peu plus librement si je n'identifie pas le produit). Cela représente actuellement environ 25 millions de LdC, soit une cinquantaine d’équipes.


Il serait bien d’en dire un peu plus sur ce logiciel: quel domaine industriel (les robots de neurochirurgie ne sont pas identiques au trading haute fréquence, par exemple)? Quelle taille approximative (en millions de lignes de code)? Quelle taille d'équipe?
Basile Starynkevitch

@BasileStarynkevitch: ajout de détails.
John Dallman

Cette. C’est précisément pour cette raison que les projets utilisent plusieurs langues, du plus bon au plus méchant.
Jared Smith

15

Dans certains cas, vous devez utiliser un outil (tel que 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 voulez écrire des applications graphiques à l'aide de UIKit et AppKit, écrire dans 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 elles peuvent se trouver derrière la dernière version du système d'exploitation que vous construisez, alors n'offrent peut-être pas toutes les fonctionnalités.)

Il arrive souvent que lorsqu'une application est multiplate-forme, sa logique principale 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 mode natif.

Ainsi, 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 n'avez pas besoin d'écrire deux fois la logique principale 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 correspond pas au plus petit dénominateur commun existant une bibliothèque d'interface utilisateur multi-plateforme serait.


MVC FTW! Même s’attaquer à un seul noyau multiplateforme avec des applications d’emballage pour chaque système d’exploitation / environnement ... ou dans le monde moderne de la connectivité, le transférer à une architecture client / serveur
ivanivan

1
Cela correspond à ma propre expérience. Tous les projets de grande taille sur lesquels j'ai travaillé ont utilisé plusieurs langues, et jamais la multiplicité des langues n’a apporté d’avantage. La raison en était toujours que des parties particulières devaient être écrites dans des langages particuliers afin de s’interfacer avec des outils particuliers.
Owen

En tant qu'ancien développeur iOS, je peux confirmer que nous l'avons fait. Nous avions une API écrite en PHP qui communiquait en JSON, une interface Web écrite en PHP comportant également une partie JavaScript / HTML5, une interface Android composée en Java et une interface iOS en Objective-C. . Plus tard, de nouveaux projets ont été écrits dans Swift, mais notre cadre interne était toujours écrit en Objective-C. Donc, à un moment donné, une de nos applications a été écrite en PHP, Java, Objective-C, Swift, JavaScript et HTML5 et disponible sur 3 plates-formes.
Belle-Sophie

10

Outre le fait que certains langages de programmation peuvent être mieux adaptés à certaines tâches spécifiques, il existe une réalité pratique.

Dans la réalité pratique, il y a 2 points particulièrement importants à considérer:

  1. Les gens ont des expériences et des niveaux d’intérêt différents selon les langages de programmation. - Le fait de permettre aux personnes de travailler dans des langues qui leur plaisent et dans lesquelles elles maîtrisent peut, dans certaines circonstances, produire un meilleur résultat final que de les forcer à utiliser une langue commune.
  2. Les grandes bases de code sont construites sur de longues périodes par différentes personnes. - Il n’existe aucun moyen d’obtenir le financement ou le nombre de volontaires nécessaires pour réécrire un projet complet dès lors qu’une langue plus adaptée à la langue est proposée.

Et bien sûr, il existe souvent des parties spécifiques d'une application qui ont des besoins totalement différents, tels que:

  • Zones sensibles à la performance développées dans un langage compilé. Exemple de langage: C ++
  • Zones qui doivent être peu coûteuses, faciles à modifier et potentiellement personnalisables, développées dans un langage de script. Exemple de langue: Lua.
  • Disposition de l'interface graphique. Exemple de langage: HTML
  • Installateur. Exemple de langage / outil: WiX.
  • Construire. Exemple de langage / outil: Trop nombreux pour être énumérés, généralement plusieurs à la fois.

Et en plus de cela, il existe de nombreux outils utilisés par une base de code sophistiquée, dont beaucoup permettent la personnalisation nécessaire et des plugins dans une autre langue.


8
HTML n'est pas un langage de programmation
Bergi

1
@ Bergi Correct. Peter ne prétend pas que c'est le cas. C'est un langage de balisage.
Belle-Sophie

1
HTML, XAML, QML, etc. sont des langages utilisés par les programmeurs dans les projets logiciels pour indiquer à l'ordinateur ce qu'il doit faire. Les langages ne sont généralement pas strictement nécessaires car les programmeurs pourraient théoriquement écrire le projet entier, interface utilisateur comprise, dans un seul langage. C'est ce qui le rend pertinent dans le contexte de cette question.
Peter

5

En plus des remarques correctes déjà faites:
Par expérience, de nombreuses décisions en matière de langage ou d’environnement sont prises par "si vous avez un marteau, tout ressemble à un clou", ce qui signifie que les utilisateurs ont tendance à utiliser les outils qui leur sont familiers.

De plus, l' introduction d' un nouvel environnement ou même la langue est un important investir dans des licences, des formations, peut - être matériel, et est livré avec de grandes pertes de temps productif - Procure, installer, configurer, train chaque prise semaines dans une entreprise plus grande, et vous finissez essentiellement avec un groupe de développeurs débutants.
Il n’ya pratiquement jamais le temps d’investir dans un environnement ou un langage plus moderne ou plus adapté, de sorte qu’ils conservent ce qu’ils ont jusqu’à ce qu’il ne puisse plus fonctionner.

Pour répondre à votre question, si plusieurs personnes / équipes participent au développement d'une solution, chaque groupe a tendance à s'en tenir à ce qu'il sait le mieux, de sorte que la solution globale comporte potentiellement plusieurs langues et se développe dans plusieurs environnements.


5

Cette question (et certaines des réponses) semblent supposer que les applications sont des blocs monolithiques de code - ce n'est pas nécessairement le cas.

Votre site Web typique, comme Stack Exchange, est en réalité un ensemble de services différents fonctionnant 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 plateforme bancaire en ligne destinée aux petites banques et aux coopératives de crédit. Cette plate-forme comporte plusieurs composants: une interface Web, une couche de base de données, une couche de communication tierce, etc. Ces applications sont toutes indépendantes et s'exécutent sur différents serveurs dotés de systèmes d'exploitation différents. Javascript est exécuté côté client dans le navigateur, les pages de construction Perl côté serveur, plusieurs services écrits en C ++ agissant en tant que couche d'abstraction entre le code Perl et le processeur central de la banque, un autre ensemble d'applications C ++ route des messages entre les différentes couches, quelques applications C ++ et des scripts Perl pour surveiller l’état de santé de divers processus et signaler leur état à un moniteur interne, etc., etc., etc.

Les applications monolithiques existent toujours, mais elles peuvent même tirer parti de différentes langues pour différentes raisons. Vous pouvez écrire 90% d'une application en Java, mais utilisez JNI pour tirer parti de C ou C ++ pour des sections plus critiques en termes de performances.


Je suis surpris que personne n'ait mentionné SQL (ou le langage de requête de votre choix), la plupart des applications ont aujourd'hui au moins une sorte d'architecture "stack".
user3067860

3

J'aimerais souligner un cas très spécifique du motif "les langues différentes ont des atouts différents": le fortran.

Fortran a été développé à l'origine pour aider les ingénieurs à effectuer des analyses numériques. Depuis, beaucoup d'efforts ont été consentis pour que les compilateurs Fortran émettent du code numérique très efficace. D'autre part, depuis ces débuts, l'utilisation des ordinateurs a explosé dans un millier de 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".

SO: C’est aujourd’hui, et vous vous retrouvez à travailler pour une entreprise dont le produit est plutôt tentaculaire, la plupart d’entre eux écrits en (disons) Java (je parle par expérience personnelle ici) . Mais vous constatez que l’une des caractéristiques principales du produit va nécessiter une analyse numérique, et que tous les meilleurs codes pour cette analyse particulière sont déjà disponibles sur le réseau - Fortran. Donc que fais-tu? Vous téléchargez l'un de ces codes Fortran, déterminez son interface (c'est-à-dire les arguments du sous-programme le plus haut), créez un wrapper JNI pour lui en C et créez un package en tant que classe Java. BAM! Vous venez de développer en trois langues à la fois. [surtout si vous trouvez que votre code Fortran utilise des blocs COMMON - c'est-à-dire un stockage statique - et doit être modifié pour la sécurité des threads]


4
Ou bien votre noyau de calcul FORTRAN bien testé serait amélioré en appelant à un moment donné un nouvel algorithme qui dépend du tri des tas sur les pointeurs, que vous avez déjà écrit en C. Et vous avez des fichiers d'entrée complexes à analyser. scanner en flex. Oh, et peut-être aimeriez-vous une interface graphique que vous devez appeler à partir de C ++. Ou le client voudrait vraiment appeler le tout comme un sous-programme Matlab ...
jamesqf

3

Parce que la programmation n'est pas une tâche. Même créer un produit n'est pas une tâche. Il existe plusieurs types de tâches qui s’expriment le mieux avec 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
  • assembler (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é

Un langage qui peut être bon pour écrire le temps d'exécution d'un produit a très peu de chances d'être aussi bon pour assembler un produit. Etc.

Cependant, même le processus d'écriture d'un produit peut ne pas être réalisé de manière optimale dans une langue.

Disons que le produit contient beaucoup de données structurées. La structure des données est-elle connue au moment de l'écriture? Si c'est le cas, vous souhaiterez configurer une base de données au moment du déploiement. Ceci est fait de manière optimale dans un langage qui peut générer le langage qui sera compilé dans votre temps d'exécution.

Maintenant que se passe-t-il si la structure des données peut changer de temps en temps? Il vous faut alors un moyen structuré de transformer de nouvelles constructions de données en configuration de code et de base de données. Ceci est mieux fait dans encore 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, ce que vous prenez 3 mois peut être effectué par quelqu'un d'autre en 2 jours. Mais cette personne utiliserait d'autres langages pour automatiser ce que vous feriez par répétition.


«Un langage qui peut être bon pour écrire le temps d'exécution d'un produit a très peu de chances d'être aussi bon» ... Les langages de programmation ne sortent pas d'un processus aléatoire, c'est donc un peu bizarre de parler de probabilité de cette façon. Les langages de programmation sont conçus pour résoudre certaines tâches. Vous dites maintenant qu’il est peu probable qu’une langue résolue également, par accident , un autre problème qu’elle n’a pas été conçue pour résoudre. Je dirais cependant que l’essence de la programmation est d’abréger tous les problèmes que l’on pourrait souhaiter résoudre, et qu’un langage vraiment bien conçu devrait donc être tout aussi bon pour toute tâche.
gauche autour

@leftaroundabout c'est une erreur commune de confondre ce qu'une langue peut faire et ce qu'elle exprime bien. Le but d'un langage de haut niveau n'est pas de résoudre un problème. Il s’agit d’une syntaxe permettant d’exprimer une solution à un problème de manière à ce que certains outils puissent transformer cette expression en tâche exécutée par un ordinateur. Cela étant dit, il est important de rappeler que le travail d’expression est effectué par des personnes. Et les gens utilisent différentes abstractions pour décrire les solutions aux problèmes de différents domaines.
Grovkin

Bien sûr, les gens utilisent différentes abstractions. Ce que je veux dire, c'est qu'un bon langage devrait pouvoir exprimer toutes ces abstractions.
gauche autour

@leftaroundabout, pas du tout. Pour bien exprimer, il faut être capable de diriger son attention sur la chose. Vouloir bien exprimer tous les types d’abstractions signifierait attirer l’attention sur chacun d’eux. Et cela disperserait l'attention et ferait que les idées soient mal exprimées. Il n'y a rien de mal à choisir sur quoi insister et à se concentrer sur cela.
Grovkin

Être capable de faire réellement comme diriger l' attention est quelque part pas la même chose il.
gauche autour

1

Le développement logiciel a progressé au point que vous pouvez utiliser différents langages de programmation dans le même projet et que vous pouvez le faire fonctionner.

Il y a ensuite la question de savoir pourquoi vous utiliseriez plus d'une langue.

Une des raisons est que les langues deviennent obsolètes et lentement remplacées par de nouvelles, et si vous avez de la chance, cela peut se faire petit à petit. Votre projet combinera donc ancien et nouveau langage.

Une autre raison est la situation dans laquelle le langage X est essentiellement ce qui est utilisé sur la plate-forme A, le langage Y est très similaire à celui utilisé sur la plate-forme B, mais le langage Z est pris en charge sur les deux plates-formes. Le code courant est donc écrit en langage Z, qui est ensuite combiné avec X ou Y, en fonction de la plate-forme.

Et les gens aiment utiliser du code écrit par d'autres personnes (autrement dit, un code sur lequel ils n'ont pas passé beaucoup de temps à l'écrire eux-mêmes). Ils se sentent libres d'utiliser du code écrit par d'autres personnes dans n'importe quelle langue, puis d'ajouter du code dans la langue de leur choix.


8
À propos de la première phrase: les programmes bilingues sont une chose depuis plus de 50 ans.
Blrfl
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.