Pourquoi n'y a-t-il pas de traducteurs automatisés d'un langage de programmation à un autre? [fermé]

La plupart des langages de programmation sont complets, ce qui signifie que toute tâche pouvant être résolue dans un langage peut être résolue dans un autre, voire sur une machine de Turing. Alors pourquoi n’existe-t-il pas de traducteurs automatiques capables de convertir des programmes d’une langue donnée vers une autre langue? J'ai déjà vu plusieurs 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 100% de traducteur correct dans toutes les langues? Quels sont les défis en pratique? Existe-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 plate-forme.

Considérons un traducteur PHP en Java. Le seul moyen réalisable de le faire sans intégrer une partie du binaire PHP est de réimplémenter tous les modules et les 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 simple. Et même après tout ce travail, vous n'auriez pas de code Java, vous auriez une sorte de monstruosité s'exécutant sur la plate-forme Java, mais celle-ci était structurée de la même manière que PHP.

C’est pourquoi les seuls outils qui me viennent à l’esprit sont la traduction du code pour le déployer, et non pour 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 alors implémenter quelque chose qui traduit un programme en langue X en ce format, et également de ce format en langue Y. Implémentez ces conversions pour toutes les langues qui vous intéressent et que vous avez terminées, n'est-ce pas?

Eh bien tu sais quoi? Un tel format existe déjà: assemblage. Le compilateur effectue déjà la conversion "Langage X en assembleur" et les désassembleurs en conversion "assemblage en Langage Y".

Maintenant, l’assemblage n’est pas un très bon langage pour la conversion inverse, mais MSIL n’est en fait pas si mauvais. Téléchargez Reflector et vous verrez qu'il a des options pour désassembler un assemblage .NET en plusieurs langues (et que les plugins en fournissent encore plus). Il est donc tout à fait possible de prendre un programme en C #, de le compiler dans une DLL (c'est-à-dire MSIL), puis d'utiliser un réflecteur pour le désassembler en VB, C ++ / CLI, F # et bien d'autres encore. Bien sûr, tous les autres travaux de conversion fonctionnent également. Prenez un fichier F #, compilez-le en une DLL, utilisez Reflector pour le convertir en C #.

Bien sûr, les deux gros problèmes que vous rencontrerez sont:

1. Le code est fondamentalement illisible. MSIL (même avec les informations de débogage) supprime beaucoup d’informations de la source originale, donc la version traduite n’a pas une fidélité à 100% (théoriquement, une conversion C # -> MSIL-> C # devrait vous restituer le code original, mais cela habitude).
2. 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.). Ceux-ci doivent être inclus (ou convertis) lorsque vous effectuez également votre conversion.

Il n'y a vraiment rien à contourner de n ° 2, mais vous pouvez probablement contourner n ° 1 avec quelques annotations supplémentaires dans 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 100% de traducteur correct dans toutes les langues? Quels sont les défis en pratique?

• Traduire d'un langage plus structuré à un langage moins structuré et toujours complet de Turing est toujours possible.
  • Cette affirmation doit être considérée dans un sens strictement technique: Cela signifie que le programme traduit produira exactement le même résultat lorsqu’il sera exécuté.
  • Rien n’implique la lisibilité du code traduit ni la préservation des structures de programme originales.
• 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 toujours compilées en code machin (virtuel) *. Ainsi, pour des raisons techniques, il n'est pas nécessaire de disposer d'un compilateur dans un autre langage de haut niveau.

Les langues sont pour les humains. Ainsi, l'exigence implicite de votre question est: « pourquoi est - il pas de traducteur qui génère lisible code » , et la réponse serait (AMHA): parce que s'il y a deux langues qui sont sufficently différents, le de code lisible » des moyens est écrit est différent d'une manière qui nécessiterait non seulement de traduire les algorithmes, mais prendrait des algorithmes différents.

Par exemple, comparez une itération typique en C et une en lisp. Ou bien les pythons «à leur meilleur» avec un rubis idiomatique.

Ici, les mêmes problèmes commencent à apparaître dans les langues réelles, comme lorsque vous traduisez "Il pleut des chats et des chiens" en quelque chose qui a la signification de "Il pleut comme s'il s'agissait de seaux" lors de la traduction d'anglais en allemand, vous ne pouvez pas traduire mot par mot plus, mais vous devez chercher le sens.

Et le «sens» n'est pas un concept facile à travailler.

*) eh bien, il y a du café ...

C'est théoriquement possible mais surtout inutile. Presque n'importe quelle combinaison de langues source et cible est possible, mais dans la plupart des cas, personne ne voudrait jamais regarder ou utiliser le résultat.

