Mis experiencias con Lisp y el desarrollo de Emacs de GNU

Transcripción de la conferencia pronunciada por Richard Stallman el 28
de octubre de 2002 en el Congreso Internacional de Lisp.

Dado que ninguna de mis charlas habituales tiene nada que ver con Lisp,
ninguna era apropiada para hoy. Así que voy a tener que improvisar. En
cualquier caso, la cantidad de trabajo relacionado con Lisp que he hecho
a lo largo de mi carrera es bastante amplia y debería ser capaz de decir
algo interesante al respecto.

Mi primera experiencia con Lisp tuvo lugar en la escuela secundaria,
cuando leí el manual de Lisp 1.5. Entonces quedé maravillado con la idea
de que pudiera haber un lenguaje de programación así. La primera vez que
tuve la oportunidad de hacer algo en Lisp fue siendo un novato en
Harvard, cuando escribí un intérprete de Lisp para el PDP-11. Era una
máquina muy pequeña, tenía algo así como 8k de memoria, y me las arreglé
para escribir el intérprete en unas mil instrucciones. Eso me dejó sitio
para unos pocos datos. Aquello fue antes de que llegara a conocer cómo
era el software real, el que hacía el trabajo en los sistemas reales.

Fue tras comenzar mi trabajo en el MIT cuando empecé a trabajar en una
implementación real de Lisp con JonL White. No fui contratado para el
Laboratorio de Inteligencia Artificial gracias a JonL, sino por Russ
Noftsker, lo cual es muy irónico teniendo en cuenta lo que vendría
después. Debe de haber lamentado realmente lo ocurrido aquel día.

En la década de los 70, antes de que mi vida se politizara a causa de
terribles sucesos, simplemente me dedicaba a hacer una extensión tras
otra de varios programas, la mayoría de los cuales no tenía nada que ver
con Lisp. Pero, al mismo tiempo, escribí un editor de textos: Emacs. Lo
interesante de Emacs era que no solo incluía un lenguaje de
programación, sino que además los comandos de edición de los que
disponía el usuario estaban escritos en ese mismo lenguaje, de forma que
permitía cargar nuevas instrucciones mientras se estaba editando. Podía
modificar los programas que estaba utilizando e, inmediatamente, editar
utilizando los programas recién modificados. Es decir, teníamos un
sistema que resultaba útil para tratar con texto además de programar, y
que, sin embargo, permitía al usuario programar el editor mientras lo
estaba usando. No sé si era el primer sistema de estas características,
pero, desde luego, sí el primer editor con tales prestaciones.

Esta construcción de programas complejos y gigantescos para usarlos en
las ediciones de textos de uno, y después intercambiarlos con otros,
alimentó el espíritu de cooperación espontánea que teníamos entonces en
el Laboratorio de Inteligencia Artificial. La idea era que podía dar una
copia de cualquier programa que tuviera a quien quisiera una.
Compartíamos programas con todo el que deseara usarlos, eran
conocimiento humano. Así que, a pesar de que no había un pensamiento
político organizado que relacionara la forma en que compartíamos
software con el diseño de Emacs, estoy convencido de que había una
conexión entre ellos, quizá una conexión inconsciente. Creo que fue la
naturaleza de la forma de vida que llevábamos en el Laboratorio de
Inteligencia Artificial lo que condujo a Emacs e hizo de él lo que fue.

El Emacs original no incluía Lisp. Su lenguaje, de más bajo nivel y no
interpretado, era Ensamblador del PDP-10. El intérprete que escribimos
nosotros en realidad no fue escrito para Emacs, sino para TECO. TECO era
nuestro editor de textos y era un lenguaje de programación
extremadamente feo, no podía haber sido más feo. La razón era que no fue
diseñado para ser un lenguaje de programación, sino como un lenguaje de
órdenes y un editor de textos. Había órdenes como 5l, que significaba
«mover cinco líneas», o i seguido de una cadena de caracteres y después
ESC para insertar esa cadena de caracteres. Podría escribir una cadena
de caracteres que fuera una secuencia de órdenes, lo que se llamaba una
cadena de órdenes, terminada con ESC ESC, y sería ejecutada.

