path: root/talermerchantdemos/blog/articles/es/rms-lisp.html

<!--#set var="ENGLISH_PAGE" value="/gnu/rms-lisp.en.html" -->

<!--#include virtual="/server/header.es.html" -->
<!-- Parent-Version: 1.77 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Mis experiencias con Lisp y el desarrollo de Emacs de GNU - Proyecto GNU -
Free Software Foundation </title>

<!--#include virtual="/gnu/po/rms-lisp.translist" -->
<!--#include virtual="/server/banner.es.html" -->
<h2>Mis experiencias con Lisp y el desarrollo de Emacs de GNU</h2>

<blockquote><p>(Transcripción de la conferencia pronunciada por Richard Stallman el 28 de
octubre de 2002 en el Congreso Internacional de Lisp [<span
style="font-style:italic;">International Lisp Conference</span>]).</p></blockquote>

<p>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.</p>

<p>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 <abbr title="Programmed Data
Processor" lang="en">PDP</abbr>-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.</p>

<p>Fue tras comenzar mi trabajo en el <abbr title="Instituto de Tecnología de
Massachusetts">MIT</abbr> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <abbr title="Text
Editor and COrrector" lang="en">TECO</abbr>. <abbr>TECO</abbr> 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.</p>

<p>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: &lt; &gt;. 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
<a href="#foot-1">(1)</a> 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 <span
style="font-style:italic;">unwind-protect</span>, llamémosle,
«de-aplicación-abierta», de TECO.</p>

<p>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.</p>

<p>Fue Bernie Greenberg quien descubrió que lo era <a href="#foot-2">(2)</a>
. 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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
<span style="font-style:italic;">Incompatible Timesharing System</span>
[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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>La excepción fue <span style="font-style:italic;">redisplay</span>. Durante
mucho tiempo, <span style="font-style:italic;">redisplay</span> fue una
especie de universo paralelo. El editor pasaba al universo de <span
style="font-style:italic;">redisplay</span> y todo funcionaba con
estructuras de datos muy especiales que no eran seguras para la recolección
de memoria [<span style="font-style:italic;">garbage collection</span>], 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 <span
style="font-style:italic;">redisplay</span>. Es algo muy práctico.</p>

<p>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.</p>

<p>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 <code>car</code> de un número,
obtenían resultados absurdos y terminaban por fallar o bloquearse.</p>

<p>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 <code>car</code> validaría los tipos de los datos, de modo que
cuando se intentara obtener el <code>car</code> 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.</p>

<p>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 <a href="#foot-3">(3)</a>. 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.</p>

<p>¿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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p> A Symbolics se le ocurrió un plan <a href="#foot-4">(4)</a>. 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».</p>

<p>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.</p>

<p>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 <a href="#foot-5">(5)</a>, 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).</p>

<p>Después de un tiempo <a href="#foot-6">(6)</a>, 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.</p>

<p>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 <a
href="#foot-7">(7)</a>. 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 ejecutar un
<code>catch</code> y un <code>throw</code>, 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.</p>

<p>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<a
href="#foot-8">(8)</a>. No me parecen muy de Lisp; los utilizo a veces pero
intento hacerlo lo menos posible.</p>

<p>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.</p>

<p>En aquel momento, <abbr title="Tool Command Language" lang="en">TCL</abbr>
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.</p>

<p>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.</p>

<p>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.</p>

<p>Esta charla no es sobre software libre, pero déjenme comentarles brevemente
lo que significa. Software libre no se refiere al precio<sup><a
href="#TransNote1" id="IniTransNote1">1</a></sup>, 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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <a
href="/help/">http://www.gnu.org/help/help.es.html</a> 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, «<span style="font-style:italic,">Free Software and Free
Society</span>» se encuentra a la venta y puede adquirirse en <a
href="http://www.gnu.org">www.gnu.org</a><sup><a href="#TransNote2"
id="IniTransNote2">2</a></sup>. ¡Feliz hacking!</p>

<ol>
<li id="foot-1">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.</li>

<li id="foot-2">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. </li>

<li id="foot-3">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.</li>

<li id="foot-4">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.</li>

<li id="foot-5">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.</li>

<li id="foot-6">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.

<p>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.</p></li>

<li id="foot-7">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.</li>

<li id="foot-8">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».</li>
</ol>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<b>Notas del traductor</b>:
<ol>
<li id="TransNote1">Software Libre es la traducción de <span
style="font-style:italic;">Free Software</span>. Aquí se hace referencia al
doble significado del término inglés <span
style="font-style:italic;">Free</span>, que puede significar tanto «libre»
como «gratis». <a href="#IniTransNote1" >Regresar al texto</a>.</li>
<li id="TransNote2">Existe una traducción del libro publicada en España por
la editorial Traficantes de Sueños. <a href="#IniTransNote2">Regresar al
texto</a>.</li></ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.es.html" -->
<div id="footer">
<div class="unprintable">

<p>Envíe sus consultas acerca de la FSF y GNU a <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
avisar de enlaces rotos y proponer otras correcciones o sugerencias,
diríjase a <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
El equipo de traductores al español se esfuerza por ofrecer traducciones
fieles al original y de buena calidad, pero no estamos libres de cometer
errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
<a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
</p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
para las traducciones</a> para obtener información sobre la coordinación y
el envío de traducciones de las páginas de este sitio web.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 2003, 2007, 2013, 2014, 2020 Free Software Foundation, Inc.</p>

<p>Esta página está bajo licencia <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.es_ES">Creative
Commons Reconocimiento-SinObraDerivada 4.0 Internacional</a>.</p>

<!--#include virtual="/server/bottom-notes.es.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
<span style="text-weight:bold;">Traducción</span>: Rafa Pereira, julio 2009.</div>

<p class="unprintable"><!-- timestamp start -->
Última actualización:

$Date: 2020/09/23 10:32:19 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>