Re: [TRAD GNU] Re: [TRAD GNU] Re: [TRAD GNU] quelques mises à jour

["de Maillard Marc" <mdemaillard AT gmail.com>]

Bonsoir,

Une mouture de rms-lisp.fr.html : à relire donc.

Cordialement,
Marc

2008/1/23 Cédric Corazza <cedric.corazza AT wanadoo.fr >:

de Maillard Marc a écrit :

> Bonsoir,
> Je me lance dans rms-lisp.html.

Bonsoir,
C'est noté. Pour info, je ne serai pas disponible cette fin de semaine.

Cédric




--
Pour toutes informations sur le fonctionnement du groupe
de travail et de la liste de diffusion :
<url:http://www.april.org/groupes/gnufr/work/>

Pour vous desinscrire, tapez la commande sous GNU/Linux :
echo sig trad-gnu | mail sympa AT april.org


Administration : http://www.april.org/wws/

Mes expériences avec Lisp et le Développement de GNU Emacs - Project GNU -
Fondation pour le logiciel libre (FSF)

Mes expériences avec Lisp et le Développement de GNU Emacs

(Transcription du discours de Richard Stallman, 28 Oct 2002, à la conférence internationale Lisp)

Comme aucun de mes discours habituels n'a à voir avec Lisp, aucun ne serait approprié pour aujourd'hui. Donc je vais improviser. Comme j'ai fait suffisement de choses dans ma carrière en liaison avec Lisp, je devrais être capable de raconter quelque chose d'intéressant.

Ma première expérience avec Lisp a été de lire le manuel Lisp 1.5 au lycée. C'est à ce moment là que l'idée m'a frappé de plein fouet : qu'il puisse y avoir un langage informatique comme cela. La première fois que j'ai eu la chance de faire quelque chose avec Lisp fut quand je suis arrivé à Harvard et que j'ai écrit un interpréteur Lisp pour le PDP-11. C'était une toute petite machine, avec quelque chose comme 8k de mémoire, et j'ai réussi à écrire l'interpréteur en un millier de lignes. Cela m'a laissé un peu de place pour quelques données. Tout cela était avant que je ne vois ce qu'est du vrai logiciel, qui exécute un vrai travail système.

J'ai commencé à travailler sur une vrai implémentation de Lisp avec JonL White après avoir débuté au MIT. J'ai été engagé au laboratoire d'intelligence artificielle non pas par JonL, mais par Russ Noftsker, ce qui est plutôt ironique vu ce qui c'est passé par la suite : il a vraiment du regretter ce jour là.

Pendant les années 70, avant que ma vie ne soit politisée par des évènements horribles, je me contentais de faire une extension après l'autre pour des programmes variés, et la plupart d'entre eux n'avaient rien à voir avec Lisp. Mais, au fur et à mesure, j'ai écris un éditeur de texte, Emacs. L'idée intéressante à propos d'Emacs était qu'il possédait un langage de programmation, et que les commandes d'édition de l'utilisateur seraient écrites dans ce langage de programmation interprété, de telle sorte que vous pouviez charger de nouvelles commandes dans votre éditeur pendant que vous éditiez. Vous pouviez éditer les programmes que vous utilisiez et continuer à éditer avec eux. Donc, nous avions un système qui était utile à autre chose qu'à programmer, et que vous pouviez programmer pendant que vous l'utilisiez. Je ne sais pas si c'était le premier programme à le faire, mais c'était certainement le premier éditeur comme ça.

L'idée de construire des programmes gigantesques et compliqués, à utiliser dans notre propre édition, et ensuite de les échanger avec d'autres personnes, a alimenté l'esprit de coopération sans contrainte (free wheeling cooperation) que nous avions au labo d'AI à ce moment là. L'idée était que vous pouviez donner une copie de n'importe quel programme que vous aviez à celui qui en voulait une copie. Nous partagions les programmes avec qui que soit qui voulait les utiliser, ils étaient de la connaissance, du savoir humain. Donc même s'il n'y avait pas de pensée politique organisée liée à la manière dont nous partagions du logiciel pour concevoir Emacs, je suis convaincu qu'il y avait une connection entre eux, peut-être une connection inconsciente. Je pense que c'est la nature de notre façon de vivre au labo d'AI qui à mené à Emacs et l'a fait devenir ce qu'il était.