Bien. La gente quería extender este lenguaje con elementos útiles para
la programación, así que añadió algunos. Por ejemplo, uno de los
primeros fue una estructura iterativa: < >. Encerrar algo entre estos
signos hacía que se ejecutara en un bucle. Había otras crípticas órdenes
que podían usarse para salir del bucle condicionalmente. Para construir
Emacs, nosotros [1] añadimos mecanismos para tener subrutinas con
nombres. Antes de esto, de forma análoga a lo que ocurre con Basic, los
nombres de las subrutinas sólo podían estar formados por una letra. Con
esta limitación era difícil escribir programas grandes, así que añadimos
código que permitió que pudieran tener nombres más largos. De hecho,
había algunos mecanismos bastante sofisticados; creo que Lisp tomó su
mecanismo unwind-protect, llamémosle, «de-aplicación-abierta», de TECO.

Empezamos a añadir otros mecanismos sofisticados, todos ellos con la
sintaxis más horrible que puedan imaginar, y funcionó, por lo menos la
gente fue capaz de escribir programas extensos con él. La lección obvia
fue que utilizar un lenguaje como TECO, que no había sido diseñado como
lenguaje de programación, fue una opción equivocada. El lenguaje sobre
el que construye sus extensiones no debería ser considerado como un
lenguaje de programación a posteriori, sino que debería ser diseñado
como un lenguaje de programación desde un principio. De hecho,
descubrimos que el mejor lenguaje de programación para ese propósito era
Lisp.

Fue Bernie Greenberg quien descubrió que lo era [2]. Escribió una
versión de Emacs en Multics MacLisp, y programó sus órdenes en MacLisp
de forma sencilla. El propio editor estaba escrito enteramente en Lisp.
Multics Emacs fue un gran éxito: programar nuevas órdenes de edición era
tan práctico que incluso los administrativos empezaron a aprender a
hacerlo en sus oficinas. Utilizaban un manual que mostraba cómo extender
Emacs, pero que no lo llamaba programación, de forma que los
administrativos, que pensaban que no sabían programar, no se asustaran.
Leyeron el manual, descubrieron que podían hacer cosas útiles y
aprendieron a programar.

Así que Bernie vio que una aplicación, un programa creado para
solucionar problemas prácticos, que llevara incorporado LISP, de forma
que pudiera extender las funcionalidades que este trae por defecto,
incluso reescribirlas enteramente, era en sí misma un muy buen medio de
aprender a programar. Le da a uno la oportunidad de ajustar dichas
utilidades a su medida, algo que en la mayoría de las situaciones
simplemente no puede hacer. Lo cual es estimulante en sí mismo y le
mueve a extender las aplicaciones, y transitar así desde el momento más
duro, en el que asume que no es capaz de programar, hasta aquel en que
está, de hecho, programando.

Llegado este punto, la gente se empezó a preguntar cómo podría conseguir
algo así en una plataforma que no poseyera una implementación de Lisp
completa. Multics MacLisp tenía tanto un compilador como un intérprete,
era un sistema Lisp con todas las de la ley, pero la gente quería
implementar algo similar en otros sistemas para los cuales todavía no
había programado un compilador de Lisp. Bien, si no tenía el compilador
de Lisp no podía escribir todo el editor en Lisp: resultaría demasiado
lento, especialmente al refrescar la pantalla, si tenía que ejecutarse
en Lisp interpretado. Así que desarrollamos una técnica híbrida. La idea
era escribir conjuntamente un intérprete de Lisp y los fragmentos de
nivel más bajo del editor, de forma que algunos fragmentos del editor
fueran mecanismos incorporados en el intérprete de Lisp. Estos
fragmentos serían todas aquellas partes que consideráramos que teníamos
que optimizar. Ya habíamos utilizado esta técnica en el Emacs original,
cuando reescribimos en lenguaje máquina algunas funciones de nivel
relativamente alto, transformándolas en primitivas TECO. Por ejemplo,
había una primitiva TECO para rellenar un párrafo (en realidad, para
hacer casi todo el trabajo necesario para rellenar un párrafo, porque
algunas de las tareas que menos tiempo consumían eran realizadas en un
nivel superior por un programa TECO). Se podría haber hecho todo el
trabajo con un programa TECO, pero habría resultado demasiado lento, por
eso lo optimizamos escribiendo parte de él en lenguaje máquina. Esa
misma idea es la que usamos aquí (en la técnica híbrida): escribimos la
mayoría del editor en Lisp, pero escribimos en un nivel inferior algunas
partes que tenían que ejecutarse particularmente rápido.

