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

---

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 suffisamment de choses dans ma carrière en relation 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 8 kilooctets 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, c'était avant que je ne voie ce qu'est un vrai logiciel, qui fait de vraies tâches sur un système.

J'ai commencé à travailler sur une vraie implémentation de Lisp avec JonL White après avoir débuté au MIT. J'ai été engagé au laboratoire d'intelligence artificielle (IA) non pas par JonL, mais par Russ Noftsker, ce qui est plutôt ironique vu ce qui s'est passé par la suite ; il a vraiment dû 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, la plupart d'entre eux n'ayant rien à voir avec Lisp. Mais en cours de route j'ai écrit 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 étaient écrites dans ce langage de programmation interprété, de telle sorte qu'on pouvait charger de nouvelles commandes dans l'éditeur tout en éditant. On pouvait éditer les programmes qu'on utilisait tout en continuant à s'en servir pour l'édition. Donc, nous avions un système qui était utile à autre chose qu'à programmer et qu'on pouvait programmer pendant qu'on l'utilisait. 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 pour nous en servir dans notre propre travail d'édition, et ensuite de les échanger avec d'autres personnes, a alimenté l'esprit de coopération sans contrainte que nous avions au labo d'IA à ce moment-là. L'idée première était qu'on pouvait donner une copie de n'importe quel programme qu'on possédait à qui en voulait une. Nous partagions les programmes avec 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 connexion, peut-être une connexion inconsciente. Je pense que c'est la nature de notre façon de vivre au labo d'IA qui a 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 c'était un langage de programmation extrêmement laid, le plus laid qui puisse exister. En effet, il n'était pas conçu comme langage de programmation, mais comme langage d'édition et de commande. Il y avait des commandes comme 5l, qui signifiait « avance de 5 lignes », ou bien i puis une chaîne de caractère et Échap pour insérer cette chaîne. Vous pouviez taper une chaîne de caractères qui était une série de commandes, ce qui s'appelait une chaîne de commande. Vous la terminiez par Échap Échap, et elle était exécutée.

Certaines personnes voulaient étendre ce langage avec des méthodes de programmation. Elles en ont donc ajouté quelques-unes. Par exemple, l'une des premières fut une structure de boucle, qui était < >. Vous pouviez placer ces chevrons autour de quelque chose, et cette chose s'exécutait en boucle. Il y avait d'autres commandes cryptiques qu'on pouvait utiliser pour sortir de la boucle si une condition était vérifiée. Pour faire Emacs, nous [1] avons ajouté des méthodes pour avoir des sous-programmes avec des noms. Avant cela, c'était une sorte de Basic, et le nom des sous-programmes ne pouvaient avoir qu'une seule lettre. Il était difficile de faire de gros programmes avec. Nous avons donc ajouté du code pour qu'ils 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 puissiez imaginer, et cela marchait ; en tout cas, les gens étaient capables d'écrire des programmes avec. La leçon évidente était qu'un langage comme TECO, qui n'a pas été conçu pour programmer, menait à une impasse. Un langage sur lequel on construit des extensions ne doit pas être vu comme langage de programmation après coup, il doit être conçu comme langage de programmation. En fait, nous avons découvert que le mieux adapté à cet usage était Lisp.

C'est Bernie Greenberg qui l'a découvert [2]. Il a écrit une version d'Emacs avec le MacLisp de Multics ; il écrivait ses commandes en MacLisp de façon très simple. L'éditeur lui-même était entièrement écrit en Lisp. L'Emacs de Multics a été un grand succès : programmer de nouvelles commandes d'édition était si pratique que même les secrétaires de son service s'y sont mises. Elles se servaient d'un manuel que quelqu'un avait écrit pour montrer comment étendre Emacs, sans dire qu'il s'agissait de programmation. Donc les secrétaires, qui croyaient être incapables de programmer, n'ont pas eu peur d'essayer. Elles ont lu le manuel, découvert qu'elles pouvaient faire des choses utiles, et ont appris à programmer.