L'Emacs original ne contenait pas de Lisp. Le langage de bas-niveau, le langage non interprété, était de l'assembleur PDP-10. L'interpréteur dans lequel nous écrivions n'était en fait pas écrit pour Emacs, il était écrit pour TECO. C'était notre éditeur de texte, et était un langage de programmation extrêmement laid, le plus laid qu'il puisse exister. La raison en était qu'il n'était pas conçu pour être un langage de programmation, mais pour être un langage d'édition et de commande. Il y avait des commandes comme '5l', signifiant 'avance de 5 lignes', ou bien 'i' puis une chaîne de caractère et Echap pour insérer cette chaîne. Vous pouviez taper une chaîne de caractère qui était une série de commandes, ce qui s'appelait une chaîne de commande. Vous la terminiez par Echap Echap, et elle était exécutée.

Eh bien, certaines personnes voulait étendre ce langage avec des méthodes de programmation, donc ils en ont ajouté quelques unes. Par exemple, l'une des premières fut une structure de boucle, qui était < >. Vous pouviez les placer autour de quelque chose, et cette chose s'exécutait en boucle. Il y avait d'autre commandes cryptiques qui pouvaient être utilisées pour sortir de la boucle en fonction de conditions. Pour faire Emacs, nous (7) avons ajouté des méthodes pour avoir des sous-routines avec des noms. Avant cela, c'était une sorte de Basic, et les sous-routines pouvaient uniquement avoir une seule lettre pour nom. Il était difficile de programmer des gros programmes avec, donc nous avons ajouté du code pour qu'elles puissent avoir des noms plus long. En fait, il y avait des méthodes plutôt sophistiquées : je pense que Lisp a hérité sa méthode unwind-protect de TECO.

Nous avons commencé à intégrer des méthodes plutôt sophistiquées, toutes avec la syntaxe la plus horrible que vous pouviez vous représenter, et cela marchait : les gens étaient capables d'écrire des programmes avec en tout cas. La leçon évidente était qu'un langage comme TECO, qui n'était pas conçu pour programmer, était la mauvaise direction. Le langage sur lequel vous construisez vos extensions ne devrait pas être vu en tant que langage de programmation après coup, il devrait être conçu en tant que langage de programmation. En fait, nous avons découvert que le meilleur langage de programmation pour faire cela était Lisp.

C'est Bernie Greenberg, qui a découvert qu'il l'était (5). Il a écrit une version d'Emacs en Multics MacLisp, et il écrivait ses commandes en MacLisp de façon très directe. L'éditeur lui-même était entièrement écrit en Lisp. Emacs Multics fut un grand succès : programmer de nouvelles commandes d'édition était si pratique que même les secrétaires dans son bureau ont commencé à apprendre à s'en servir. Elles utilisaient un manuel que quelqu'un avait écrit qui montrait comment étendre Emacs, mais qui ne disait pas qu'il s'agissait de programmation. Donc les secrétaires, qui croyaient qu'elles ne pouvaient pas programmer, n'ont pas été effrayées. Elles ont lu le manuel, découvert qu'elles pouvaient faire des choses utiles, et ont appris à programmer.

Donc Bernie à vu qu'une application (un programme qui fait quelque chose d'utile pour vous) qui avait Lisp à l'intérieur et que vous pouviez étendre en réécrivant les programmes Lisps, était réellement une très bonne manière pour les gens d'apprendre à programmer. Cela leur donnait la chance d'écrire de petit programmes qui leurs étaient utiles, ce qui est impossible dans la plupart des situations. Ils peuvent ainsi s'encourager (au stade le plus difficile) quand ils ne croient pas qu'ils puissent programmer, jusqu'à ce qu'ils arrivent au point où ils sont devenus programmeurs.

