Discuter:Interprète (informatique)

Un article de Wikipédia, l'encyclopédie libre.

« 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)

Sommaire

[modifier] Interprète ou interpréteur ?

Oh l'horrible angliscisme interpréteur! J'ai changé cela, mais maintenant il faudrait changer le titre de l'article et je ne sais pas faire.

Pierre de Lyon 2 février 2006 à 07:55 (CET)

Interpréteur a l'avantage d'être moins ambigu, et le bon goût de correspondre à l'usage. Ce serait bien que les gens qui se permettent des modifs aussi importantes ne soient pas ceux qui font deux fautes par phrase (« angliscisme » → « anglicisme » ; faire est transitif obligatoire (ce n'est pas do !) ; et je ne compte pas la typo à l'anglaise (pas d'espace devant le point d'exclamation). Doit-on chasser de la langue française tous les mots qui viennent de l'anglais, ou tous les mots qui sont nés d'erreurs de traduction, sans en considérer les conséquences ? Palpalpalpal 24 juillet 2006 à 15:14 (CEST)

Tout d'abord je commencerais par une petite remarque: le mot anglais «typo» se traduit en français par «coquille».

Ici, « typo » est l'abréviation de typographie. D'ailleurs je ne vois pas ce que signifierait dans ma phrase « coquille à l'anglaise ». Palpalpalpal 24 juillet 2006 à 21:29 (CEST)

Je suis désolé, si je néglige un peu mon style dans les discussions et je vous prie de m'en excuser. Je suis aussi désolé de déroger à ma règle qui consiste en général à ne pas répondre aux attaques ad hominem; mais c'est la dernière fois dans ce forum de discussion.