Un bon nombre de compilateurs ciblent le C, tout simplement parce que les compilateurs C sont disponibles pour presque toutes les plates-formes existantes (et qu'il existe des générateurs de compilateur automatiques qui vous permettent 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 langues utilisées par diverses machines virtuelles telles que .NET, JVM, C-- et LLVM.

Le point clé, cependant, est que ce n’est utile que si vous traitez la cible comme étant un langage assembleur qui n’est utilisé que comme une étape du processus de compilation. En particulier, vous ne voulez généralement pas qu'un programmeur normal lise ou travaille avec ce résultat; ce ne sera généralement pas très lisible.

FWIW, il existe un traducteur de Java vers D. Il s'appelle TioPort et a été utilisé dans une tentative assez sérieuse de porter SWT sur D. Le problème principal rencontré était qu'il aurait été nécessaire de porter d'importantes parties de la bibliothèque standard Java. .

Bien qu’il ne s’agisse pas d’une traduction de code en soi, le concept d’ établi de langue montre comment on pourrait mettre en œuvre une sorte de traducteur 100% correct dans toutes les langues.

Dans notre approche actuelle, le code source est stocké dans un format textuel. Lors de la compilation, ces fichiers texte lisibles par l’homme sont analysés dans une arborescence de syntaxe abstraite, qui est utilisée pour générer un code octet ou un code machine. Cette représentation abstraite est toutefois temporaire et interne au compilateur.

Dans l'approche langage, une représentation similaire de la syntaxe abstraite est l'artefact permanent stocké. Le code machine et le code «source» textuel sont 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 réalité indépendante de la langue et peut être utilisée pour générer du code textuel dans n'importe quelle langue mise en œuvre. Cela signifie qu'une personne peut travailler librement sur différents aspects du système, en utilisant la langue qu'elle considère la plus appropriée, ou que chaque membre de l'équipe peut travailler sur le projet partagé dans la langue avec laquelle il est le plus familier.

Autant que je sache, la technologie est encore loin d'être utilisable dans le développement grand public, mais plusieurs groupes y travaillent indépendamment. Difficile de dire si certains d'entre eux respecteront leurs promesses, mais il serait intéressant de voir cela se produire.

Il y a des 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 célèbre, le premier compilateur C ++ n'était pas réellement un compilateur, mais traduit C ++ en source C (vraiment compliquée) qui a ensuite été compilé par le compilateur C. De nombreux compilateurs peuvent générer du code assembleur sur demande, mais au lieu de cracher le texte de l'assembly puis de le traduire en code machine, ils peuvent normalement générer directement du code machine.

Étant donné une spécification complète de la langue A, il n’est pas difficile en principe d’écrire un programme qui exprime ses directives dans une langue B. Mais d’habitude, toute personne qui prend la peine choisira quelque chose de très bas niveau pour "langue B": Code machine , ou ces jours bytecode: Jython est une implémentation de python qui génère du code octet Java, qui est interprété par la machine virtuelle Java. Inutile de se préoccuper d'écrire et de compiler des hiérarchies de classes Java!

Ceci est 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 de langages interprétés.

J'imagine que ce n'est pas ce dont vous parlez. Vous voulez probablement un traducteur qui convertit le C ++ en quelque chose comme Java ou Python. Quel est le but de cela, cependant? Au mieux, le résultat final aura exactement la même efficacité que la source d'origine. (Pratiquement, ça va être bien pire.)

Si vous souhaitez simplement que le code soit traduit afin que vous puissiez le lire comme une langue que vous comprenez, un tel traducteur aurait l'effet inverse de l'effet souhaité. Il ne vous restera plus qu'un tas de codes cryptés, peu intuitifs et illisibles.

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 d'énormes bibliothèques pour une autre - ou peut-être même être impossible. Par conséquent:

1. Si le programme est trivial, vous pourriez obtenir un résultat décent. Mais alors, si c'est aussi simple que ça, à quoi bon de le faire passer par un traducteur?
2. Si le programme est non trivial, le code sera de mauvaise qualité.

En fin de compte, le seul moyen d'écrire un bon code est de l'écrire. Les ordinateurs ne peuvent tout simplement pas - du moins pas encore - faire correspondre les humains aux questions de lisibilité, de meilleures pratiques et de solutions élégantes.

En bref, ça ne vaut tout simplement pas la peine.

Il n'y a pas de traducteur de langue pour les langages de programmation car les langages de programmation sont incroyablement complexes. Bien que ce soit hypothétiquement possible, les défis sont nombreux.

Le premier défi est simplement dans les pratiques acceptables de la langue. La conversion entre deux langages orientés objet, tels que Java et C ++, est extrêmement complexe et tous deux basés sur le langage C. Le programme de traduction devrait avoir une connaissance parfaite des bibliothèques standard pour les deux langues et être capable de connaître les différences de comportement. Vous devrez créer un dictionnaire volumineux et, même dans ce cas, les différences de styles de programmation d'un programmeur à l'autre signifieraient qu'il faudrait deviner comment effectuer certaines modifications.

Une fois que vous avez traduit la syntaxe, vous devez ensuite comprendre comment convertir une construction de la première langue en une construction de la deuxième langue. C'est très bien si vous allez d'un objet en C ++ à un objet en Java (c'est relativement facile), 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 il peut en résulter un autre problème, à savoir la création d'un objet blob. Le blob est un antipattern qui est assez commun.

Ce n'est pas une liste complète des problèmes, mais ce ne sont que deux et ils sont grands. Un de mes professeurs a mentionné qu'une personne avait convaincu son employeur qu'elle pourrait en fabriquer une du code machine au code C dans les années 80, mais cela n'a pas fonctionné à l'époque. Je doute qu'il y en ait jamais un qui fonctionne pleinement.

Le but de la compilation est d’obtenir quelque chose d’utile pour l’ordinateur. c'est à dire quelque chose qui peut courir. Pourquoi compiler à quelque chose qui peut même être de niveau supérieur à celui que vous avez écrit?

J'aime mieux la stratégie de .NET. Tout compiler dans un langage commun. Cela donne l’avantage que les langues puissent communiquer sans avoir à créer de (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, vous devez écrire 90 compilateurs. C'est beaucoup de travail supplémentaire pour peu d'avantages.