Pourquoi n'y a-t-il pas de traducteurs automatisés d'un langage de programmation à un autre?
La plupart des langages de programmation sont Turing complet, ce qui signifie que toute tâche qui peut être résolue dans un langage peut être résolue dans un autre, ou même sur la machine Turing. Alors pourquoi n'y a-t-il pas de traducteurs automatiques capables de convertir des programmes d'une langue donnée vers une autre langue? J'ai vu quelques tentatives pour deux langues, mais elles ne fonctionnent toujours que sur un sous-ensemble limité d'une langue et peuvent difficilement être utilisées pour convertir des projets réels.
Est-il possible, au moins en théorie, d'écrire un traducteur 100% correct dans toutes les langues? Quels sont les défis en pratique? Y a-t-il des traducteurs existants qui fonctionnent?
Le plus gros problème n'est pas la traduction réelle du code du programme, mais le portage de l'API de la plateforme.
Considérez un traducteur PHP à Java. La seule façon possible de le faire sans incorporer une partie du binaire PHP est de réimplémenter tous les modules et API de PHP en Java. Cela implique la mise en œuvre de plus de 10 000 fonctions. Comparé à cela, le travail de traduction de la syntaxe est aussi simple que possible. Et même après tout ce travail, vous n'auriez pas de code Java, vous auriez une sorte de monstruosité qui se produit sur la plate-forme Java, mais qui était structurée comme PHP à l'intérieur.
C'est pourquoi les seuls outils de ce genre qui me viennent à l'esprit sont tous de traduire du code pour le déployer, et non de le maintenir par la suite. Le GWT de Google "compile" Java en JavaScript. Le hiphop de Facebook compile PHP en C.
Si vous avez un format intermédiaire, vous pouvez implémenter quelque chose qui traduit un programme en langage X en ce format, et aussi de ce format à la langue Y. Implémentez ces conversions pour toutes les langues qui vous intéressent et vous avez terminé, non?
Tu sais quoi? Un tel format existe déjà: Assembly. Le compilateur effectue déjà la conversion "Langue X en assembleur" et désassemble la conversion "Assemblage en langage Y".
Maintenant, Assembly n'est pas un si bon langage pour faire la conversion inverse, mais MSIL n'est en fait pas si mal. Téléchargez Reflector et vous verrez qu'il a des options pour démonter un assemblage .NET dans un tas de langages différents (et les plugins fournissent encore plus). Il est donc tout à fait possible de prendre un programme en C #, de le compiler en un DLL (c'est-à-dire MSIL), puis d'utiliser le réflecteur pour le démonter en VB, C++/CLI, F # et un tout bien sûr, tous les autres travaux de conversion aussi. Prenez un fichier F #, compilez-le dans une DLL, utilisez Reflector pour le convertir en C #.
Bien sûr, les deux gros problèmes que vous trouverez sont:
- Le code est fondamentalement illisible. MSIL (même avec des informations de débogage) supprime beaucoup d'informations de la source d'origine, de sorte que la version traduite n'a pas une fidélité à 100% (en théorie, une conversion C # -> MSIL-> C # devrait vous rendre le code d'origine, mais il habitude).
- De nombreux langages .NET ont leurs propres bibliothèques personnalisées (par exemple, la bibliothèque d'exécution VB, la bibliothèque F #, etc.). Elles devraient également être incluses (ou converties) lorsque vous effectuez également votre conversion.
Il n'y a vraiment rien à contourner # 2, mais vous pourriez probablement contourner # 1 avec quelques annotations supplémentaires dans le MSIL (via des attributs, peut-être). Ce serait un travail supplémentaire, bien sûr.
Est-il possible, au moins en théorie, d'écrire un traducteur 100% correct dans toutes les langues? Quels sont les défis en pratique?
- La traduction d'une langue plus structurée vers une langue moins structurée qui est toujours complète de Turing est toujours possible.
- Cette revendication doit être considérée dans un sens strictement technique: cela signifie que le programme traduit produira exactement le même résultat lors de son exécution.
- Rien n'est impliqué dans la lisibilité du code traduit ou la préservation des structures de programme d'origine.
- La traduction d'un langage moins structuré vers un langage plus structuré est possible, mais le code traduit restera dans sa forme moins structurée.
Pourquoi voudriez-vous convertir un programme?
Les deux langues, la langue source et la langue cible sont de toute façon compilées en code machine (virtuel) *, donc pour des raisons techniques, il n'est pas nécessaire d'avoir un compilateur vers une autre langue de haut niveau.
Les langues sont pour les humains. Donc, l'exigence implicite de votre question est: 'pourquoi n'y a-t-il pas de traducteur qui génère du code lisible ', et la réponse serait (à mon humble avis): parce que s'il y a deux langues suffisamment différentes, la façon dont le `` code lisible '' est écrit est différente d'une manière qui ne nécessiterait pas seulement de traduire les algorithmes, mais de prendre des algorithmes différents.
Par exemple, comparez une itération typique en C et une dans LISP. Ou les pythons "one best way" avec Ruby idiomatique.
Ici, les mêmes problèmes commencent à apparaître que vous avez dans de vraies langues, comme vous traduisez "Il pleut des chats et des chiens" en quelque chose avec la signification de "Il pleut comme il le ferait des seaux" lors de la traduction de l'anglais vers l'allemand, vous ne pouvez pas traduire Word par Word plus, mais vous devez chercher le sens.
Et le "sens" n'est pas un concept facile à travailler.
*) et bien, il y a le coffeescript ...
C'est théoriquement possible mais surtout inutile. Presque toutes les combinaisons de langues source et cible sont possibles, mais dans la plupart des cas, personne ne voudrait jamais regarder ou utiliser le résultat.
Un bon nombre de compilateurs ciblent C, simplement parce que les compilateurs C sont disponibles pour presque toutes les plates-formes existantes (et il existe des générateurs de compilateurs automatiques qui vous permettront de concevoir un processeur et de générer automatiquement un compilateur C qui cible votre nouveau processeur). Il existe également, bien sûr, un bon nombre d'implémentations qui ciblent les langages utilisés par diverses machines virtuelles telles que .NET, JVM, C-- et LLVM.
Le point clé, cependant, est qu'il n'est vraiment utile que si vous traitez la cible est essentiellement un langage d'assemblage qui n'est utilisé que comme une étape dans le processus de compilation. En particulier, vous voulez généralement pas qu'un programmeur normal lise ou travaille avec ce résultat; il ne sera généralement pas très lisible.
FWIW, il y a un traducteur de Java vers D. Il s'appelle TioPort et a été utilisé dans une tentative assez sérieuse de porter SWT vers D. Le principal problème qu'il a rencontré était qu'il aurait fallu porter des portions massives de la bibliothèque standard Java.
Bien qu'il ne s'agisse pas de traduction de code en soi, le concept de ateliers de langue montre comment quelque chose de semblable à un traducteur 100% correct entre toutes les langues pourrait être implémenté.
Dans notre approche actuelle, le code source est stocké dans un format textuel. Pendant la compilation, ces fichiers texte lisibles par l'homme sont analysés dans une représentation arborescente de syntaxe abstraite, qui à son tour est utilisée pour générer soit du bytecode soit du code machine. Cette représentation abstraite est cependant temporaire et interne au compilateur.
Dans l'approche du pupitre de langage, une représentation d'arbre de syntaxe abstraite similaire est l'artefact permanent stocké. Le code machine et le code "source" textuel sont tous deux générés sur la base de cette représentation abstraite. L'une des conséquences d'une telle méthode est que la représentation abstraite du programme est en fait indépendante de la langue et peut être utilisée pour générer du code textuel dans n'importe quelle langue implémentée. Cela signifie qu'une personne peut travailler librement sur différents aspects du système en utilisant la langue qu'elle considère comme la plus appropriée, ou que chaque membre de l'équipe peut travailler sur le projet partagé dans la langue qu'elle connaît le mieux.
Pour autant que je sache, la technologie est encore loin d'être utilisable dans le développement traditionnel, mais plusieurs groupes y travaillent indépendamment. Difficile de dire si l'un d'entre eux tiendra ses promesses, mais il serait intéressant de voir cela se produire.
Il y a quelques traducteurs automatiques. Si votre objectif est de produire du code compilable, plutôt que du code lisible, il est tout à fait possible et parfois utile, mais pas très souvent. De manière connue, le premier compilateur C++ n'était pas en fait un compilateur, mais a traduit C++ en source C (vraiment compliquée) qui a ensuite été compilée par le compilateur C. De nombreux compilateurs peuvent générer du code d'assemblage sur demande - mais au lieu de cracher du texte d'assemblage et de le traduire ensuite en code machine, ils peuvent normalement générer directement du code machine.
Étant donné une spécification complète du langage A, il n'est pas si difficile en principe d'écrire un programme qui exprime ses directives dans un langage B. Mais généralement, quiconque se donne la peine choisit quelque chose de très bas niveau pour le "langage B": le code machine , ou ces derniers bytecode: Jython est une implémentation de python qui génère Java octet code, qui est interprété par le Java = VM. Pas besoin de prendre la peine d'écrire et de compiler Java hiérarchies de classes!
Cela se fait tout le temps.
Chaque compilateur traduit le "langage principal", comme C++, en langage d'assemblage natif de la machine ou en bytecode indépendant de l'architecture dans le cas des langages interprétés.
J'imagine que ce n'est pas de cela dont vous parlez. Vous voulez probablement un traducteur qui convertit C++ en quelque chose comme Java ou Python. Quel est l'intérêt de cela, cependant? Au mieux, le résultat final aura exactement la même efficacité que la source d'origine. ( Pratiquement, ce sera bien pire.)
Si vous voulez simplement que le code soit traduit pour que vous puissiez le lire dans une langue que vous comprenez, un tel traducteur aurait l'opposé de l'effet souhaité. Vous vous retrouverez avec une flopée de code cryptique, peu intuitif et illisible.
En effet, seules les choses les plus triviales se traduisent directement d'une langue à l'autre. Souvent, ce qui est simple dans une langue nécessite des bibliothèques massives pour une autre - ou pourrait être tout à fait impossible. Donc:
- Si le programme est trivial, vous pourriez obtenir un résultat décent. Mais alors, si c'est aussi simple, à quoi sert-il de le faire passer par un traducteur?
- Si le programme n'est pas trivial, le code sera de mauvaise qualité.
En fin de compte, la seule façon d'écrire du bon code est de l'écrire. Les ordinateurs ne peuvent tout simplement pas - du moins pas encore - faire correspondre les humains sur les questions de lisibilité, de meilleures pratiques et de solutions élégantes.
En bref, ça n'en vaut pas la peine.
Il n'y a pas de traducteurs de langue pour les langages de programmation car les langages de programmation sont incroyablement complexes. Bien que cela soit hypothétiquement possible, il existe de nombreux défis.
Le premier défi réside simplement dans les pratiques acceptables de la langue. La conversion entre deux langages orientés objet comme Java et C++ est incroyablement complexe, et ils sont tous deux basés sur C. Le programme du traducteur devrait avoir une parfaite connaissance des bibliothèques standard pour les deux langages et être capable de connaître les différences de comportement. Il vous faudrait créer un dictionnaire massif et même dans ce cas, les différences de styles de programmation d'un programmeur à l'autre signifieraient qu'il devrait deviner comment effectuer certains changements.
Une fois que vous avez obtenu la traduction de la syntaxe, vous devez alors comprendre comment convertir une construction dans la première langue en une construction dans la deuxième langue. C'est très bien si vous allez un objet en C++ vers un objet en Java (comparativement facile c'est) mais que faites-vous avec vos structures C++? Ou les fonctions en dehors des classes C++ "Décider comment gérer cela peut être délicat car cela peut entraîner un autre problème, à savoir la création d'un objet blob. Le blob est un antipattern qui est assez courant.
Ce n'est pas une liste complète des problèmes, mais ce ne sont que deux et ils sont gros. Un de mes professeurs a mentionné que quelqu'un avait convaincu son employeur qu'il pouvait en faire un du code machine au C dans les années 80, mais cela n'a pas fonctionné à l'époque. Je doute qu'il y en aura un qui fonctionnera pleinement.
Le but de la compilation est d'obtenir quelque chose d'utile pour l'ordinateur. c'est-à-dire quelque chose qui peut fonctionner. Pourquoi compiler en quelque chose qui peut même être de niveau supérieur à celui dans lequel vous l'avez écrit?
J'aime mieux la stratégie de .NET. Compilez tout dans une langue commune. Cela donne l'avantage aux langues de pouvoir communiquer sans avoir besoin de créer (N ^ 2) -N compilateurs inter-langues.
Par exemple, si vous disposiez de 10 langages de programmation, il vous suffirait d'écrire 10 compilateurs sous le modèle .NET et ils pourraient tous communiquer entre eux. Si vous avez créé tous les compilateurs multilingues possibles, vous devrez écrire 90 compilateurs. C'est beaucoup de travail supplémentaire pour peu d'avantages.