Bernie a vu ainsi qu'une application (un programme qui fait quelque chose d'utile pour vous) contenant Lisp, qu'on pouvait étendre en réécrivant les programmes Lisp, était vraiment une très bonne manière pour les gens d'apprendre à programmer. Cela leur donnait l'occasion d'écrire de petits programmes qui leur étaient utiles, ce qui est impossible dans la plupart des situations. L'utilité pratique qu'ils en retiraient leur servait d'encouragement (au stade le plus difficile) quand ils ne croyaient pas pouvoir programmer, jusqu'à ce qu'ils en arrivent au point où ils étaient devenus programmeurs.

À ce moment-là, les gens ont commencé à se demander comment ils pouvaient obtenir quelque chose de ce genre sur une plateforme sur laquelle ils ne disposaient pas de l'implémentation des services complets de Lisp. Le MacLisp de Multics 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ù il n'y avait pas encore de compilateur Lisp. Car sans compilateur Lisp on ne pouvait écrire l'éditeur entier en Lisp : cela aurait été trop lent, en particulier l'affichage, s'il avait fallu faire tourner du Lisp interprété. Donc nous avons développé une technique hybride. L'idée était d'écrire ensemble l'interpréteur Lisp et les parties bas niveau de l'éditeur, de telle sorte que certaines parties de l'éditeur soient des méthodes intégrées Lisp. Ces parties étaient celles dont nous pensions qu'elles avaient besoin d'être optimisées. C'est une technique que nous avions déjà consciemment pratiquée dans l'Emacs original, puisqu'il y avait certaines fonctionnalités 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 exigeantes en temps étaient faites à un niveau supérieur par un programme TECO). On aurait pu 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. C'est cette idée que nous avons utilisée dans la technique hybride : la plus grosse partie de l'éditeur serait écrite en Lisp, mais certaines parties ayant besoin d'une vitesse d'exécution particulièrement rapide seraient écrites à un niveau inférieur.

Par conséquent, j'ai suivi le même concept pour écrire ma deuxième implémentation d'Emacs. 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 les tâches spéciales d'édition directement en C : manipuler les piles de l'éditeur, insérer des interlignes, lire et écrire des fichiers, réafficher la pile à l'écran, gérer les fenêtres de l'éditeur.

Cela dit, ce n'était pas le premier Emacs écrit en C et fonctionnant sous Unix. Le premier a été écrit par James Gosling et s'appelait GosMac. Une chose étrange est arrivée à Gosling. 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 sur Twenex – il fonctionnait à l'origine sur l'Incompatible Timesharing System ^a 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 pouvaient éventuellement l'utiliser. Nous avons commencé à le leur distribuer, en posant comme règle que « vous deviez renvoyer toutes vos améliorations » pour que tout le monde en bénéficie. Personne n'a jamais essayé de faire appliquer cette règle, mais autant que je sache les gens coopéraient effectivement.

Au début, Gosling avait vraiment l'air de collaborer dans cet esprit. Il a écrit dans un manuel qu'il appelait le programme « Emacs » en espérant que d'autres dans la communauté l'amélioreraient jusqu'à ce qu'il soit digne de ce nom. C'est la bonne approche pour créer une communauté : demander aux gens de se joindre à vous pour participer à l'amélioration du programme. Mais après cela il a apparemment changé d'état d'esprit et vendu le programme à une entreprise.

