taler-merchant-demos

rms-lisp.html (38892B)

---

 <!--#set var="ENGLISH_PAGE" value="/gnu/rms-lisp.en.html" -->
 
 <!--#include virtual="/server/header.es.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="gnu-history" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- 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>
 <style type="text/css" media="print,screen"><!--
 a[href*='#foot-'] { font-size: .94em; }
 -->
 </style>
 
 <!--#include virtual="/gnu/po/rms-lisp.translist" -->
 <!--#include virtual="/server/banner.es.html" -->
 <!--#include virtual="/gnu/gnu-breadcrumb.es.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.es.html" -->
 <div class="article reduced-width">
 <h2>Mis experiencias con Lisp y el desarrollo de Emacs de GNU</h2>
 
 <div class="infobox">
 <p>Transcripción de la conferencia pronunciada por Richard Stallman el 28 de
 octubre de 2002 en el Congreso Internacional de Lisp.</p>
 </div>
 <hr class="thin" />
 
 <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 <code>5l</code>, que significaba «mover cinco
 líneas», o <code>i</code> 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: <code>&lt;&nbsp;&gt;</code>. 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&#8239;<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 &#8239;<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 &#8239;<a class="ftn"
 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&#8239;<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&#8239;<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&#8239;<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 &#8239;<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
 <code>while</code>, implementada de forma extremadamente simple. No había
 ningún mecanismo para interrumpir la ejecución de la sentencia
 <code>while</code> y transferir el control a la instrucción siguiente a
 dicha sentencia, usted tenía que hacer un <cite>catch</cite> y un
 <cite>throw</cite>, 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 <code>caar</code>, <code>cadr</code>, 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 <code>caar</code>, <code>cadr</code>, 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&#8239;<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/help.html">gnu.org/help</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 www.gnu.org&#8239;<a
 href="#foot-9">[9]</a><sup><a href="#TransNote2"
 id="IniTransNote2">2</a></sup>. ¡Feliz hacking!</p>
 <div class="column-limit"></div>
 
 <h3 class="footnote">Notas</h3>
 <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>
 
 <li id="foot-9">En 2021, este libro (en inglés) puede adquirirse en <a
 href="https://shop.fsf.org/books-docs/free-software-free-society-selected-essays-richard-m-stallman-3rd-edition">GNU
 Press</a>.</li>
 </ol>
 </div>
 
 <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" role="contentinfo">
 <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 contributing 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, 2021 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: 2021/11/03 16:00:57 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>