English [en]   español [es]   français [fr]   日本語 [ja]   русский [ru]   Shqip [sq]  

Grâce à votre soutien, 2015 marque les 30 ans de la FSF. Au cours des 30 ans à venir, nous voulons défendre encore mieux les droits des utilisateurs de l'informatique. Pour passer à la vitesse supérieure, nous avons donné à notre collecte de fonds un objectif sans précédent : 525 000 $ au 31 janvier. En savoir plus.

525K
26% (137K)
Je participe

L'original de cette page est en anglais.

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

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

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, et la plupart d'entre eux n'avaient 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 à 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. 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 É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.

Eh bien, certaines personnes voulaient é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'autres commandes cryptiques qui pouvaient être utilisées pour sortir de la boucle en fonction de conditions. 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 les sous-programmes pouvaient uniquement avoir une seule lettre pour nom. Il était difficile de faire des gros programmes avec, donc nous avons 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 ; les gens étaient capables d'écrire des programmes avec, en tout cas. La leçon évidente était qu'un langage comme TECO, qui n'a pas été conçu pour programmer, était la mauvaise direction. Le langage sur lequel on construit des 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 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 directe. 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, qui montrait comment étendre Emacs mais ne disait pas 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. C'était toutes les parties dont nous pensions qu'elles avaient besoin d'être optimisées. C'est une technique que nous avions déjà consciemment pratiqué 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.

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 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 était appelé 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 Systema 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, avec la condition que « vous deviez renvoyer toutes vos améliorations » pour que tout le monde en bénéficie. Personne n'a jamais essayé de surveiller son application, mais à ce que j'en sais 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 a 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 les structures de données de Lisp. 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'ai conclu que je ne pouvais pas l'utiliser et que j'avais à tout remplacer, en commençant 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 et de 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é, et ne pas 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 ; donc quand 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, les seules exceptions étant certaines parties écrites dans le microcode. Des gens ont porté de l'intérêt à la fabrication de la machine Lisp, ce qui signifiait qu'ils allaient lancer une entreprise.

Il y avait deux idées différentes sur le 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, 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 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 en tant que directeur.

Donc Greenblatt a 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 et monté une entreprise florissante. Russel passait pour avoir des capacité pour les affaires. Il l'a démontré en disant aux autres membres du groupe : « Jetons Greenblatt, oublions son idée, et faisons une autre entreprise. » Poignarder dans le dos… Un véritable homme d'affaires, c'était clair. Ces personnes ont décidé 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 ont décidé de lancer tout de même Lisp Machines Inc. et de poursuivre leur projet original. 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 aussi eu un départ réussi, donc on avait 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 des quelques-uns qui travaillaient chez LMI à temps partiel. Puis, pour éliminer les gens travaillant à temps partiel pour le MIT, ils ont invoqué une règle qui les a forcés à le quitter entièrement, 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 l'exécuter, 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, dans un effort pour 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. 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 vraie version, 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, uniquement à contrer une mauvaise action. J'imagine qu'ils ont été punis assez sévèrement parce qu'ils étaient bloqué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 l'autre que leurs actions et 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 ne venaient pas tous du 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 à 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 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 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, 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 utilisateur. 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 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'y avait pas de 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 le début.

É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, et je n'en ai pas été vraiment satisfait. Ce que je n'aime pas trop, ce sont les arguments mots-clefs (8). Il ne me semblent pas très « Lisp » ; je le fais de temps à autre mais le moins possible.

L'implication du projet GNU avec Lisp n'était pas terminée. 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.

À 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 » mondial. Et j'ai pensé : « Nous devons empêcher cela. » Donc 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 de la même manière que TCL était lié à d'autres applications. Nous allions donc recommander que ce soit le logiciel utilisé de préférence pour les extensions à tous les programmes GNU.

Il y a un avantage intéressant à utiliser pour votre langage d'extension primaire un langage puissant, tel qu'une version de Lisp. Vous pouvez implémenter d'autres langages en les traduisant dans votre langage primaire. Si votre langage primaire est TCL, vous ne pouvez pas 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'autres choses en les traduisant. Notre idée était que si chaque application extensible acceptait Scheme, on pourrait é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 utiliser uniquement le langage qu'on leur fournit. Ce qui signifie que les gens qui préfèrent un langage particulier ont besoin de concourir pour le choix des développeurs d'application : « S'il vous plaît, monsieur le développeur d'applications, incluez 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 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. 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. La chose capitale 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 elles s'opposaient. Mais 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. Donc nous avons besoin de votre aide. J'aimerais vous demander d'être bénévole pour le projet GNU ; aidez-nous à développer le logiciel libre pour qu'il y ait plus d'emplois. 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 des articles sur des questions philosophiques, allez voir dans /philosophy. Si vous cherchez des logiciels libres, allez voir dans /directory, qui actuellement liste environ 1900 logiciels (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. 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, donc j'ai fini 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, 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 de 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 changements.

    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 ». 

Notes de relecture
  1. Incompatible Timesharing System (ITS) : « système à temps partagé incompatible », conçu par l'équipe du laboratoire d'intelligence artificielle et nommé en opposition avec CTSS (Compatible Time Sharing System), système d'exploitation utilisé précédemment au MIT. 
  2. Garbage collection : mise à jour de tables d'allocation de mémoire (d'après « Le Jargon Français »). 
  3. En anglais, le mot free veut dire libre, mais aussi gratuit, d'où la confusion possible. 

[logo de la FSF]« Notre mission est de préserver, protéger et promouvoir la liberté d'utiliser, étudier, copier, modifier et redistribuer les programmes informatiques, et de défendre les droits des utilisateurs de logiciel libre. »

La Fondation pour le logiciel libre (FSF) est le principal sponsor institutionnel du système d'exploitation GNU. Soutenez GNU et la FSF en achetant des manuels et autres, en adhérant à la FSF en tant que membre associé, ou en faisant un don, soit directement à la FSF, soit via Flattr.

Haut de la page