Por lo tanto, cuando escribí mi segunda implementación de Emacs seguí el
mismo esquema. El lenguaje de bajo nivel ya no era lenguaje máquina,
sino C. C era un lenguaje bueno y eficiente para programas portátiles
que fueran a ejecutarse en un sistema operativo tipo Unix. Había un
intérprete de Lisp, pero implementé directamente en C funciones para
tareas de edición de propósito específico: manipular las zonas de
memoria intermedia [buffers] del editor, insertar texto por delante,
leer y escribir ficheros, refrescar la pantalla con el contenido de la
memoria intermedia y gestionar la ventanas del editor.

Ahora bien, este no fue el primer Emacs escrito en C y que se ejecutaba
en Unix. El primero lo escribió James Gosling, y era conocido como
GosMacs. Con James ocurrió algo extraño. Al principio parecía estar
influido por el mismo espíritu de participación y cooperación del Emacs
original. En primer lugar liberé el Emacs original para personal del
MIT. Alguien quería adaptarlo para su ejecución en Twenex, inicialmente
sólo se podía ejecutar sobre el Incompatible Timesharing System [sistema
de tiempo compartido incompatible] que usábamos en el MIT. Lo adaptaron
a Twenex, lo cual significaba que había unos pocos cientos de
instalaciones alrededor del mundo que podían, potencialmente, usarlo.
Empezamos a distribuírselo junto con la norma de que «usted debía
enviarnos todas sus mejoras» para que así todos nos pudiéramos
beneficiar. Nadie intentó nunca hacer cumplir esta norma pero, hasta
donde yo sé, la gente cooperaba.

Inicialmente Gosling parecía participar de este espíritu. Escribió en un
manual que llamó Emacs al programa con la esperanza de que otros
miembros de la comunidad lo mejoraran hasta que llegara a ser merecedor
de ese nombre. Esa es la forma correcta de enfocar la relación con la
comunidad, pedirle que se una al proyecto y mejore el programa. Pero más
adelante pareció cambiar el espíritu, y lo vendió a una empresa.

Por aquel entonces yo estaba trabajando en el sistema GNU (un sistema
operativo libre tipo Unix al que mucha gente llama erróneamente
«Linux»). No había ningún editor Emacs que pudiera ejecutarse en Unix y
que fuera software libre. No obstante, tenía un amigo que había
participado en el desarrollo del Emacs de Gosling. Gosling le había dado
permiso, por correo electrónico, para distribuir su propia versión. Me
propuso que usara esa versión. Entonces me di cuenta de que el Emacs de
Gosling no incluía un Lisp real. Tenía un lenguaje de programación
conocido como «mocklisp», que sintácticamente parece Lisp pero que no
tiene sus estructuras de datos. Así, los programas no eran datos, y
carecía de elementos vitales de Lisp. Sus estructuras de datos eran
cadenas de caracteres, números y unos pocos elementos especializados
más.

Llegué a la conclusión de que no podía utilizarlo y tuve que
reemplazarlo por completo, para lo cual el primer paso fue escribir un
intérprete de Lisp real. Gradualmente adapté cada componente del editor
basándolo en estructuras de datos de Lisp real, en lugar de estructuras
de datos ad hoc, y haciendo las estructuras de datos internas del editor
visibles y manipulables por los programas Lisp del usuario.

La excepción fue redisplay. Durante mucho tiempo, redisplay fue una
especie de universo paralelo. El editor pasaba al universo de redisplay
y todo funcionaba con estructuras de datos muy especiales que no eran
seguras para la recolección de memoria [garbage collection], no eran
seguras frente a interrupciones, y no podía ejecutar ningún programa
Lisp mientras tanto. Posteriormente lo hemos modificado, ahora se puede
ejecutar código Lisp concurrentemente con redisplay. Es algo muy
práctico.

