Salut à tous !
Je me pose une question depuis quelque temps sur les langages interprétés du genre Python, Ruby , Java, Tcl... et j'en passe.
J'ai l'impression (corrigez moi si je me trompe) que ces langages sont de plus en plus utilisés pour faire de "vrai application" (avec inteface graphique...) maintenant qu'ils ont tous des bindings vers Qt, gtk etc... et plus seulement pour faire des scripts(j'entends par là essentiellement les plugins).
Je ne comprends donc pas pourquoi ces langages sont uniquements interprétés et donc pourquoi il n'existe pas de compilateur permettant de les compiler en code machine. Celà permettrait (au prix de la portabilitée certe) des gains immenses en performances... avec toutes les optimisations que font les compilos etc... Je pense que le code compilé serait moins performant que de C/C++ à cause de leurs typage faible... mais largement plus performant que si il était interprété.
Je ne pense pas que le problème soit d'ordre technique...si on arrive à interpréter un langage, on doit bien réussir à le compiler. C'est ce que fait Ocaml d'ailleurs (et plutot bien d'après ce que j'ai compris). Si ont veut juste faire des petites applications test ou scripts on l'interprète et sinon on le compile si on cherche la performance. Pourquoi celà n'est-t-il pas possible pour les autres langages cités plus haut ?
En fait, l'idéal pour moi serait que tous ces langages puissent être compilable dans un espèce de bytecode à l'instar de java. Et ce bytecode serait "universel" et donc il n'y aurait qu'un seul et unique interpréteur. Plus besoin d'installer 1000 interpréteurs différents pour les utilisateurs. Le must serait qu'on puisse en plus compiler ce bytecode universel en code machine... Celà est-il impossible techniquement ?
HS : Un autre truc que je n'arrive pas à expliquer : http://www.google.fr/trends?q=linux%2C+windows
# Re:
Posté par ciol_banni6 . Évalué à 1.
Pour python, avant la première exécution du script, il est compilé (.py -> .pyc). Je pense que dans certaines applications livrées avec ta distribution il y a systématiquement les .pyc (en plus des .py)
Pour l'interpréteur commun, il y a un projet pour avoir le même byte code entre python et perl 6, je sais pas où ça en est.
[^] # Re: Re:
Posté par Jean B . Évalué à 3.
Par contre contrairement à ce qui est dit au-dessus Python n'est pas compilable en code machine juste en une sorte de package auto exécutable contenant l'interpréteur ou en bytecode.
Par contre Ruby et Python peuvent tourner sur une JVM et si je ne m'abuse le bytecode Java est compilable en natif donc il doit être possible de magouiller un truc.
J'ai aussi entendu dire que Zend (les développeurs de PHP) essayaient désespérément de faire tourner PHP sur une JVM pour pouvoir ensuite le compiler.
[^] # Re: Re:
Posté par Eurystenes . Évalué à 1.
# qqes précisions
Posté par jigso . Évalué à 5.
Sinon le "must" dont tu rêves proviendra probablement de Parrot ; destiné initialement à Perl6, d'autres langages disposent de leur compilateur pour cette VM. cf http://fr.wikipedia.org/wiki/Parrot_(machine_virtuelle)
# Eléments de réponse
Posté par benoar . Évalué à 2.
Ce n'est pas si évident que ça : un interpréteur et un compilateur sont deux choses bien différentes. Faire un compilateur pour un langage qui a déjà un interpréteur, c'est quand même beaucoup de boulot, vu que seul le parser/lexer pourra être réutilisé.
En fait, l'idéal pour moi serait que tous ces langages puissent être compilable dans un espèce de bytecode à l'instar de java.
Python, par exemple, a son propre bytecode, et n'est jamais interprété directement. Beaucoup de langages interprétés aujourd'hui ont leur propre bytecode. Mais s'ils sont différents, c'est pour la même raison qu'il y a plusieurs langages : chacun n'est pas d'accord sur la manière de le faire ...
Certes, avec la JVM et .Net on essaye de plus en plus d'unifier ces bytecodes (il existe des implémentations de Python et Ruby pour la JVM et pour .Net, il me semble, par exemple), mais il y aura toujours le facteur "politique" : chacun a sa vision, et le "combat" entre les différents camps aura toujours lieu à moins de trouver un compromis.
# petite precision
Posté par jiyuu . Évalué à 2.
Je pense que le code compilé serait moins performant que de C/C++ à cause de leurs typage faible
Je pense que tu veux dire "typage dynamique" parce que le C a un typage faible et statique alors que ruby a un typage fort et dynamique.
Voir Typage.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.