À ce moment-là, je travaillais sur le système GNU (un système d'exploitation libre de type Unix que beaucoup de gens nomment par erreur « Linux »). Il n'y avait pas d'éditeur Emacs libre fonctionnant sur Unix. J'avais en revanche un ami qui avait participé au développement de l'Emacs de Gosling. Gosling lui avait donné, par courriel, la permission de distribuer sa propre version. Il m'a proposé d'utiliser 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 ses structures de données. Donc les programmes n'étaient pas des données 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'en ai conclu que je ne pouvais pas l'utiliser et qu'il me fallait tout reprendre à zéro, à commencer par l'écriture d'un véritable 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, de manière à permettre aux programmes Lisp des utilisateurs d'accéder aux structures de données des parties internes de l'éditeur pour les manipuler.

L'unique exception était le réaffichage. Pendant longtemps, le réaffichage a été une sorte d'autre planète. L'éditeur arrivait sur cette planète, et les choses continuaient avec des structures de données très spéciales qui pouvaient être corrompues par le « ramasse-miette »,^b ou par les interruptions, et vous ne pouviez exécuter aucun programme Lisp pendant ce temps-là. Nous avons changé ça depuis ; il est maintenant possible d'exécuter du code Lisp pendant le réaffichage. C'est quelque chose de très pratique.

Ce second programme Emacs était du « logiciel libre » dans le sens moderne du terme ; il faisait partie d'une campagne politique explicite pour libérer le logiciel. L'essence de cette campagne était que chacun devait être libre de faire les choses que nous faisions au temps du MIT, travailler ensemble sur du logiciel et travailler avec qui voulait travailler avec nous. C'est la base du mouvement du logiciel libre – l'expérience que j'ai eue, la vie que j'ai vécue au labo d'IA du MIT : travailler sur le savoir de l'humanité, sans empêcher qui que ce soit de le réutiliser et de le disséminer.

À cette époque, on pouvait fabriquer un ordinateur dans le même ordre de prix que d'autres qui n'étaient pas conçus pour Lisp, à part qu'il faisait fonctionner Lisp beaucoup plus rapidement qu'eux, avec en plus une vérification complète de type. Les ordinateurs ordinaires vous forçaient typiquement à choisir entre vitesse d'exécution et bonne vérification de type. Donc oui, vous pouviez avoir un compilateur Lisp et faire fonctionner vos programmes rapidement, mais quand ils essayaient d'exécuter car sur un nombre, ils sortaient des résultats insensés et finissaient par planter au bout d'un moment.

La machine Lisp était capable d'exécuter des instructions presque aussi vite que ces autres machines, mais à chaque instruction une instruction car faisait une vérification de type ; par conséquent, lorsque vous essayiez d'obtenir le car d'un nombre dans un programme compilé, vous obteniez immédiatement une erreur. Nous avons construit la machine et fait un système d'exploitation Lisp pour elle. Il était presque entièrement écrit en Lisp, à la seule exception des parties écrites dans le microcode. Certaines personnes ont porté de l'intérêt à la fabrication de la machine Lisp, ce qui voulait dire qu'elles allaient lancer une entreprise.

Il y avait deux conceptions différentes du type de société que ça devait ê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. Elle aurait également pour but de maintenir la culture du labo d'IA [3]. Malheureusement, comme Greenblatt n'avait aucune expérience des affaires, d'autres personnes du groupe de la machine Lisp ont émis des doutes sur ses chances de réussite. Elles pensaient que son plan pour éviter les investissements extérieurs ne marcherait pas.

Pourquoi voulait-il éviter les investissements extérieurs ? Parce que, lorsqu'une entreprise a des investisseurs extérieurs, ils prennent le contrôle et ne vous laissent pas avoir le moindre scrupule. Et si vous finissez par avoir des scrupules, ils vous remplacent également à la direction.

Greenblatt a donc eu l'idée de chercher un client prêt à payer d'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, etc., etc. Les autres personnes du groupe ne pensaient pas que cela puisse fonctionner.

Greenblatt a ensuite recruté Russel Noftsker, la personne qui m'avait engagé, et qui avait entre-temps quitté le labo d'IA pour monter une entreprise florissante. Russel passait pour avoir des capacités pour les affaires. Il l'a démontré en disant aux autres membres du groupe : « Jetons Greenblatt, oublions son idée et créons une autre entreprise. » Poignarder dans le dos… un véritable homme d'affaires en effet. Ces personnes ont décidé de former une société nommée Symbolics. Elles 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 ont décidé de lancer tout de même Lisp Machines Inc. et de poursuivre leur projet initial. Et devinez quoi, ils ont réussi ! Ils ont trouvé leur premier client et ont été payés d'avance. Ils ont construit leurs machines, les ont vendues, et ont construit de plus en plus de machines. Ils ont effectivement réussi alors même qu'ils n'avaient pas l'aide de la plupart des personnes du groupe. Symbolics a eu un bon départ également ; il y avait donc deux entreprises concurrentes de machines Lisp. Quand Symbolics a vu que LMI n'allait pas s'écrouler, ils ont commencé à chercher des moyens de la détruire.

Il y a donc eu l'abandon de notre labo, 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 de quelques autres qui travaillaient chez LMI à temps partiel. Puis, pour éliminer les gens qui travaillaient à temps partiel pour le MIT, ils ont invoqué une règle qui les a forcés à le quitter complètement, ce qui m'a laissé seul. Le labo d'IA é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 donnait des licences pour utiliser les sources des systèmes de machine Lisp. Ces entreprises étaient obligé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 pour lesquels les deux entreprises lui avaient donné des licences. Personne n'avait imaginé que le groupe de hackers du labo d'IA disparaîtrait, mais ce fut le cas.

Les gens de Symbolics ont trouvé une combine [4]. Ils ont dit au labo : « Nous continuerons à mettre à votre disposition nos modifications du système pour votre usage, mais vous ne pourrez pas les installer dans le système de machine Lisp du MIT. À la place, nous vous donnerons accès à celui de Symbolics et vous pourrez le faire fonctionner, mais c'est tout ce que vous pourrez faire. »

En pratique, cela voulait dire qu'ils nous obligeaient à choisir un camp : utiliser la version du MIT, ou la version de Symbolics. Quel que soit notre choix, cela déterminait à quel système iraient nos améliorations. Si nous travaillions sur la version de Symbolics pour l'améliorer, nous soutiendrions uniquement Symbolics. Si nous utilisions la version MIT du système, nos améliorations seraient à la disposition des deux entreprises, mais Symbolics verrait que nous soutenions LMI puisque nous les aidions à exister. Donc nous ne pouvions plus rester neutres.

Jusque-là, je n'avais pris parti pour aucune des deux entreprises, bien que cela me rendît malheureux de voir ce qui était arrivé à notre communauté et au logiciel. Mais maintenant, Symbolics m'avait forcé la main. Alors, pour essayer d'aider LMI à poursuivre son activité [5], j'ai commencé à dupliquer toutes les améliorations que Symbolics avait faites au système de machine Lisp. Je réécrivais des améliorations équivalentes moi-même (c'est-à-dire avec mon propre code).

Au bout d'un moment [6], je suis arrivé à la conclusion que cela irait mieux si je ne regardais même pas leur code. Dans les annonces de versions bêta qui donnaient les notes de version, je pouvais voir quelles allaient être les fonctionnalités et les implémenter moi-même. Au moment où ils avaient une version publiable, j'avais la mienne également.

De cette façon, et pendant deux ans, je les ai empêchés d'écraser LMI et les deux entreprises ont continué d'exister. Mais je ne voulais pas passer des années et des années à punir quelqu'un, dans le seul but de contrer une mauvaise action. J'imagine qu'ils avaient été assez punis parce qu'ils étaient coincés avec de la concurrence qui n'allait pas laisser tomber ni disparaître [7]. De toute manière, il était temps de commencer à bâtir une nouvelle communauté pour remplacer celle que leurs actions, ainsi que d'autres, avaient rayée de la carte.

La communauté Lisp des années 70 ne se limitait pas au labo d'IA du MIT et les hackers n'étaient pas tous au MIT. La guerre lancée par Symbolics est ce qui a déclenché la disparition du groupe du 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 ; tout cela a détruit la communauté et il n'en est pas resté grand-chose.

Après avoir arrêté de punir Symbolics, il m'a fallu réfléchir à la suite. 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 d'avoir 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 de la machine Lisp, on avait besoin de microcode à but spécifique. C'est ce qui permettait d'exécuter des programmes aussi rapidement que les autres ordinateurs exécutaient les leurs, en ayant tout de même le bénéfice de la vérification de type. Sans cela, on en était réduit à quelque chose comme les compilateurs Lisp pour les autres machines. Les programmes étaient plus rapides, mais instables. Ça va bien si on exécute un programme sur un système en temps partagé ; si un programme plante, ce n'est pas un désastre, c'est quelque chose que les programmes font occasionnellement. Mais cela ne convenait pas pour l'écriture d'un système d'exploitation ; j'ai donc rejeté l'idée de prendre comme modèle le système comme la machine Lisp.

Au lieu de ça, j'ai décidé de faire un système d'exploitation de type Unix qui aurait des implémentations Lisp fonctionnant en tant que programmes utilisateur. Le noyau ne serait pas écrit en Lisp, mais nous aurions Lisp. Le développement de ce système d'exploitation, le système d'exploitation GNU, est ce qui m'a amené à écrire GNU Emacs. Ce faisant, j'ai cherché à faire le strict minimum d'implémentation Lisp. La taille des programmes était un souci énorme.

Il y avait des gens à cette époque, en 1985, qui avaient des machines d'un mégaoctet sans mémoire virtuelle. Ils voulaient pouvoir utiliser GNU Emacs. Cela voulait dire que je devais garder le programme aussi réduit que possible.

Par exemple, à ce moment-là, la seule construction de boucle était while, et elle était extrêmement simple. Il n'existait aucun moyen de sortir de cette boucle while ; vous ne pouviez faire qu'un catch et un throw, ou tester une variable dans la boucle. Cela montre à quel point j'essayais de réduire le programme. Nous n'avions pas de caar, de cadr, etc. ; simplifier au maximum était l'esprit de GNU Emacs, l'esprit du Lisp d'Emacs, depuis l'origine.

Évidemment les machines sont plus grosses maintenant et nous ne travaillons plus de cette façon. Nous utilisons caar et cadr, etc., et nous pourrions intégrer une autre construction de boucle un de ces jours. Nous avons envie de l'étendre un peu maintenant, mais nous ne voulons pas l'étendre au niveau du Common Lisp. Il m'est arrivé une fois d'implémenter le Common Lisp sur la machine Lisp, mais je n'en ai pas été vraiment satisfait. Ce que je n'aime pas trop, ce sont les arguments mots-clefs [8]. Ils ne me semblent pas très « Lisp » ; je le fais de temps à autre, mais le moins possible.

L'implication du projet GNU avec Lisp ne s'est pas arrêtée là. 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 qui permette d'en écrire une grande partie et de le rendre facilement extensible, comme l'éditeur. La question était lequel choisir.

À ce moment-là, 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'était pas aussi propre. Puis quelqu'un m'a montré une publicité dans laquelle Sun essayait de recruter quelqu'un pour travailler sur TCL afin d'en faire le « langage d'extension standard de facto » au niveau mondial. Et j'ai pensé : « Nous devons empêcher cela. » C'est ainsi que nous avons commencé à faire de Scheme le langage d'extension standard pour GNU. Pas Common Lisp parce qu'il était trop gros. L'idée était d'avoir un interpréteur Scheme conçu pour être lié à des applications à la manière de TCL. Nous recommanderions ensuite de donner la préférence à Scheme pour les extensions à tous les programmes GNU.

Il y a un avantage intéressant à utiliser comme langage d'extension primaire un langage aussi puissant qu'une version de Lisp. On peut implémenter d'autres langages en les traduisant en langage primaire. Si le langage primaire est TCL, on ne peut pas implémenter facilement Lisp en le traduisant en TCL. Mais si le langage primaire est Lisp, il n'est pas difficile d'implémenter d'autres choses en les traduisant. Nous sommes partis de l'idée que si chaque application extensible était compatible avec Scheme, on pourrait écrire une implémentation de TCL, Python ou Perl en Scheme, qui traduirait ce programme en Scheme. Puis on pourrait 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 utiliser uniquement le langage qu'on leur fournit. Ce qui signifie que les gens qui préfèrent un langage particulier doivent concourir pour le choix des développeurs d'application : « S'il vous plaît, monsieur le développeur d'applications, mettez mon langage dans votre application, pas le sien. » Ensuite, 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 peut implémenter les autres en les traduisant, alors vous donnez le choix aux utilisateurs et vous éliminez la guerre des langages. Nous espérons que c'est ce que fera « Guile », notre interpréteur Scheme. Nous avions une personne l'été dernier qui travaillait à terminer 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. Voilà donc notre projet pour l'avenir.

Je n'ai pas parlé de logiciel libre, mais laissez-moi vous dire rapidement un petit peu de ce que cela signifie. « Logiciel libre » ne se réfère pas au prix, cela ne veut pas dire que vous l'obtiendrez gratuitement (vous pouvez avoir à payer les copies, ou bien vous pouvez les obtenir gratuitement).^c Cela signifie que vous êtes libre en tant qu'utilisateur. L'essentiel, c'est que vous êtes libre d'utiliser le programme, libre d'étudier ce qu'il fait, libre de le modifier pour l'adapter à vos besoins, libre de redistribuer des copies aux autres et libre de publier des versions améliorées ou étendues. Voilà 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 faciliter aux gens le rejet des logiciels non libres qui dominent les utilisateurs, qui piétinent leur liberté, en mettant à leur disposition des logiciels libres pour les remplacer. À 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 libre pour qu'ils puissent se libérer avec moins de complications et un sacrifice moindre en termes pratiques. Plus le sacrifice est petit, mieux c'est. Nous voulons leur faciliter la vie libre, la coopération.

Il s'agit de la liberté de coopérer. Nous avons l'habitude de penser à la liberté et à la coopération avec la société comme si ces notions s'opposaient. Mais ici elles sont dans le même camp. Avec le logiciel libre vous êtes libre de coopérer avec d'autres personnes et vous êtes libre de vous aider vous-même. Avec le logiciel non libre, quelqu'un vous domine et garde les gens divisés. Vous n'êtes pas autorisé à partager avec eux, vous n'êtes pas libre de coopérer avec la société ni de l'aider, pas plus que vous n'êtes autorisé à vous aider vous-même. Divisés et impuissants, 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 à faire ; nous avons deux systèmes d'exploitation constitués de logiciel libre. Nous avons de nombreuses applications, mais évidemment nous avons encore beaucoup à faire. C'est pourquoi nous avons besoin de votre aide. J'aimerais vous demander de faire du bénévolat pour le projet GNU ; aidez-nous à développer le logiciel libre pour qu'il y ait plus d'emplois. Allez voir sur gnu.org/help pour trouver des idées 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 des articles sur des questions philosophiques, allez voir dans /philosophy. Si vous cherchez des logiciels libres, allez voir dans /directory, qui actuellement répertorie environ 1900 logiciels (ce qui représente une fraction de tout les logiciels libres existants). S'il vous plaît, écrivez-en d'autres et offrez-les au projet GNU. Mon livre d'essais, Free Software, Free Society (Logiciel libre, société libre), est en vente et peut être acheté sur www.gnu.org [9]. Happy hacking! (Codez joyeusement !)

Notes

1. ↑ Guy Steele a conçu la bibliothèque symétrique originale de commandes d'Emacs, puis lui et moi avons commencé à implémenter Emacs (au-dessus de TECO), mais après une longue session de développement conjointe, Steele a commencé à s'éloigner. J'ai donc terminé Emacs. D'autres, en particulier Eugene C. Cicciarelli et Mike McMahon, ont par la suite contribué de manière substantielle.
2. ↑ Bernie Greenberg dit que l'implémentation d'Emacs de Dan Weinberg pour la machine Lisp est arrivée avant celle de Greenberg pour Multics. Je lui présente mes excuses pour cette erreur.
3. ↑ Le plan de Greenblatt, d'après ce que j'ai compris, était d'engager les gens du laboratoire à temps partiel afin qu'ils puissent continuer à travailler au labo d'IA. Au lieu de cela, Symbolics les a engagés à temps plein, et donc ils ont arrêté de travailler au MIT.
4. ↑ L'arrière-pensée de ce plan, que je n'ai pas explicitée dans le discours, était que durant cette période initiale les ex-hackers du labo d'IA, que ce soit chez Symbolics ou chez LMI, continuent à apporter leurs modifications au système pour machine Lisp du MIT, bien que le contrat ne l'exige pas. Le plan de Symbolics était de briser cette coopération unilatéralement.
5. ↑ Ce n'est pas que le sort de LMI m'intéressait particulièrement, mais plutôt que je ne voulais pas laisser Symbolics gagner grâce à son agression contre le labo d'IA.
6. ↑ Cette phrase a été mal interprétée ; je n'aurais, paraît-il, jamais, à aucun moment jeté un œil sur le code de Symbolics. En réalité, cette phrase dit que je l'ai bel et bien regardé, au début. 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 leurs modifications.

   Mais cela signifiait que je devais faire un effort particulier pour résoudre chaque problème différemment, de manière à éviter de copier le code de Symbolics. Après un moment, j'ai conclu que c'était mieux de ne pas le 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 de Symbolics.

7. ↑ Symbolics s'est plaint au MIT que mon travail, en contrant leur plan, avait coûté à Symbolics un million de dollars.
8. ↑ Cela ne me dérange pas si une mégafonction très complexe prend des arguments mots-clés. Ce qui me dérange, c'est de les mettre dans des fonctions simples et basiques comme « member ».
9.  ↑En 2021, on peut acheter ce livre sur GNU Press.