Este segundo Emacs era «software libre» en el sentido moderno del
término: formaba parte de una campaña política explícita para la
elaboración de software libre. La esencia de la campaña era que todo el
mundo debería tener la libertad de hacer lo que nosotros hacíamos en el
MIT en los viejos tiempos: trabajar conjuntamente en el software y
colaborar con todo el que quisiera trabajar con nosotros. Esta es la
base del movimiento por el software libre, la experiencia que tuve, la
vida que viví en el Laboratorio de Inteligencia Artificial del MIT:
trabajar para el conocimiento, y no obstaculizar su uso ni su expansión.

En esa época, podía construir un ordenador por un precio similar al de
otros ordenadores que no estaban pensados para usar Lisp, en el cual
Lisp se ejecutaría mucho más rápido y que incluiría validación de tipos
en cada operación. Los ordenadores normales típicamente le forzaban a
elegir entre velocidad de ejecución y buena validación de tipos. O sea
que sí, podía tener un compilador de Lisp y ejecutar sus programas con
velocidad, pero cuando sus programas intentaban tomar car de un número,
obtenían resultados absurdos y terminaban por fallar o bloquearse.

La máquina Lisp podía ejecutar instrucciones aproximadamente a la misma
velocidad que esas otras máquinas, pero para cada instrucción una
instrucción car validaría los tipos de los datos, de modo que cuando se
intentara obtener el car de un número en un programa compilado,
devolvería un error inmediato. Construimos la máquina y un sistema
operativo Lisp para ella. Estaba escrito en Lisp casi en su totalidad,
con las únicas excepciones de algunos fragmentos escritos en
microcódigo. Hubo quien se interesó en fabricarla, lo que significaba
fundar una empresa.

Había dos visiones diferentes sobre cómo debería ser esa empresa.
Greenblatt quería fundar lo que él llamaba una empresa «hacker». Esto
quería decir que sería una empresa gestionada por hackers y que operaría
de un modo propicio para hackers. Otro objetivo era mantener la cultura
del Laboratorio de Inteligencia Artificial [3]. Desafortunadamente,
Greenblatt no tenía experiencia empresarial, por lo que otros miembros
del grupo de la máquina Lisp expresaron sus dudas sobre el éxito de la
empresa. Pensaban que su plan para evitar inversiones externas no
funcionaría.

¿Por qué quería evitar la inversión externa? Porque cuando una empresa
tiene inversores externos, éstos toman el control y no permiten que
tenga ningún escrúpulo. Y, si usted tiene algún escrúpulo, finalmente le
relevan de sus funciones directivas.

La idea de Greenblatt era encontrar un cliente que pagara sus máquinas
por adelantado para poder comprar las piezas necesarias. Construirían
las máquinas y las entregarían; con los beneficios obtenidos podrían
comprar las piezas para unas pocas máquinas más, venderlas, comprar
piezas para un número mayor de máquinas, y así sucesivamente. Los otros
miembros del grupo pensaban que lo más probable era que el plan no
saliera bien.

Entonces Greenblatt reclutó a Russell Noftsker, la persona que me había
contratado, quien había dejado el Laboratorio de Inteligencia Artificial
y creado una empresa exitosa. Russell era considerado una persona con
aptitudes para los negocios. Demostró serlo al decir a los otros
miembros del grupo: «deshagámonos de Greenblatt, olvidad sus ideas, y
fundaremos otra empresa». Apuñalando por la espalda, sin duda un
auténtico hombre de negocios. Decidieron crear una empresa llamada
Symbolics. Obtendrían financiación externa, no tendrían escrúpulos y
harían todo lo posible por ganar.