Ma remarque n'est pas un ad hominem, bien qu'elle y ressemble : tout en prétendant exercer une compétence de correcteur, vous montrez l'absence d'une partie de cette compétence en faisant des fautes criantes. Vous pouvez négliger votre style, vous avez même le droit à l'erreur ; mais si c'est pour corriger les autres auteurs de Wikipédia péremptoirement (« l'horrible angliscisme »), sans arguments, qu'est-ce qui peut, à part la démonstration implicite de votre compétence, donner de la valeur à votre jugement ? Palpalpalpal 24 juillet 2006 à 21:29 (CEST)
La voici, je pense. Dans le livre Théorie des programmes de Livercy, publié en 1976 et malheureusement hors impression, dont j'ai été le co-auteur nous utilisions le mot interprète et je crois que c'est le premier ouvrage d'enseignement en français présentant ces concepts. Une version électronique existe dans [1] et la page d'index où se trouve interprète est [2]. Pour la petite histoire, nous avions discuté certains termes opiniâtrement, mais je ne me souviens pas que nous ayons discuté le mot inteprète. Pierre de Lyon 25 juillet 2006 à 09:58 (CEST)

Je ne vois pas où est l'absence d'ambiguïté, ni l'usage dans l'emploi d'un mot anglais. L'argument est constamment invoqué pour les anglicismes. Or souvent le français est plus riche que l'anglais. Je vais prendre quelques exemples: on nous dit souvent que «process» ne peut se traduire que par «process», or c'est précisément un mot qui a deux traductions en français à savoir «procédé» et «processus». De même «to implement» que d'aucuns traduisent par «implémenter» a deux traductions différentes «implanter» et «mettre en œuvre».

  • L'absence d'ambiguïté ? Si l'on utilise interprète, on n'a qu'un mot pour deux interprétations. Quand on utilise interpréteur, on n'a besoin d'aucune information supplémentaire pour savoir qu'on parle d'un programme informatique. Interpréteur n'a pas de page de désambiguïsation sur Wikipédia. Je ne dis pas que l'ambiguïté est forcément un mal ; simplement que c'est une partie du prix à payer si l'on élimine interpréteur, prix qu'on ne peut pas se contenter d'ignorer.
  • Je ne parle que du cas particulier qui nous occupe. Je n'ai jamais traduit process par process. Aux traductions littérales de process que vous citez, j'ajouterais procès (et traitement). Les erreurs que vous décrivez montrent qu'il faut être prudent, mais ne justifient pas de tomber dand l'excès inverse en bannissant tout anglicisme. Palpalpalpal 24 juillet 2006 à 21:29 (CEST)
Eh bien oui, j'affirme qu'en traduisant interpreter par intepréteur on a fait n'importe quoi sans réfléchir sans regarder l'usage établi. Pierre de Lyon 25 juillet 2006 à 09:58 (CEST)
Là-dessus, nous pouvons tomber d'accord. C'est peut-être malheureux que l'exemple de votre livre n'ait pas été suivi. Mais c'est de l'usage actuel qu'il est question. Quand nous avons intégré algorithme, nous avons peut-être fait une erreur. Que gagne-t-on et que perd-on à essayer (souvent despérément) de corriger ces erreurs passées ? Palpalpalpal 25 juillet 2006 à 13:46 (CEST)
Je pense qu'il n'y a rien de grave, comme nous faisons une encyclopédie francophone, nous mettons le mot correct et le plus ancien attesté, à savoir inteprète et nous mettons un renvoi depuis le mot interpréteur et nous expliquons l'usage (malheureux) en train de s'installer. Profitons en pour expliquer à nos collègues informaticiens à bien parler le français (-: je voudrais dire bien l'écrire mais après mon premier message j'ai des scrupules!) et surtout n'abondons pas dans leur sens. Pierre de Lyon 25 juillet 2006 à 14:56 (CEST)


Enfin en traduisant «interpretor» par «interpréteur» on perd l'analogie qu'a l'anglais, à savoir celle de l'homme qui traduit et celle du programme qui fait la même chose (-: oui «faire» est un verbe transitif). La traduction devient un appauvrissement.

C'est interpreter, pas interpretor. Et ce qu'on perd, c'est l'ambiguïté qu'il y a en anglais. On a toujours un lien étymologique évident. Palpalpalpal 24 juillet 2006 à 21:29 (CEST)
J'aurais dû aller vérifier, c'est bien interpreter qui est le mot que je voulais citer et qui a une rubrique d'homonymie dans le Wikpedia anglais. Ceci dit, à ma décharge, si l'on cherche interpretor dans le Wikipédia anglais, on constate que beaucoup d'auteurs utilisent interpretor pour intepreter. Très probablement l'un doit être angalis et l'autre américain. Cependant, j'affirme que chaque fois que l'on francise un mot anglais ou américain au lieu de le traduire on perd de l'information et c'est évidemment le cas avec interpréteur. Notre langue informatique s'abatardit. Pierre de Lyon 25 juillet 2006 à 09:58 (CEST)

Quant à l'usage, je dois dire que depuis 1969 que je pratique et enseigne l'informatique, j'ai toujours employé le mot «interprète» et mes élèves m'ont toujours compris.

Si vous leur disiez « interprétateur » (sic) ou « intéprète » (sic), ils vous comprendraient aussi bien. J'admets que déterminer l'usage n'est pas une mince affaire. Mais êtes-vous en train de me dire que les gens qui utilisent interpréteur sont rares ? Palpalpalpal 24 juillet 2006 à 21:29 (CEST)
Non, mais je constate que les gens ignorant les ressources de la langue français sont nombreux. Pierre de Lyon 25 juillet 2006 à 09:58 (CEST)

Pour conclure, comme je travaille pour le Wiképdia francophone, je continuerai à pourchasser les anglicismes, quoi qu'en disent mes contradicteurs, il en va de la survie de notre langue et de notre science informatique. Pierre de Lyon 24 juillet 2006 à 16:01 (CEST)

Pourchasserez-vous bit avec la même détermination ? Quel mot suffisamment français utilisez-vous pour algorithme ? Chaque mot est un cas particulier ; je ne vois pas ce qu'on peut gagner à rejeter (ou embrasser) systématiquement tous les anglicismes. Palpalpalpal 24 juillet 2006 à 21:29 (CEST)
(-: Le mot bit a précisément, en français, cette ambigüité dont je parlais, qui nous renvoie à coquille et qui nous rappelle notre esprit gaulois. Quant au mot algorithme j'espère que vous ne voulez par me faire dire qu'il s'agit d'un mot anglais récent.Pierre de Lyon 25 juillet 2006 à 09:58 (CEST)
Pour bit, l'ambiguïté est effectivement gênante, et justifierait qu'on cherche un substitut – voilà une cause qui me semble plus utile que celle d'interprète. Pour algorithme, je comptais simplement sur votre coopération pour préciser les limites de votre rejet des emprunts. Palpalpalpal 25 juillet 2006 à 13:46 (CEST)
Quant à algorithme, comme il s'agit d'un mot arabe (ou persan) attesté en français depuis le XVIe siècle, je crois, il ne s'agit pas du même débat. Mais je veux bien aussi participer. Pierre de Lyon 25 juillet 2006 à 14:56 (CEST)
Oh, il n'y a pas de débat sur algorithme. On pourrait en lancer un, mais ça serait vraiment uniquement histoire de rigoler. Pour moi les questions seraient les mêmes : en quoi la date ou la langue à laquelle un mot est emprunté est-elle utile pour décider de son sort ? Palpalpalpal 25 juillet 2006 à 17:26 (CEST)

Enin à propos du le point d'exclamation: il faut savoir que l'on ne met pas une espace, mais une demi-espace avant un point d'excalamation et cela mon clavier ne sait pas «le» faire. Pierre de Lyon 25 juillet 2006 à 09:58 (CEST)

Ce qu'il « faut » savoir, c'est qu'en français moderne, on met une espace fine, qui est… une espace, aussi sûrement qu'une demi-part de gâteau est une part de gâteau. Une espace insécable quelconque ( ) la remplace mieux que rien du tout. Palpalpalpal 25 juillet 2006 à 13:46 (CEST)

[modifier] Considérations didactiques

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)

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)