A ce moment là, les gens ont commencé à se demander comment ils pouvaient obtenir quelque chose de ce genre sur une plate-forme sur laquelle ils ne disposaient pas de l'implémentation des services complets de Lisp. Multics MacLisp avait un compilateur aussi bien qu'un interpréteur (c'était un système Lisp complet) mais les gens voulaient implémenter quelque chose comme ça sur d'autres systèmes où ils n'avaient pas encore de compilateur Lisp. Car sans avoir le compilateur Lisp vous ne pouviez écrire l'éditeur entier en Lisp : ce serait trop lent, spécialement l'affichage, s'il fallait faire tourner du Lisp interprété. Donc nous avons développé une technique hybride. L'idée était d'écrire un interpréteur Lisp et les parties bas niveau de l'éditeur ensemble, de telle sorte que des morceaux de l'éditeur étaient des méthodes intégrées Lisp. C'étaient toutes les parties dont nous avions le sentiment qu'il fallait les optimiser. C'est une technique que nous avions déjà consciemment pratiqué dans l'Emacs original, puisqu'il y avait certaines fonctionnalité de relativement haut-niveau que nous ré-implémentions en langage machine, les transformant en primitives TECO. Par exemple, il y avait une primitive TECO pour remplir un paragraphe (en fait, pour faire le gros du travail de remplir un paragraphe, parce que certaines des parties du travail les moins exigentes en temps étaient faites à un niveau supérieur par un programme TECO). Vous pouviez faire tout le travail en écrivant un programme TECO, mais c'était trop lent, donc nous l'avons optimisé en en mettant une partie en langage machine. Nous avons utilisé la même idée ici (dans la technique hybride), que la grosse partie de l'éditeur serait écrite en Lisp, mais que certaines parties ayant besoin de fonctionner particulièrement rapidement seraient écrites à un niveau inférieur.

C'est pourquoi, quand j'ai écrit ma deuxième implémentation d'Emacs, j'ai suivi le même concept.Le langage de bas niveau n'était plus du langage machine mais du C. C était un bon langage, efficace pour des programmes portables fonctionnant dans un système d'exploitation de type Unix. Il y avait un interpréteur Lisp, mais j'ai implémenté des méthodes pour des travaux d'édition spéciale directement en C - manipuler les piles de l'éditeur, insérer du ‘leading text‘, lire et écrire des fichiers, réafficher la pile à l'écran, gérer les fenêtres de l'éditeur.

Maintenant, ce n'était pas le premier Emacs écrit en C et fonctionnant sous Unix. Le premier a été écrit par James Gosling, et était appelé GosMac. Une chose étrange lui est arrivée. Au début, il semblait être influencé par le même esprit de partage et de coopération que celui de l'Emacs original. J'ai d'abord distribué l'Emacs original aux gens du MIT. Quelqu'un voulait le porter pour le faire fonctionner sur Twenex : il fonctionnait à l'origine sur l'Incompatible Timesharung System que nous utilisions au MIT. Ils l'ont porté sur Twenex, ce qui signifiait qu'il y avait quelques centaines d'installations dans le monde qui pouvait potentiellement l'utiliser. Nous avons commencé à le leur distribuer, avec la règle que ‘vous aviez à renvoyer toutes vos améliorations‘ pour que tout le onde en bénéficie. Personne n'a jamais essayé de surveiller son application, mais à ce que j'en sais les gens ont coopéré.

Gosling avait l'air, au début, de participer à cet esprit. Il a écrit dans un manuel qu'il appelait le programme Emacs espérant que d'autres dans la communauté l'améliore jusqu'à ce qu'il soit digne de ce nom. C'est la bonne approche pour créer une communauté : leur demander de se joindre et de participer à améliorer le programme. Mais après cela il a apparemment changé d'esprit, et a vendu le programme à une entreprise.

A ce moment là je travaillait sur le système GNU (un système d'exploitation libre de type Unix que beaucoup de personnes nomment par erreur ‘Linux‘). Il n'y avait pas d'éditeur Emacs libre qui fonctionnait sur Unix. J'avais par contre un ami qui avait participé au développement de l'Emacs de Gosling. Gosling lui avait donné, par mail, la permission de distribuer sa propre version. Il 'a proposé que j'utilise cette version. Puis j'ai découvert que l'Emacs de Gosling n'avait pas réellement de Lisp. Il avait un langage de programmation connu sous le nom de ‘mocklisp‘, qui ressemblait pour la syntaxe à Lisp, mais n'avait pas les structures de données de Lisp. Donc les programmes n'étaient pas des données (data), et des éléments vitaux de Lisp manquaient. Ses structures de données étaient les chaînes de caractères, les nombres et quelques autres choses spécialisées.

J'ai conclu que je ne pouvais pas l'utiliser et que j'avais à tout remplacer, en commençant par écrire un vrai interpréteur Lisp. J'ai progressivement adapté toutes les parties de l'éditeur aux structures de données du vrai Lisp, plutôt qu'à des structures de données ad hoc, rendant les structures de données des parties internes de l'éditeur exposables et manipulables par les programmes Lips des utilisateurs.

L'unique exception était l'affichage. Pendant longtemps, le réaffichage était une sorte d'autre planète. L'éditeur entrait le mot pour réaffichage, et les choses continuaient avec des structures de données très spéciales qui n'étaient pas sures pour le ramassage des messages d'erreurs, pas sures pour les interruptions, et vous ne pouviez lancer aucun programme Lisp pendant ce temps là. Nous avons changé ça depuis : il est maintenant possible de lancer du code Lisp pendant le réaffichage. C'est quelque chose d'assez pratique.

Ce second programme Emacs était du ‘Logiciel Libre‘ dans le sens moderne du terme : il faisait part d'une campagne politique explicite pour libérer le logiciel. L'essence de cette campagne était que n'importe qui devrait être libre de faire les choses que nous faisions au temps du MIT, travailler ensemble sur du logiciel et travailler avec qui que ce soit qui veuille travailler avec nous. C'est la base pour le mouvement du logiciel libre : l'expérience que j'ai eue, la vie que nous avions au Labo d'AI du MIT, de travailler sur du savoir humain, et ne pas être en travers du chemin de qui que ce soit, et de disséminer de plus en plus le savoir humain.

A cette époque, vous pouviez faire un ordinateur dans le même ordre de prix que d'autres non conçus pour Lisp, sauf qu'il ferait fonctionner Lisp beaucoup plus rapidement qu'ils ne le feraient, et avec en plus vérification complète de type (full type checking). Les ordinateurs ordinaires vous forçaient typiquement à choisir entre vitesse d'exécution et bonne vérification de type (typechecking). Donc oui, vous pouviez avoir un compilateur Lisp et faire fonctionner vos programmes rapidement, mais quand ils essayaient de prendre le ‘car‘ d'un nombre, il sortaient des résultats insensés et finalement plantaient au bout d'un moment.

La machine Lisp était capable d'exécuter des instructions presque aussi vite que ces autres machines, mais pour toutes les instructions (une instruction car fait de la vérification de type (typechecking)), donc quand vous essayiez d'obtenir le ‘car‘ d'un nombre dans un programme compilé, vous obteniez immédiatement l'erreur. Nous construisions la machine et avions un système d'exploitation Lisp pour elle. Il était presque entièrement écrit en Lisp, les seules exceptions étant certaines parties écrites dans le micro code. Des gens ont porté de l'intérêt à leur fabrication, ce qui signifie qu'ils allaient lancer une entreprise.

Il y avait deux idées différentes à propos de comment cette société devrait être. Greenblatt voulait lancer ce qu'il appelait une entreprise de ‘hacker‘. Cela signifie qu'il voulait une entreprise dirigée par des hackers et qui fonctionnerait d'une manière favorable aux hackers. Un autre but était de maintenir la culture du labo d'AI (1). Malheureusement, Greenblatt n'avait aucune expérience des affaires, donc d'autres personnes dans le groupe de la machine Lisp ont dit qu'ils doutaient qu'il puisse réussir. Ils pensaient que son plan pour éviter les investissements extérieurs ne marcherait pas.

Pourquoi voulait-il éviter les investissements extérieurs ? Parce que quand une entreprise a des investisseurs extérieurs, ils prennent le contrôle, et ne vous laissent pas avoir le moindre scrupule. Et finalement, si vous avez des scrupules, ils vous remplacent également en tant que directeur.

Donc Greenblatt avait l'idée qu'il trouverait un client prêt à payer en avance pour acheter les composants. Ils construiraient les machines et les livreraient : avec le bénéfice réalisé, ils seraient en mesure d'acheter les composants pour quelques machines de plus, de les vendre, d'acheter des composants pour plus de machines, et caetera et caetera. Les autres personnes dans le groupe ne pensaient pas que cela puisse fonctionner.

DGreenblatt a ensuite recruté Russel Noftsker, la personne qui m'avait engagé, et qui avait entre temps quitté le Labo d'AI et monté une entreprise florissante. Russel passait pour avoir des capacité pour les affaires. Il a démontré cette capacité pour les affaires en disant aux autres membres du groupe : ‘jetons Greenblatt, oublions son idée, et faisons une autre entreprise‘. Poignarder dans le dos, clairement un vrai homme d'affaires. Ces personnes décidèrent qu'elles formeraient une société nommée Symbolics. Ils chercheraient des investissements extérieurs, n'auraient aucun scrupule, et feraient tout leur possible pour gagner.

Mais Greenblatt n'a pas abandonné. Lui et les quelques personnes qui lui étaient restées loyales décidèrent de lancer tout de même Lisp Machines Inc. et de continuer sur leur plan original. Et devinez quoi, ils ont réussi ! Ils ont trouvé leur premier client et ont été payés en avance. Ils ont construit leurs machines et les ont vendues, construit plus de machines et encore plus. Ils ont effectivement réussi alors même qu'ils n'avaient pas l'aide de la plupart des personnes du groupe. Symbolics a aussi eu un départ réussi, donc vous aviez deux entreprises concurrentes de machines Lisp. Quand Symbolics a vu que LMI n'allait pas s'écrouler, ils ont commencé à chercher des moyens de le détruire.

Donc, l'abandon de notre labo fut suivi par une ‘guerre‘ dans notre labo. L'abandon s'est fait quand Symbolics a débauché tous les hackers, à l'exception de moi et des quelques uns qui travaillaient à LMI à temps partiel. Puis ils ont invoqué une règle et éliminé les gens travaillant à temps partiel pour le MIT, les forçant à le quitter entièrement, ce qui m'a laissé seul. Le Labo d'AI était maintenant impuissant. Et le MIT a passé un arrangement absurde avec ces deux entreprises. C'était un contrat entre eux trois dans lequel chaque entreprise licenciait l'utilisation des sources des systèmes de machine Lisp. Ces entreprises étaient forcées de laisser le MIT utiliser leurs modifications. Mais le contrat ne contenait rien disant que le MIT avait le droit de les utiliser dans les systèmes de machine Lisp que les deux entreprises avaient licenciées. Personne ne s'était rendu compte que le groupe de hacker du Labo d'AI avait disparu, mais c'était le cas.

Donc Symbolics à eu une idée (4). Ils ont dis au labo : ‘Nous continuerons à mettre à votre disposition nos modifications du système pour votre utilisation, mais vous ne pouvez les utiliser dans le système de machine Lisp du MIT. A la place, nous vous donnerons accès au système de machine Lisp de Symbolics, et vous pourrez l'utiliser, mais c'est tout ce que vous pourrez faire‘.

Ceci, en pratique, voulait dire qu'ils demandaient que nous choisissions un camp, et utilisions soit la version du système du MIT, soit la version de Symbolics. Quel que soit notre choix cela déterminait à quel système iraient nos améliorations. Si nous travaillions et améliorions la version de Symbolics, nous soutiendrions uniquement Symbolics. Si nous utilisions et améliorions la version MIT du système, nous réaliserions du travail disponible pour les deux entreprises, mais Symbolics verrait que nous soutiendrions LMI puisque nous les aiderions à exister. Donc nous ne pouvions plus rester neutre.

Jusqu'à ce moment, je n'avais pris parti pour aucune des deux entreprises, bien que cela me rendait malheureux de voir ce qui était arrivé à notre communauté et au logiciel. Mais maintenant, Symbolics avait forcé le problème. Donc, dans un effort pour aider à faire continuer Lisp Machines Inc. href="‘#foot-2‘>(2), j'ai commencé à dupliquer toutes les améliorations que Symbolics avait fait au système machine Lisp. J'ai écrit les améliorations équivalentes à neuf moi-même (c'et à dire avec mon propre code).

Au bout d'un moment (3), je suis arrivé à la conclusion que cela irait mieux si je ne regardais même pas leur code. Quand ils annonçaient une version bêta qui donnait les notes de versions, je pouvais voir quelles allaient être les fonctionnalités et les implémenter moi-même. Au moment où ils avaient une vrai version, j'avais la mienne également.

De cette façon, et pendant deux ans, je les ai empêchés d'écraser Lisp Machines Incorporated, et les deux entreprises ont continué d'exister. Mais je ne voulais pas passer des années et des années à punir quelqu'un, uniquement à contrer une entreprise maléfique. J'imagine qu'ils ont été punis assez sévèrement parcequ'ils étaient bloqués avec de la compétition qui n'avait ni l'intention de laisser tomber ni ne risquait de disparaître (6). Entre temps, il était temps de commencer à bâtir une nouvelle communauté pour remplacer l'autre que leurs actions et d'autres avait rayé de la carte.

La communauté Lisp des années 70 n'était pas limitée au Labo d'AI du MIT, et les hackers ne venaient pas tous du MIT. La guerre que Symbolics a lancé fut ce qui anéanti (la communauté au) MIT, mais il y avait d'autres évènements en cours au même moment. Il y avait des gens qui abandonnaient la coopération, et tout cela détruisait la communauté, et il n'an restait pas grand chose.

Après avoir arrêté de punir Symbolics, il a fallu réfléchir à quoi faire ensuite. Il fallait que je fasse un système d'exploitation libre, c'était clair : la seule façon de faire travailler des gens ensemble et de les faire partager était avec un système d'exploitation libre.

Au début, j'ai pensé faire un système basé sur Lisp, mais j'ai réalisé que techniquement ce n'était pas une très bonne idée. Pour avoir quelque chose comme le système machine Lisp, vous aviez besoin de micro code à but spécifique. C'est ce qui rendait possible de faire fonctionner des programmes aussi rapidement que les autres ordinateurs faisaient fonctionner les leurs, en ayant tout de même le bénéfice de la vérification de type (typechecking). Sans cela, vous seriez réduit à quelque chose comme les compilateurs Lisps pour les autres machines. Les programmes seraient plus rapides, mais instables. Maintenant c'est bon si vous faites fonctionner un programme sur un système à partage de temps (timesharing system) : si un programme plante, ce n'est pas un désastre, c'est quelque chose que les programmes font occasionnellement. Mais cela ne le rendait pas bon pour écrire le système d'exploitation de cette façon, donc j'ai rejeté l'idée de faire un système comme la machine Lisp.

J'ai décidé de faire un système d'exploitation de type Unix qui aurait des implémentations Lisp qui fonctionneraient en tant que programmes utilisateurs. Le noyau ne serait pas écrit en Lisp, mais nous aurions Lisp. Donc le développement de ce système d'exploitation, le système d'exploitation GNU, est ce qui m'a amené à écrire GNU Emacs. En faisant cela, j'ai cherché à faire le minimum d'implémentation Lisp possible. La taille des programmes était un soucis énorme.

Il y avait des gens à cette époque, en 1985, qui avaient des machines d'un mega-octet sans mémoire virtuelle. Ils voulaient pouvoir utiliser GNU Emacs. Ce qui signifie qu'il fallait que je garde le programme aussi petit que possible.

Par exemple, à ce moment la seule construction de boucle était ‘while‘, qui était extrêmement simple. Il n'y avait pas de moyen de sortir de cette boucle ‘while‘, vous deviez uniquement (do a catch and a throw), ou tester une variable qui bouclait (that ran the loop). Cela montre à quel point je poussait les choses pour les garder le plus petites possibles. Nous n'avions pas de caar, de cadr et caetera : simplifier au maximum était l'esprit de GNU Emacs, l'esprit de Emacs Lisp, depuis le début.

évidemment les machines sont plus grosses maintenant, et nous ne le faisons plus de cette façon. Nous utilisons caar et cadr et caetera, et nous pourrions intégrer une autre construction de boucle un de ces jours. Nous sommes favorables à l'étendre un peu maintenant, mais nous ne voulons pas l'étendre au niveau du Common Lisp. Une chose que je n'aime pas énormément sont les arguments mot-clefs. Il ne me semblent pas très Lispy : je le fais de temps à autre mais je minimise les fois où je le fais.

Ce n'était pas la fin de l'implication du projet GNU avec Lisp. Plus tard vers 1995, nous pensions à lancer un projet de bureau graphique. Il était clair que pour les programmes du bureau, nous voulions un langage de programmation afin d'en écrire une grande partie et de le rendre facilement extensible, comme l'éditeur. La question était lequel choisir.

A ce moment, TCL était largement mis en avant pour ce genre d'applications. J'avais une très mauvaise opinion de TCL, avant tout parce que ce n'était pas du Lisp. Cela ressemblait un peu à Lisp, mais pas au niveau sémantique, et ce n'est pas aussi propre. Puis quelqu'un m'a montré une publicité dans laquelle Sun essayait de recruter quelqu'un pour travailler sur TCL afin de le rendre ‘de facto langage d'extension standard ‘ mondial. Et j'ai pensé : ‘ nous devons empêcher cela‘. Donc nous avons commencé à rendre Scheme le langage d'extension standard pour GNU. Pas Common Lisp parcequ'il était trop large. L'idée était d'avoir un interpréteur Scheme conçu pour être lié à des applications de la même manière que TCL était lié à d'autres applications. Nous allions donc recommander qu'il soit le paquet pour extension préféré pour tous les programmes GNU.

Il y a un bénéfice intéressant à utiliser un langage si puissant en tant que version de Lisp pour votre langage d'extension primaire. Vous pouvez implémenter d'autres langages en les traduisant dans votre langage primaire. Si votre langage primaire était TCL, vous ne pourriez implémenter facilement Lisp en le traduisant en TCL. Mais si votre langage primaire est Lisp, il n'est pas difficile d'implémenter d'autre choses en les traduisant. Notre idée était que si chaque application extensible acceptait Scheme, vous pourriez écrire une implémentation de TCL ou de Python ou de Perl en Scheme qui traduirait ce programme en Scheme. Puis vous pourriez charger cela dans n'importe quelle application et la configurer dans votre langage favori, et cela marcherait également avec d'autres configurations.

Tant que l'extensibilité des langages est faible, les utilisateurs doivent uniquement utiliser le langage que vous leur fournissez. Ce qui signifie que les gens qui adorent n'importe quel langage ont besoin de concourir pour le choix des développeurs d'application : ‘s'il vous plaît, développeur d'application, inclus mon langage dans ton application, pas la sienne‘. Puis les autres utilisateurs n'ont plus le choix : quelle que soit l'application qu'ils utilisent elle arrive avec un langage et ils sont limités à ce langage. Mais quand vous avez un langage puissant qui peux implémenter les autres en les traduisant, alors vous donnez aux utilisateurs le choix du langage et vous n'avez plus de guerre des langages du tout. Nous espérons que c'est ce que fera 'Guile', notre interpréteur Scheme. Nous avions une personne travaillant l'été dernier à finir un traducteur de Python vers Scheme. Je ne sais pas s'il est entièrement fini maintenant, mais si quelqu'un est intéressé par ce projet, contactez-moi. Donc c'est notre plan pour le futur.

Je n'ai pas parlé de logiciel libre, mais laissez moi vous dire rapidement un petit peu ce que cela veut dire. Logiciel libre (Free Software) ne se réfère pas à un prix, cela ne veut pas dire que vous l'obtiendrez gratuitement. (Vous pouvez avoir à payer pour une copie, ou bien vous pouvez l'obtenir gratuitement.) Cela signifie que vous êtes libre en tant qu'utilisateur. La chose capitale est que vous êtes libre d'utilisez le programme, libre d'étudier ce qu'il fait, libre de le modifier pour s'adapter à vos besoins, libre de redistribuer des copies aux autres et libre de publier des versions améliorées ou étendues. C'est ce que signifie logiciel libre. Si vous utilisez des logiciels non-libres, vous perdez cette liberté capitale, donc ne le faites jamais.

Le but du projet GNU est de rendre facile pour le gens de rejeter les logiciels dominateurs-d'utilisateurs, piétineurs-de-liberté, non-libres, en mettant à disposition des logiciels libres pour les remplacer. Pour ceux qui n'ont pas le courage moral de rejeter les logiciels non-libres, quand cela signifie quelque inconvénient pratique, nous essayons de donner une alternative gratuite (free : gratuite ou libre ?) pour que vous puissiez vous libérer avec moins de complications et un sacrifice moindre en termes pratiques. Plus le sacrifice est petit, mieux c'est. Nous voulons vous faciliter la vie libre, la coopération.

C'est un problème de faire coopérer pour la liberté. Nous avons l'habitude pour la société de penser à la liberté et à la coopération en tant qu'opposés. Mais elles sont dans le même camp. Avec le logiciel libre vous êtes libres de coopérer avec d'autres personnes et êtes libre de vous aider vous-même. Avec le logiciel non-libre, quelqu'un vous domine et tient les gens divisés. Vous n'êtes pas autorisés à partager avec eux, vous n'êtes pas libres de coopérer avec ou d'aider la société, pas plus que vous n'êtes autorisés à vous aider vous-même. Divisés et impuissant, voilà l'état des utilisateurs de logiciel non libre.

Nous avons produit une variété énorme de logiciels libres. Nous avons fait ce que les gens disaient que nous n'arriverions jamais, nous avons deux systèmes d'exploitations en logiciels libres. Nous avons de nombreuses applications et évidemment avons encore beaucoup à faire. Donc nous avons besoin de votre aide. J'aimerais vous demander d'être volontaire pour le projet GNU, aidez nous à développer le logiciel libre pour plus de travails. Allez voir sur http://www.gnu.org/help pour trouver des suggestions sur la manière de nous aider. Si vous voulez commander des choses, il y a un lien pour cela sur cette page. Si vous voulez lire à propos des questions philosophiques, allez voir dans /philosophy. Si vous cherchez des logiciels libres à utiliser, allez voir dans /directory, qui liste environ 1900 paquets maintenant (ce qui représente une fraction de tout le logiciel libre existant). S'il vous plaît, écrivez-en plus et contribuez. Mon livre d'essais, ‘Free Software and Free Society‘ (Logiciel libre et société libre), est en vente et peut être acheté sur www.gnu.org. Happy hacking! (Codez joyeusement !)

(1) Le plan de Greenblatt, à ce que j'en ai compris, était d'engager les gens du laboratoire à temps partiel, afin qu'ils puissent continuer à travailler au Labo d'AI. Symbolics les a engagé à temps plein à la place, donc ils ont arrêté de travailler au MIT

(2)Ce n'était pas que le sort de LMI m'interesse particulièrement, mais plutôt je ne voulais pas laisser Symbolics gagner par son aggression contre le Labo d'AI.

(3) Cette phrase a été malinterprétée selon quoi je n'aurais jamais, jamais jeté l'oeil sur le code Symbolics. En réalité je l'ai fait.

Le code source de Symbolics était disponible au MIT, où j'étais en droit de le lire, et au début c'est ainsi que je me suis rendu compte de leur changements. Mais cela signifie que j'avais l'effort supplémentaire de résoudre chaque problème différement, pour éviter de copier le code Symbolics. Après un moment, j'ai conclus que c'était mieux de ne pas y regarder du tout. De cette façon je pouvais écrire le code de la meilleure façon, sans me soucier de ce qui était dans le code Symbolics.

(4)L'arrière pensée de ce plan, que je n'ai pas explicité dans le discours, est que durant cette période initiale les ex hackers du labo d'AI, que ce soit chez Symbolics ou chez LMI, ont continué à faire contribuer leurs modifications au système machine Lisp du MIT, bien que le contrat ne l'exigeait pas. Le plan de Symbolics était de briser cette coopération unilatéralement.

(5) Bernie Greenberg dit que l'implémentation de Dan Weinberg d'Emacs pour la machine Lisp est arrivée avant l'implémentation de Greenberg pour Multics. Je m'excuse pour cette erreur.

(6) Symbolics a à un moment protesté au MIT que mon travail, en contrant leur plan, avait couté à Symbolics un million de dollars.

(7)Guy Steele a conçu la bibliothèque de commande de l'Emacs symmétrique original, puis lui et moi avons commencé à implémenter Emacs (par dessus TECO), mais après une longue session de développement conjointe, Steele a commencé à s'éloigner, donc j'ai fini Emacs. D'autres incluant particulièrement Eugene C. Cicciarelli et Mike McMahon ont par la suite contribué de manière substantielle.

Pour les questions et requêtes relatives à la FSF & GNU : gnu AT gnu.org. Autres moyens pour contacter la FSF. Merci d'envoyer des commentaires sur cette page web à webmasters AT gnu.org, envoyer une autre question à gnu AT gnu.org.

Copyright © 1997, 1998, 1999, 2004 Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110, USA

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

La reproduction exacte et la distribution intégrale de cet article est permise sur n'importe quel support d'archivage, pourvu que cette notice soit préservée.

Dernière mise-à-jour : $Date: 2006/11/06 09:35:15 $ $Author: taz $

Traduction : Marc de Maillard Révision : trad-gnu AT april.org

Traductions de cette page

• Català
• English
• Deutsch
• Español
• Français
• 日本語
• 한국어
• Polski
• Română
• Русский
• Српски