Pero Greenblatt no se dio por vencido. Fundó, junto con los pocos que
permanecieron leales a él, Lisp Machines Inc. y siguió adelante con sus
planes. ¡Y tuvieron éxito! Consiguieron el primer cliente y éste les
pagó por adelantado. Construyeron las máquinas y las vendieron, y
construyeron más y más máquinas. Tuvieron éxito a pesar de no contar con
la ayuda de la mayor parte de los miembros del grupo. Symbolics también
empezó con buen pie, así que había dos empresas de máquinas Lisp
compitiendo. Cuando Symbolics vio que LMI no se iba a caer de bruces
empezó a buscar maneras de destruirla.

Por lo tanto, al abandono de nuestro laboratorio le siguió la «guerra»
en nuestro laboratorio. El abandono tuvo lugar cuando Symbolics se llevó
a todos los hackers, excepto a los pocos que trabajaban a tiempo parcial
en LMI y a mí mismo. Luego apelaron a una norma y eliminaron a la gente
que trabajaba a tiempo parcial para el MIT, que tuvo que marcharse, lo
cual me dejo sólo a mí. En ese momento el Laboratorio de Inteligencia
Artificial estaba indefenso. Y, además, el MIT había llegado a un
acuerdo muy poco sensato con esas dos empresas. Era un contrato a tres
bandas por el que ambas empresas autorizaban el uso de las fuentes del
sistema de la máquina Lisp. Estas empresas debían permitir al MIT usar
sus modificaciones. Pero el contrato no decía que el MIT tuviera derecho
a instalarlas en las máquinas Lisp para cuyo uso le habían otorgado
licencia ambas empresas. Nadie había previsto que el grupo de hackers
del Laboratorio de Inteligencia Artificial sería aniquilado, pero lo
fue.

A Symbolics se le ocurrió un plan [4]. Dijeron al laboratorio:
«seguiremos permitiéndoles que usen nuestras modificaciones al sistema,
pero no podrán instalarlas en la máquina Lisp del MIT. En su lugar, les
daremos acceso al sistema de la máquina Lisp de Symbolics, y podrán
ejecutarlo, pero eso será todo lo que podrán hacer».

Esto, en la práctica, significaba que nos exigían posicionarnos en un
bando y utilizar, o bien la versión del MIT del sistema, o bien la
versión de Symbolics. Nuestra decisión determinaría a qué sistema irían
nuestras mejoras. Si mejorábamos la versión de Symbolics, estaríamos
apoyando a Symbolics exclusivamente. Si utilizábamos y mejorábamos la
versión del sistema del MIT, ambas empresas tendrían acceso a nuestro
trabajo. Pero Symbolics vio que estaríamos dando apoyo a LMI porque
estaríamos ayudando a que siguiera existiendo. Así, no se nos permitió
seguir siendo neutrales.

Hasta ese momento yo no había tomado partido por ninguna de las dos
empresas, aunque me entristecía ver lo que le había ocurrido a nuestra
comunidad y al software. Pero ahora, Symbolics había forzado la
situación. Así que, en un intento por ayudar a mantener Lisp Machines
Inc. a flote [5], empecé a duplicar todas las mejoras que había hecho
Symbolics al sistema de la máquina Lisp. Escribí por mí mismo las
mejoras equivalentes de nuevo (es decir, el código era mío).

Después de un tiempo [6], llegué a la conclusión de que sería mejor ni
siquiera mirar su código. Cuando anunciaban la liberación de una
actualización del código, podía ver en las notas correspondientes a la
nueva liberación cuáles eran las modificaciones introducidas e
implementarlas. Cuando ellos hacían finalmente la liberación de las
modificaciones, yo también liberaba las mías.

De esta manera, durante dos años evité que acabaran con Lisp Machines
Incorporated, y las dos empresas siguieron adelante. Pero no quería
pasarme años y años castigando a alguien, evitando que se cometiera un
acto malvado. Supuse que ya habían sido castigados bastante puesto que
estaban inmersos en una competición que no tendría fin [7]. Por otro
lado, había llegado el momento de formar una nueva comunidad que
reemplazara a la que las acciones suyas y de otros exterminaron.

La comunidad Lisp en los setenta no estaba limitada al Laboratorio de
Inteligencia Artificial del MIT, y no todos los hackers estaban en el
MIT. La guerra iniciada por Symbolics fue lo que aniquiló el MIT, pero
había otras actividades en marcha. Había gente que abandonó la
cooperación, y esto también contribuyó a extinguir la comunidad.