J'agrée complètement, pour deux raisons concernant ces considérations didactiques :

  • ce n'est pas leur place
  • je suis en complet désaccord avec.

Hors sujet mais je peux détailler :

  • la réimplantation des structures de données classiques est un bon

exercice qui ne fait pas de mal à ceux qui, justement, apprennent à programmer. Mais il faut bien distinguer l'aisance dans la manipulation des pointeurs, acquise par ces exercices classiques, d'avec la connaissance des structures fournies par la bibliothèque du langage utilisé .Les deux sont indispensables.

  • ceux qui ne connaissent pas les détails affreux de telle ou telle structure

finissent un jour où l'autre par en recréer une implémentation douteuse

  • et d'autre part ils sont tendance à oublier les limites raisonnables d'emploi

de ces structures.

Que ceux qui n'ont jamais vu d'étudiants implémenter un "tampon de texte" sous forme de liste d'octets à double chainage m'accusent d'exagération !

Utilisateur: Schtong

[modifier] Langage à domaines spécifiques

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)

[modifier] Argument sur vitesse de compilation

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)

[modifier] Rediriger ?

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)

[modifier] Sources pour « interprète » ?

En l'absence de source, utiliser « interprète » pour désigner ce concept n'est rien d'autre que du travail inédit. Merci de citer vos sources, c'est une règle sur Wikipédia.

Bien entendu, je ne parle pas d'un document utilisant le mot « interprète » pour désigner ce type de programme — ce serait une source primaire — mais d'un document qui explique d'un point de vue linguistique qu'« interprète » peut ou doit être utilisé. C'est ce exactement que je fais pour « interpréteur », en citant une recommandation officielle d'un organisme de normalisation de la langue. Vous ne le faites pas, vous avez tort.

Quant à la nécessité de signer, encore une fois, je ne vois pas le rapport, les sources sont plus intéressantes, plus fiables et plus valables que les opinions ou les traductions personnelles de tel ou tel contributeur (sauf si, bien entendu, le contributeur en question est un expert reconnu en la matière, et que son travail sur le sujet a été publié ailleurs que sur Wikipédia ; est-ce votre cas ? si oui, mettez un lien vers votre travail sur « interprète » / « interpréteur », et le problème sera réglé) voir plus bas.

Ah oui, j'oubliais, dire que c'est une « mauvaise » traduction, et que c'est utilisé « à tort », n'est pas neutre. Or la neutralité est également une règle. Pour être neutre, vous devez préciser qui considère que c'est une mauvaise traduction (par exemple, tel ou tel linguistique ou organisme), et là encore, citer une source. On n'y coupe pas. Désolé.
Je viens de voir le lien vers votre ouvrage dans la discussion plus haut, je l'ai donc placé en source pour montrer l'usage. Ça reste une source primaire, mais c'est mieux que rien.
J'ai aussi distancié le propos en présentant le fait qu'il s'agisse d'une mauvaise traduction, non pas de manière péremptoire comme une vérité, mais comme un point de vue adopté par certains. Il reste encore à l'attribuer, c'est-à-dire à citer une source disant explicitement que la traduction est mauvaise et qu'elle doit être évitée — à vrai dire, en l'état, c'est plutôt le contraire (cf. recommandation de l'OQLF), mais si vous avez des sources n'hésitez pas à les produire.
Enfin, pour éviter d'alourdir le propos en intro, j'ai placé ces précisions dans un paragraphe dédié avec un renvoi depuis l'intro, et des liens vers le wiktionnaire.
J'espère que tout ceci vous conviendra, et que nous pourrons tous deux retourner à nos occupations dans la sérénité.