Même il y a 2 décennies, il était possible d'appeler le code écrit dans une langue pour appeler le code écrit dans un autre; À l'école, nous avons appelé les routines graphiques assemblées de l'ADA Code pour une mission de classe. Les exceptions notables sont en cours d'exécution du code compilé à partir de scripts ou d'exécution d'une commande système à partir du code compilé; Mais nous écrivons rarement une bibliothèque en C ++ à utiliser dans notre application Java. Lorsque Java est apparu pour la première fois et il était encore lent, il y avait la possibilité d'écrire l'application principale en Java et de déplacer le code de goulot d'étranglement dans une DLL C / C ++ à appeler à l'aide de JNI.
Donc, après toutes ces années, ce qui nous empêche d'écrire des applications multi-langues? Le scénario principal que j'ai à l'esprit est quand une langue est considérée comme un bon choix s'il n'était pas pour un goulot d'étranglement de la performance (comme dans les journées de Java antérique) afin qu'il soit entièrement écrit en C au lieu d'utiliser un mélange des deux langues.
Je suis intéressé par cela d'une perspective d'architecture ainsi que de la conception de la langue. Avez-vous de bons exemples, histoires de réussite ou citations?
[modifier] L'un des meilleurs exemples de ceci était la barlum contre Java en raison de ses performances lentes tôt. Même si les compilateurs JIT ont abordé la question, ma question était toujours de la rédaction de logiciels dans une langue qui facilite l'écriture, la lecture et la maintenance. S'il y a un goulot d'étranglement, écrivez une routine en montage ou c juste pour le goulot d'étranglement. De cette façon, vous devriez obtenir le meilleur des deux mondes, du moins théoriquement.
24 Réponses :
"Alors, après toutes ces années, ce qui nous empêche d'écrire des applications multilingues?"
On pourrait percevoir qu'il y a trop de Gotchas avec un code d'appel dans la langue A du code dans la langue B. Alignement des octets, de l'endansion, de l'ordre des paramètres, etc. couvrant tous les gotchas afin que vous puissiez dormir la nuit prend du temps .
.NET tente de les résoudre, mais je ne sais pas dans quelle mesure. C'est une autre discussion.
Utiliser plusieurs langues implique:
Oui, cela peut parfois en valoir la peine - mais je ne le ferais pas avant d'avoir eu une très bonne raison.
.NET et Java les deux rendent beaucoup plus facile, bien sûr - en utilisant différentes langues sur une plate-forme est beaucoup plus facile que d'interopérer entre (dire) du code géré et natif.
Excellente réponse. Je suis connu pour utiliser le code DSLS / généré pour "grandes petites" tâches, mais d'une perspective d'équipe utilisant une seule langue présente de nombreux avantages. La question que vous devez poser est "est la deuxième langue tant mieux à résoudre ce problème que le premier que nous sommes disposés à faire face aux problèmes ci-dessus pour toute la durée du projet juste pour l'utiliser . "
Et beaucoup de personnes gaspillées de temps / de code monchalant les données de chaque sous-système, si vous n'utilisez pas simplement des chaînes simples.
Qu'est-ce qui vous fait penser que cela ne se produit pas?
Mes applications ASP.NET MVC ont certains C #, certains vb.net et certains JavaScript. Je pouvais assez facilement jeter dans certains python et f #, mais je n'ai pas trouvé le besoin d'y aller aussi loin.
J'ai aussi un projet qui utilise VB.NET/JAVScript pour le côté Web et C # pour les services et les bibliothèques de l'application.
Je ne dis pas que ça ne se passe pas, je demande pourquoi cela n'arrive pas plus .
Définir «plus». Quel pourcentage d'applications sont écrites aujourd'hui dans une langue? deux? Trois? Dix?
@kevindtimm, cela ressemble au noyau d'une excellente réponse. Veuillez élaborer une réponse postée.
La question dit "plus". L'implication est que, bien que les gens utilisent certainement plusieurs langues dans une application (l'enfer ... à peu près toutes les applications Web utilisent JavaScript, de GPL comme Java, et SQL), il y a beaucoup plus de place pour qu'il soit fait à bon affecter.
La façon dont je le vois, il y avait deux raisons principales pour inclure le support multiple-langage dans un interprète / compilateur:
Le premier est rarement vu aujourd'hui, principalement en raison de l'utilisation de bibliothèques partagées (telles que des DLL) et d'une abstraction accrue (la couche d'abstraction entre votre code et l'ensemble en dessous est assez épaisse), tandis que le second est surtout un La chose marketing et le marketing ne sont généralement pas l'intérêt principal du gars qui écrit la spécification de la langue (.Net étant la première exception à venir à l'esprit).
Les gens écrivent des applications multi-langues tout le temps. Vous mentionnez le code compilé appelé des langues de script. Cela arrive vraiment souvent, par exemple C ++ de Python, Perl, Lua ou R. ou Java de Groovy. Je ne sais pas à quelle fréquence C ++ est appelé de Java, mais je suis sûr que cela se produit aussi.
C'est pourquoi Swig est si populaire.
Vous parlez de deux langues très différentes ici, avec C ++ comme langue haute performance et Perl ou Lua ou Python ou quoi que ce soit comme langue de développement rapide. Cependant, C ++ et Java sont des langues similaires, je ne vois donc pas la synergie là-bas.
JNI (interface natif Java) est utilisée pour interfacer C ++ et Java
Je sais plus ou moins comment interfacer C ++ et Java, je me demande pourquoi, sauf pour utiliser le code déjà écrit. (Quelque chose comme comment, dans l'école de grades, j'ai compilé le code fortrain dans C avec F2C, je pourrais donc l'interfacer avec Lisp. J'avais besoin d'un système de programmation linéaire de haute qualité pour mon application LISP, après tout.) C ++ et Python ne font pas le même genre de choses, mais c ++ et java font.
Un aspect légèrement différent:
Dans les années 1980, peu de langues sont capables d'une gamme complète de fonctionnalités. Une application commerciale peut être écrite dans COBOL mais si elle nécessitait des routines numériques complexes, elles peuvent être écrites en Fortran avec assembleur sur mesure utilisé pour gérer les appels de fonctions de COBOL en Fortran. De nos jours, il existe une variété de choix pour les langues et les bibliothèques associées qui peuvent fournir toute la fonctionnalité dans une langue.
Les limitations sévères sur la capacité informatique (CPU, mémoire, disque, vitesses d'E / S) ont également entraîné une nécessité d'utiliser différentes langues pour différentes parties d'un programme ou d'un système.
Je pense que vous parlez trop tard une période. Les applications COBOL sont autour depuis les années 1960 et Cobol est une langue limitée. Dans les années 1980, nous avions de base et pascal sur les plus petits ordinateurs, ainsi que pour Fortran et C approvisionné (il était initialement normalisé en 1989). Même dans les années 1960, Fortran et Algol étaient disponibles pour une programmation à usage général.
Je conviens que cela peut aussi avoir été le cas plus tôt. J'ai mentionné les années 80 comme je connais un système à partir de ce moment-là que je décris. Je ne voulais pas dire que la question était exclusive à cette période, juste citant de l'expérience plutôt que de rechercher d'autres exemples d'autres périodes.
Dans mes projets d'origine, je appelle les procédures de fortrange des procédures C ou C de C ++.
Dans mon code de travail, nous mélangons Java avec un peu de c.
Cela se produit toujours, mais les gens essaient de l'éviter, de bonnes raisons.
Pourriez-vous élaborer ces raisons?
Nom Mangling, incompatibilité binaire, difficulté à déboguer. JNI, par exemple, est réputé être un pita.
Unix a déjà résolu ce problème après une mode. Le style unix d'écriture de petits utilitaires pouvant être enfilés pour former une solution est une forme d'une application dans plusieurs langues. Au lieu de définir l'interface et / ou le mécanisme d'interaction entre les langues, par ex. JNI, la ligne de commande ou l'environnement Shell est devenue la norme DEFACTO.
Je me demande si une exposition à UNIX ou de son absence est ce qui a rendu ce sujet ne valant pas la peine d'effort ou de complexe folle respectivement. C'est-à-dire que ceux avec une expérience Unix ne se dérangent pas avec JNI car ils s'approchent au problème de la conception différemment afin que leur application soit plus modulaire et plus cohérente; plus propice à la transformation en un composant dans une chaîne d'applications au lieu d'une monstruosité monolithique singulière.
Le plus gros problème que je vois est parce qu'il exige que tout le monde dans l'équipe soit très diversifié (voir la réponse de Jon Skeet). Si vous avez une équipe de dix personnes et trois connaissez-vous très bien et certains vb.net, trois connaissez-vous très bien et très peu C #, et les quatre autres connaissent très bien C ++, mais ne sont que d'accord sur C # ou VB. Net, pouvez-vous imaginer quel type de programme ils écriraient d'être multilingues? Cela peut aller bien, mais si vous perdez si vous perdez quelques membres de l'équipe, le temps est de l'essence et dites que c'était vos gars C ++, maintenant qui va résoudre ce code? Sûrement pas les gars .NET qui ne sont pas diversifiés en C ++. Cela peut causer beaucoup de problèmes.
La deuxième raison pour laquelle je vois pourquoi les applications sont principalement une seule langue d'aujourd'hui, c'est parce que lorsque vous atteignez un nombre élevé de lignes de code, il est très agréable de pouvoir suivre le même flux, les mêmes modèles et voir le même type de code dans tout le système. Votre cerveau n'a pas à basculer entre les langues pour personnaliser quelque chose, car vous «pensez C #», par exemple.
J'ai un ami qui écrit ses interfaces utilisateur dans vb.net et son code de backend qu'il stocke toujours dans la DLL en C #. C'est bon, vb.net et c # Travailler très bien ensemble, mais disent qu'il avait besoin de l'exter à la fois à quelqu'un pour corriger un segment de code où un bogue était à la fois dans le VB.NET et le code C #, bien, il a fait besoin de Externaliser deux développeurs, une couramment VB.NET, et l'autre en C #. Cela augmente coûte deux fois, ainsi que des frais généraux quand il aurait pu juste le faire dans un.
I Cependant, cela convient parfaitement sur les applications pouvant utiliser C ++ pour les sections critiques de performance. Il y a des moments où vous ne pouvez pas être un bon choix pour un segment de code critique de performance. Ce type de mélange de code est absolument correct.
à long terme, le mélange de code n'est pas une mauvaise chose. Cela peut être bon car cela vous aidera en tant que développeur devenant plus diversifié, changez votre façon de penser et de vous aider en tant que développeur. Mais vous devez être préparé pour plus de frais généraux, éventuellement des coûts, et peut-être même une frustration en cours de route.
Peut-être une bonne idée pour vous (si vous recherchez ce type de réponse) serait de choisir la langue par technologie. J'écris personnellement toutes mes applications Web (ASP.NET, etc.) dans vb.net. Il est rapide d'écrire, il est facile à lire et à entretenir. Et pour le Web, c'est exactement ce que vous voulez. Toutes mes applications de bureau soient toutefois poussées dans C #, car c'est une langue plus forte dans certains aspects et offre quelques éléments vb.net ne le fait pas. Vraiment, voici toutes les préférences personnelles, mais vous obtenez l'idée.
Même en tant que programmeur débutant, je me suis retrouvé avoir besoin d'utiliser un sourire de langage d'assemblage en Code C pour accélérer des trucs. (C'était pour suivre une ligne avec un flux de caméra à l'aide d'une carte de processeur assez lente pour une classe)
Je suggérerais que si quelqu'un écrit un morceau dans une certaine langue, qu'ils ne sont probablement plus à l'aise avec ladite langue. Il faudrait des raisons extrêmement convaincantes d'utiliser une langue qu'ils sont potentiellement moins à l'aise.
Dans ma compréhension, de nombreux développeurs de jeux utiliseront l'assemblage pour les bibliothèques de mathématiques critiques.
Je ne suis pas sûr de la raison, mais j'imagine que c'est beaucoup à voir avec la mentalité "Langue-Du-Jour", nous avons commencé à avoir à la fin des années 90. Je suis sur le point de m'embarquer sur un projet de foudre que je souhaite écrire en C ++, mais je veux être disponible dans de nombreuses autres langues. Je vais probablement utiliser une combinaison de Swig et Spidermonkey pour cela.
Mais beaucoup d'entre elles revient vraiment à personne ne créant une interface d'objet unifié / réutilisation à court de .dlls. Com était super sous Windows. Idispatch a fait des choses à la disposition de tout ce qui a parlé Idispatch. C'était génial d'écrire nos composants en C ++ et de les utiliser de VBScript dans ASP. Mais rien de tel que ça n'a jamais eu lieu de manière portraitement. Bien sûr, des tentatives ont été faites via Corba et une demi-douzaine d'autres technologies à moitié cuite et souvent malitées - mais elles ont tous le problème des données-marshalling, le problème de l'invocation, les problèmes de performance, les problèmes de l'endian-ness. Personne n'a vraiment passé du temps à essayer de le résoudre, et maintenant, l'industrie évolue vers le savon pour la remplacer pour la performance de la performance (et de coller à Corba où elle le fait).
Selon la façon dont vous examinez ce problème, il y a ou non, de nombreuses applications écrites dans des langages mutiltes.
Par exemple, envisagez une application Web Alternativement, vous pouvez regarder Il peut même s'agir d'un outil Mais je ne pense pas que c'est ce que vous avez à l'esprit. Je pense que votre portée prévue est le "corps principal" du code produit par une seule équipe de projet . Vous vous demandez pourquoi un projet n'écrire pas, disons, un composant en Java, un autre dans Lisp, et un troisième à Erlang, puis les liera tous ensemble comme des livrables unifiées.
Certaines réponses ont été proposées comme la construction / le déploiement est plus difficile, ou tout le monde sera capable de travailler dans toutes les parties du système, en raison d'un manque d'habileté en particulier des langues. Je ne suis pas vendu sur ces types de réponses. J'ai vu des scripts de construction / déploiement méchant dans des projets écrits principalement dans une seule langue. Et dans mon expérience, lorsque presque tout projet correspond à une certaine taille, surtout s'il était écrit par de nombreux esprits, il devient difficile pour tout le monde d'être bien versé dans toutes les parties du système. En outre, sauter d'une langue à une autre (compte tenu d'un développeur suffisamment expérimenté), n'est vraiment pas aussi gros qu'un obstacle que certains le font.
Le problème est que nous ne pouvons pas simplement brancher des morceaux de code comme des blocs LEGO . Nous aimerions, et dans certains cas, peut-être que nous pouvons en quelque sorte, de cela. Le problème concerne principalement la maturité des spécifications des interfaces de composants publics et des dépendances des composants Quoi qu'il en soit, Alors, cela revient vraiment à réduire les coûts d'assemblage des composants. Ceci est une notion légèrement différente que de simplement dire "la construction devient plus difficile". Avec des interfaces publiques bien définies, une protection de l'information appropriée et une découverte de dépendance et une résolution relativement indolore Il n'y a aucune raison pour que les composants d'un seul projet ne puissent pas être écrits dans plusieurs langues.
Un cas est lorsque des bibliothèques ou un autre code en conserve viennent dans une langue différente de l'application. Beaucoup de ce genre de choses sont écrits en C, et beaucoup d'applications de nos jours ne sont pas écrites dans C. Stuff numériques sont souvent écrits en Fortran (à Grad School, je devais interfacer une routine de Fortran vers une application LISP commune).
Lorsque vous avez déjà écrit des pièces importantes, il est beaucoup plus facile d'utiliser des langues supplémentaires que de réécrire et de vérifier le code des autres personnes.
Je pense qu'une grande partie de la raison est parce qu'il n'y a pas de raisons impérieuses de le faire. Si une langue a une fonctionnalité suffisamment convaincante pour l'utiliser (par exemple, une orientation de l'objet), elle est probablement suffisamment convaincante d'utiliser pour l'ensemble du projet. Bitd, il était nécessaire de réécrire des parties de votre code dans la langue d'assemblage si ce n'était pas assez rapide, ou écrivez des adaptateurs afin que vous puissiez appeler un paquet de statistiques de Fortran de nos jours, il n'y a pas beaucoup de pression. pour faire ça. De nombreux problèmes de performance ne sont pas corrects dans le code (par exemple, la latence de réseau) et la plupart des entreprises qui fournissent des composants logiciels leur fournissent plusieurs "saveurs" (par exemple, des fichiers JAR JAR ou des composants .NET). Comme d'autres l'ont mentionné, il existe également une quantité importante d'inertie parmi de nombreux développeurs qui a tendance à les désincénérer à apprendre une nouvelle langue, surtout si c'est différent. Et, bien sûr, si une langue n'est pas différente, il n'y a probablement aucune raison convaincante de l'apprendre.
Nous écrivons fréquemment dans plusieurs langues. Cela dépend de la tâche à accomplir. Dans une application Web récente, j'ai codé le Framework Web en PHP, la balayage client dans JavaScript, le moteur à back-end et les plug-ins PHP dans Delphi et la base de données dans MS-SQL.
Je travaille actuellement dans un environnement où nous effectuons un prototypage rapide dans Delphi, puis envoyez à la production pour coder dans la MS C #. La société dispose également d'une variété d'autres langues employées.
Il y a quelques années, j'ai travaillé sur un projet qui employait 8 langues différentes. C'était un mauvais gâchis, mais il est toujours soutenu à grande échelle.
Donc, je ne peux vraiment pas être d'accord avec la proposition de Kelly français que nous n'utilisons pas plusieurs langues. Il vous suffit d'étendre votre application dans une base de données ou un service Web pour vous connaître. Il n'y a pas 1 langue qui va tout faire. S'il y en avait, je l'utiliserais et assisterais à cet église le dimanche.
Mes 4 derniers emplois ont été appels appelés:
(et cela ne compte même pas SQL, JS, OQL, etc.)
Dans mon expérience, le changement a été le contraire: plus de langues. Les raisons pour cela comprennent:
Ce sont tous des projets payants, BTW. Sur mes projets personnels, je finis toujours par utiliser une seule langue. La simplicité l'emporte sur les avantages de pouvoir tirer un paquet et de l'intégrer avec mon projet rapidement.
J'ai utilisé un mélange de C et Lua (ou C ++ et Lua) dans des projets récents. Je pense que cela libérait d'avoir deux langues avec différents avantages et contre pour équilibrer. Le code Lua devient principalement compilé (cuit au four) dans le même exe, le résultat final n'est qu'un seul binaire.
commentaires sur la difficulté de déboguer cela et de comprendre tout cela, sont valables. Il conserve le nombre de lignes source bas, cependant.
L'objectif de l'Apple-C est à peu près la même approche "amalgame", mais commutant la ligne de mentalité par ligne. Je trouve cette difficulté. Lua et C (++) me permettent de changer la mentalité par fichier source.
Devs s'est inquiété des performances, telles que l'optimisation des appels de méthode virtuelle en C ++ ou la compilation d'exécution du code d'octet de Java, car l'assembleur a été inventé. C'est dans sa nature de se demander quoi que ce soit qui n'est pas manifestement évident.
L'utilisation de plusieurs langues facilite le refactoring plus difficile et coûteux. Parce que des actions telles que bouger une méthode d'une classe à une autre sont beaucoup plus difficiles lorsque ces classes sont écrites dans différentes langues.
Je suis totalement d'accord avec le principe de cette question.
Il est plus facile d'apprendre plusieurs langues spécifiques de domaine que d'essayer d'apprendre à appliquer une langue générale à un ensemble diversifié de domaines.
Ne vous laissez pas tromper en pensant que l'utilisation d'une langue à usage général rétrécit les compétences requises et l'apprentissage de quelque manière que ce soit. C'est juste que maintenant vous devez apprendre à contenir une seule langue dans toutes sortes de formes et à apprendre une demi-douzaine de cadres pour y aller.
Nous avons écrit un système qui a remplacé 10 000 lignes de code Java à usage général avec 750 lignes de code écrites en 2 DSL et collé avec Java. Nous l'avons écrit en 1/10 l'heure du système d'origine, y compris le temps d'apprentissage DSL.
Je dirais que beaucoup d'applications que vous ne le pensez sont écrites en utilisant plusieurs langues. Juste un exemple:
Ceci est principalement une question de gestion. La réponse est plus enracinée dans le Rathe économique que technique. Simple mis, c'est plus cher. Vous pouvez imaginer toutes difficultés comme plus difficiles à gérer, y compris le débogage, le refactoring, le remplacement des développeurs, etc.
Pour de nombreuses classes d'applications, il n'est tout simplement pas nécessaire de «classiques» de projets multilingues (impliquant une langue de haut niveau et une langue de bas niveau), et le coût supplémentaire de la complexité est significatif:
OTOH, beaucoup d'applications modernes utilisent déjà de nombreuses langues différentes, par exemple. Java, JSP, XSLT et JavaScript peuvent tous être utilisés dans le même projet.
J'écris dans Python qui est appelé à partir de C, requête sa dB à l'aide de SQL, effectue ses E / S à l'aide de HTTP, dessert des documents qui sont décrits à l'aide de TEI, les transforme à l'aide de XSLT, rend la sortie du côté du client en utilisant HTML. et CSS, formate sa sortie non-document dans un langage de modèles spécial et ajoute une fonctionnalité à son interface utilisateur à l'aide de JavaScript.
Vous avez peut-être remarqué, il s'agit d'une application Web assez générique (à l'exception du TEI). Les techniques dont vous parlez sont absurdement communes de nos jours. La motivation n'est pas toujours d'optimiser les portions sensibles à la vitesse du code, mais les techniques sont certainement là-bas.
Ceci est un rant blogué. Pas une question.
Qu'est-ce que vous basez votre opinion? Comment savez-vous ce que font les gens? Il y a des millions d'applications là-bas. Je pense qu'il n'y a que certaines applications dans lesquelles ce type de chose serait utile de toute façon, et il a un coût associé (c'est-à-dire que vous devez maintenant embaucher une personne qui connaît deux langues au lieu d'un).
Les gens ne sont pas des idiots. Les langues populaires d'aujourd'hui sont tout-en-un (ou au moins la plupart en une). Aucune personne productive sur Terre ne décidera d'écrire une application dans plusieurs langues, à moins qu'il ne soit sûr que cela lui donnera ce qu'il veut (ou veut) plus rapidement.