Una vez que dejé de castigar a Symbolics, tuve que pensar qué hacer a
continuación. Tenía que hacer un sistema operativo libre, eso estaba
claro. La única forma de que la gente pudiera trabajar conjuntamente y
compartir era con un sistema operativo libre.

Al principio pensé en hacer un sistema basado en Lisp, pero me di cuenta
de que no sería una buena idea desde el punto de vista técnico. Para
tener algo como el sistema de la máquina Lisp, se necesita un tipo de
microcódigo llamado «de propósito específico». Eso es lo que hizo
posible ejecutar programas con la misma velocidad con la que se
ejecutaban programas en otros ordenadores y con el beneficio adicional
de la validación de tipos. Sin eso, se habría visto limitado a algo
similar a los compiladores Lisp para otras máquinas. Los programas
habrían sido más rápidos, pero inestables. Ahora bien, eso puede ser
admisible si está ejecutando un programa en un sistema de tiempo
compartido: que un programa falle no es un desastre, es algo que ocurre
ocasionalmente. Pero no es admisible cuando lo que escribimos es el
sistema operativo, así que rechacé la idea de hacer un sistema como la
máquina Lisp.

En su lugar, decidí hacer un sistema operativo tipo Unix que tuviera
implementaciones Lisp, las cuales serían ejecutadas como programas de
usuario. El núcleo no estaría escrito en Lisp, pero tendríamos Lisp. Así
que el desarrollo de ese sistema operativo, el sistema operativo GNU,
fue lo que me llevó a escribir Emacs de GNU. Al hacerlo, me propuse como
meta hacer la implementación de Lisp mínima posible. El tamaño de los
programas era algo a tener muy en cuenta.

Había gente en aquellos días, en 1985, que tenía máquinas con un
megabyte de memoria y sin memoria virtual. Querían poder usar Emacs de
GNU. Esto significaba que tenía que hacer que el programa fuera lo más
pequeño posible.

Por ejemplo, en aquel entonces la única estructura iterativa era while,
implementada de forma extremadamente simple. No había ningún mecanismo
para interrumpir la ejecución de la sentencia while y transferir el
control a la instrucción siguiente a dicha sentencia, usted tenía que
hacer un catch y un throw, o monitorizar una variable para salir del
bucle. Esto muestra hasta dónde estaba llevando las cosas para mantener
los programas pequeños. No teníamos caar, cadr, etc. Había que sacarle
el mayor jugo posible, ese fue el espíritu de Emacs de GNU, el espíritu
de Emacs Lisp desde el principio.

Evidentemente, las máquinas actuales tienen mayor capacidad, y ya no
hacemos las cosas así. Ahora incluimos caar, cadr, etc. Y podríamos
añadir otra estructura iterativa un día de estos. Queremos ampliarlo en
cierta medida, pero no hasta el punto de Common Lisp. Una vez implementé
Common Lisp en una máquina Lisp, y no estoy muy satisfecho con el
resultado. Algo que no me gusta gran cosa son los parámetros de palabra
clave [8]. No me parecen muy de Lisp; los utilizo a veces pero intento
hacerlo lo menos posible.

Ese no fue el fin de los proyectos de GNU implicados con Lisp. Más
tarde, alrededor de 1995, estábamos estudiando el inicio de un proyecto
de escritorio gráfico. Teníamos claro que queríamos un lenguaje de
programación que hiciera fácilmente extensibles, como el editor, los
programas accesibles desde el escritorio. La cuestión era cuál.

