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.
Réponses:
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:
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!
la source
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
la source
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.<sup>mais avec regretDe 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.
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.
la source
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.
la source
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.
la source
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.
la source
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:
Et bien sûr, il existe souvent des parties spécifiques d'une application qui ont des besoins totalement différents, tels que:
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.
la source
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.
la source
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.
la source
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]
la source
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
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.
la source
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.
la source