Discussion:Interprète (informatique)

message: « Il était particulièrement pratique quand les temps de réponse des machines étaient plus lents. Aujourd'hui, ce temps de compilation d'un programme répartis en différents modules est devenu négligeable, aussi les langages interprétés ont perdu de leur intérêt pour la programmation pure. »
Il me semble que l'interet des interpréteurs soit plutôt dans la portabilite que dans le temps de compilation, non ? Aoineko 11 aoû 2003 à 10:09 (CEST)

message: La phrase suivante relève de la didactique de l'informatique et n'a rien à voir dans un article sur les interprètes.  «Il est à noter toutefois que les structures de données n'ont plus à être enseignées de façon pratique aujourd'hui, sauf aux concepteurs de langages. Elles sont en effet disponibles en standard dans tous les langages objet, et même quelques autres. Ainsi Perl implémente les hashs ou fonctions de hachage comme type d'accès de base, éliminant tout besoin de les programmer».
Je me propose de l'enlever.
Pierre de Lyon 2 février 2006 à 08:09 (CET)
replies: text: Tout à fait d'accord. Je trouve même que tout le paragraphe devrait être supprimé : les langages compilés et interprétés n'ont aucune raison théorique d'avoir plus ou moins de « particularités ». Palpalpalpal 24 juillet 2006 à 15:26 (CEST)
thread_title:  Considérations didactiques 

message: Il me semble que la dernière partie : utilisation des langages interprétés, devrait donner lieu à un article sur les langages de programmation à domaines spécifiques, en anglais en:Domain-specific programming language et donc ne pas figuer là.  On pourrait d'ailleurs traduire l'article en question.
Pierre de Lyon 2 février 2006 à 08:17 (CET)
thread_title:  Langage à domaines spécifiques

message: L'argument sur la vitesse de compilation est d'ordre historique
du moins en ce qui concerne des applications de taille moyenne.
L'exemple de Turbo Pascal montre que ce qui accélère le travail des programmeurs, c'est
d'avoir une intégration raisonnable des outils pour ne pas avoir à se dire "bon, je sors de 
l'éditeur, maintenant je compile, zut point virgule ligne 203, je recharge l'editeur je vais ligne 203 etc". Mais ça on l'a aussi avec un compilateur en ligne de commande, et un makefile
lance par une touche depuis emacs.
Ce qui me parait plus fondamental avec un interprete(ur), c'est de pouvoir lancer l'exécution
de programmes incomplets sans avoir à écrire des "stubs" pour des fonctions 
manquantes, du moment qu'on ne tente pas de les appeler. La aussi, c'est un gain de temps
pour verifier vite fait qu'un bout de code fonctionne/
: On interprète pendant la mise au point et on compile quand c'est au point.  Moralité: on a besoin des deux!  Pierre de Lyon 3 février 2006 à 19:32 (CET)
thread_title:  Argument sur vitesse de compilation 

message: L'article interprétation (informatique) est indigent, il faut plutôt le rediriger vers interprète.Pierre de Lyon 25 novembre 2006 à 14:37 (CET)
thread_title:  Rediriger ? 

message: Cela ne choque personne qu'il y est plus de contenu dans le synopsis que dans le corps ?!?
Un chapitre "Cycle", un chapitre "comparaison interprèteur-compilateur", …
« Ainsi, le langage BASIC fut le premier langage interprété à permettre au grand public d'accéder à la programmation, tandis que le premier langage de programmation moderne interprété est Lisp. » Détail limite anecdotique qui devrait être dans le chapitre "Historique".
Etc.
Ranger votre chambre ;)
Lacrymocéphale 30 juillet 2008 à 12:20 (CEST)
thread_title:  Équilibrage