En aquel momento, TCL estaba recibiendo un fuerte impulso como lenguaje
a utilizar para este propósito. Yo tenía una opinión muy negativa de
TCL, básicamente porque no era Lisp. Tiene un ligerísimo parecido con
Lisp, pero no semánticamente, y no es tan limpio. Después, me mostraron
un anuncio en el que Sun ofrecía un puesto de trabajo para trabajar con
TCL y hacer de él el «lenguaje de extensión estándar, de facto» en el
mundo. Y pensé: «Tenemos que evitar que eso llegue a ocurrir.». Así que
empezamos a hacer de Scheme el lenguaje para extensiones estándar para
GNU. No Common Lisp, porque era demasiado voluminoso. La idea era tener
un intérprete Scheme diseñado para ser enlazado en las aplicaciones de
la misma manera que se enlazaba TCL. Entonces lo recomendaríamos como el
paquete para extensiones prefererido para todos los programas GNU.

Usted puede obtener un beneficio interesante del uso de un lenguaje tan
potente como un dialecto de Lisp como su lenguaje primario de extensión:
puede implementar otros lenguajes traduciéndolos a su lenguaje primario.
Si su lenguaje primario es TCL, usted no podrá implementar Lisp
fácilmente mediante su traducción a TCL. Pero si su lenguaje primario es
Lisp, no es tan difícil implementar otros lenguajes traduciéndolos.
Nuestra idea era que si cada aplicación extensible admitía Scheme, usted
podría escribir una implementación de TCL o Python o Perl en Scheme que
tradujera los programas en esos lenguajes a Scheme. Entonces, usted
podría cargar su traductor en cualquier aplicación y extender dicha
aplicación usando su lenguaje favorito.

Mientras los lenguajes de extensión sean débiles, los usuarios sólo
pueden usar los lenguajes proporcionados por el programador. Lo que
significa que a quien le guste utilizar un lenguaje de programación
determinado tiene que competir por la elección de los diseñadores de
aplicaciones diciendo «por favor, programador, ponga mi lenguaje en su
aplicación, no el lenguaje de aquél.». Después los usuarios no tienen
ninguna opción, la aplicación viene con un lenguaje y tienen que
quedarse con él. Pero cuando dispone de un lenguaje potente que puede
implementar otros mediante la traducción, da al usuario la posibilidad
de elegir el lenguaje y ya no hay necesidad de una guerra de lenguajes.
Esto es lo que esperamos que haga «Guile», nuestro intérprete Scheme. El
verano pasado tuvimos a una persona trabajando en la finalización de un
traductor de Python a Scheme. No sé si ya está completamente terminado,
pero cualquiera que esté interesado en este proyecto, por favor póngase
en contacto. Este es nuestro plan para el futuro.

Esta charla no es sobre software libre, pero déjenme comentarles
brevemente lo que significa. Software libre no se refiere al precio1, no
significa que usted lo obtiene gratis (puede haber pagado por una copia,
o haberla obtenido gratis.). Lo que significa es que usted tiene
libertad como usuario. Lo fundamental es que es libre de ejecutar el
programa, libre de estudiar qué hace, libre de modificarlo para
adaptarlo a sus necesidades, libre de redistribuir las copias de otros y
libre de publicar versiones mejoradas, ampliadas. Esto es lo que
significa software libre. Si utiliza un programa que no es libre, pierde
una libertad crucial, así que no lo haga nunca.

El propósito del proyecto GNU es hacer más fácil para la gente rechazar
el software que no sea libre, pisotea libertades y domina usuarios,
proporcionándole software libre para sustituirlo. Para aquellos que no
tienen el valor moral de rechazar el software que no es libre cuando
hacerlo representa un inconveniente práctico, lo que intentamos hacer es
ofrecer una alternativa libre de forma que puedan mudarse a la libertad
de forma más ordenada y con menos sacrificios en términos prácticos.
Cuanto menor el sacrificio, mejor. Queremos hacer más fácil vivir en
libertad, cooperar.

Es una cuestión de libertad para cooperar. Solemos pensar en la libertad
y en la cooperación con la sociedad como si fueran opuestos. Pero aquí
están del mismo lado. Con software libre es libre de cooperar con otros
así como libre de ayudarse a usted mismo. Con software que no es libre,
alguien le está dominando y está manteniendo dividida a la gente. No se
le permite compartir con el resto, no es libre de cooperar ni de ayudar
a la sociedad, como tampoco es libre de ayudarse a usted mismo.
Divididos y desamparados es como se encuentran los usuarios de software
que no es libre.

