Forum Programmation.autre Langages interprétés... questions existentielles...

Posté par  .
Étiquettes : aucune
0
7
juil.
2008
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  . Évalué à 1.

    Juste un élément de réponse parce que j'ai rien à faire avant que ceux qui s'y connaissent mieux répondent.

    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  . Évalué à 3.

      L'interpreteur commun c'est Parrot_(machine_virtuelle).
      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  . Évalué à 1.

        En effet Parrot a l'air super intéressant. Espérons qu'il aura le succès qu'il mérite et que les différent langages de scripts soient compilable vers ce dernier.

  • # qqes précisions

    Posté par  . Évalué à 5.

    Pour info, le gain de performance n'est pas évident - ou au moins il ne sera peut-être pas de l'ordre de ce qu'on imagine. Les opérations de bases de traitement des données (par ex les manipulations de chaines) sont déjà écrites et exécutées en langage machine, même si on passe par une VM. Bien sûr on gagne un niveau d'indirection, mais face au traitement proprement dit ça n'est pas significatif. Par contre le gain au développement et au déploiement à ne pas avoir à recompiler est énorme.

    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  . Évalué à 2.

    si on arrive à interpréter un langage, on doit bien réussir à le compiler
    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  . É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.