Hemos producido una enorme variedad de software libre. Hemos hecho lo
que la gente decía que nunca lograríamos hacer; tenemos dos sistemas
operativos de software libre. Tenemos muchas aplicaciones y, obviamente,
todavía tenemos mucho camino por recorrer. Así que necesitamos su ayuda.
Me gustaría pedirles que colaboraran como voluntarios para el proyecto
GNU; ayúdennos a desarrollar software libre para más tareas. Echen un
vistazo a gnu.org/help para encontrar sugerencias sobre cómo ayudar. Si
quieren hacer algún pedido, hay un enlace disponible en la página
principal. Si quieren leer sobre cuestiones filosóficas, miren en
/philosophy. Si están buscando el software libre disponible, miren en
/directory, donde se listan alrededor de 1900 paquetes en la actualidad
(lo cual es una fracción de todo el software libre disponible ahí
fuera). Por favor, escriban más software y contribuyan. Mi libro de
ensayos, «Free Software and Free Society» se encuentra a la venta y
puede adquirirse en www.gnu.org [9]2. ¡Feliz hacking! Notas

    Guy Steele diseñó el conjunto de órdenes simétrico original de
    Emacs; luego, él y yo empezamos a implementar Emacs (sobre TECO),
    pero, tras una larga sesión conjunta de desarrollo, Steele empezó a
    distanciarse, así que yo finalicé Emacs. Otros, entre los que
    destacan Eugene C. Cicciarelli y Mike McMahon, contribuyeron más
    tarde de forma sustancial. Bernie Greenberg dice que Dan Weinreb
    implementó Emacs para la Máquina Lisp antes de que Greenberg lo
    implementara para Multics. Pido disculpas por el error. El plan de
    Greenblatt, según lo entendía yo, era contratar a la gente del
    laboratorio a tiempo parcial, de forma que pudieran seguir
    trabajando en el Laboratorio de Inteligencia Artificial. En cambio,
    Symbolics les contrató a jornada completa, así que dejaron de
    trabajar en el MIT. Las circunstancias de este plan, que no expuse
    explícitamente en la charla, fueron las siguientes: durante un
    periodo inicial los hackers que habían dejado el Laboratorio de
    Inteligencia Artificial, tanto los que trabajaban para Symbolics
    como los que lo hacían para LMI, continuaron aportando al sistema de
    la máquina Lisp del MIT sus modificaciones, a pesar de que el
    contrato no lo exigía. El plan de Symbolics era provocar
    unilateralmente la ruptura de esta cooperación. No era que me
    preocupara especialmente el destino de LMI, sino más bien que no
    quería que Symbolics saliera vencedora gracias a haber agredido como
    lo hizo al Laboratorio de Inteligencia Artificial. Esta afirmación
    ha sido malinterpretada atribuyéndole el significado de que nunca
    miré el código de Symbolics. En realidad dice que sí lo hice, al
    principio. El código fuente de Symbolics estaba disponible en el
    MIT, por lo tanto yo podía leerlo, y al principio era así como me
    enteraba de sus modificaciones.

    Pero eso significaba que tenía que hacer un esfuerzo especial para
    resolver cada problema de forma diferente, para evitar que mi código
    fuera una copia del código de Symbolics. Pasado un tiempo, llegué a
    la conclusión de que era mejor no mirarlo. De esa forma podía
    escribir el código de la forma que considerara mejor sin preocuparme
    de lo que contenía el código de Symbolics. En una ocasión Symbolics
    se quejó al MIT de que mi trabajo, al frustrar sus planes, le había
    costado un millón de dólares. No me molesta si una función muy
    compleja y avanzada toma parámetros de palabras clave. Lo que me
    molesta es ponerlas en funciones simples y básicas como «member». En
    2021, este libro (en inglés) puede adquirirse en GNU Press.

Notas del traductor:

    Software Libre es la traducción de Free Software. Aquí se hace
    referencia al doble significado del término inglés Free, que puede
    significar tanto «libre» como «gratis». Regresar al texto. Existe
    una traducción del libro publicada en España por la editorial
    Traficantes de Sueños. Regresar al texto.