SUPERANDO LOS PROMEDIOS

Abril de 2001, rev. Abril de 2003

(Este artículo se deriva de una charla dada en el Simposio de desarrolladores Franz de 2001).

En el verano de 1995, mi amigo Robert Morris y yo pusimos en marcha una empresa llamada Viaweb . Nuestro plan era desarrollar un software que permitiera a los usuarios finales crear tiendas online. Lo novedoso de este software, en aquel momento, era que se ejecutaba en nuestro servidor y utilizaba páginas web comunes como interfaz.

Por supuesto, muchas personas podrían haber tenido esta idea al mismo tiempo, pero, hasta donde yo sé, Viaweb fue la primera aplicación basada en la Web. Nos pareció una idea tan novedosa que le pusimos ese nombre a la empresa: Viaweb, porque nuestro software funcionaba a través de la Web, en lugar de ejecutarse en el ordenador de escritorio.

Otra característica inusual de este software es que estaba escrito principalmente en un lenguaje de programación llamado Lisp. Fue una de las primeras aplicaciones de usuario final de gran tamaño escritas en Lisp, que hasta entonces se había utilizado principalmente en universidades y laboratorios de investigación. [1]

El arma secreta

Eric Raymond ha escrito un ensayo titulado "Cómo convertirse en hacker" y en él, entre otras cosas, les dice a los futuros hackers qué lenguajes deberían aprender. Sugiere empezar con Python y Java, porque son fáciles de aprender. El hacker serio también querrá aprender C, para hackear Unix, y Perl para la administración de sistemas y scripts cgi. Por último, el hacker verdaderamente serio debería considerar aprender Lisp:

Vale la pena aprender Lisp por la profunda experiencia de iluminación que tendrás cuando finalmente lo comprendas; esa experiencia te convertirá en un mejor programador para el resto de tus días, incluso si en realidad nunca usas mucho Lisp.

Este es el mismo argumento que se suele escuchar a favor de aprender latín. No te conseguirá trabajo, salvo quizás como profesor de literatura clásica, pero mejorará tu mente y te convertirá en un mejor escritor en los idiomas que sí quieras utilizar, como el inglés.

Pero espere un momento. Esta metáfora no es tan amplia. La razón por la que el latín no le permitirá conseguir un trabajo es que nadie lo habla. Si escribe en latín, nadie podrá entenderlo. Pero Lisp es un lenguaje de programación y las computadoras hablan cualquier idioma que usted, el programador, les diga.

Entonces, si Lisp te hace un mejor programador, como él dice, ¿por qué no querrías usarlo? Si a un pintor se le ofreciera un pincel que lo haría mejor pintor, me parece que querría usarlo en todos sus cuadros, ¿no? No estoy tratando de burlarme de Eric Raymond. En general, su consejo es bueno. Lo que dice sobre Lisp es más o menos la sabiduría convencional. Pero hay una contradicción en la sabiduría convencional: Lisp te hará un mejor programador y, sin embargo, no lo usarás.

¿Por qué no? Después de todo, los lenguajes de programación son solo herramientas. Si Lisp realmente produce mejores programas, deberías usarlo. Y si no, ¿quién lo necesita?

No se trata de una mera cuestión teórica. El software es un negocio muy competitivo, propenso a los monopolios naturales. Una empresa que escriba software más rápido y mejor, en igualdad de condiciones, dejará a sus competidores fuera del negocio. Y cuando estás empezando una startup, esto lo sientes muy profundamente. Las startups tienden a ser una propuesta de todo o nada. O te haces rico o no consigues nada. En una startup, si apuestas por la tecnología equivocada, tus competidores te aplastarán.

Robert y yo conocíamos bien Lisp y no veíamos ninguna razón para no confiar en nuestros instintos y optar por Lisp. Sabíamos que todos los demás escribían su software en C++ o Perl, pero también sabíamos que eso no significaba nada. Si uno elegía la tecnología de esa manera, tendría que utilizar Windows. Cuando se elige una tecnología, hay que ignorar lo que hacen los demás y considerar solo lo que funcionará mejor.

Esto es especialmente cierto en una startup. En una gran empresa, puedes hacer lo que hacen todas las demás grandes empresas, pero una startup no puede hacer lo que hacen todas las demás. No creo que mucha gente se dé cuenta de esto, incluso en las startups.

La gran empresa promedio crece a un ritmo de aproximadamente un diez por ciento anual. Por lo tanto, si usted dirige una gran empresa y hace todo como lo hace una gran empresa promedio, puede esperar obtener un rendimiento tan bueno como el de una gran empresa promedio, es decir, crecer aproximadamente un diez por ciento anual.

Por supuesto, lo mismo ocurrirá si estás dirigiendo una startup. Si haces todo como lo hace una startup promedio, deberías esperar un rendimiento promedio. El problema es que un rendimiento promedio significa que el negocio se acabará. La tasa de supervivencia de las startups es muy inferior al cincuenta por ciento. Así que, si estás dirigiendo una startup, más vale que hagas algo extraño. Si no, estás en problemas.

En 1995, sabíamos algo que no creo que nuestros competidores entendieran, y pocos entienden incluso ahora: cuando estás escribiendo software que solo tiene que ejecutarse en tus propios servidores, puedes usar cualquier lenguaje que quieras. Cuando estás escribiendo software de escritorio, hay una fuerte tendencia a escribir aplicaciones en el mismo lenguaje que el sistema operativo. Hace diez años, escribir aplicaciones significaba escribir aplicaciones en C. Pero con el software basado en la Web, especialmente cuando tienes el código fuente tanto del lenguaje como del sistema operativo, puedes usar cualquier lenguaje que quieras.

Sin embargo, esta nueva libertad es un arma de doble filo. Ahora que se puede utilizar cualquier idioma, hay que pensar cuál utilizar. Las empresas que intentan hacer como si nada hubiera cambiado corren el riesgo de descubrir que sus competidores no lo hacen.

Si pudieras usar cualquier lenguaje, ¿cuál usarías? Elegimos Lisp. Por un lado, era obvio que el desarrollo rápido sería importante en este mercado. Todos empezábamos desde cero, por lo que una empresa que pudiera desarrollar nuevas funciones antes que sus competidores tendría una gran ventaja. Sabíamos que Lisp era un lenguaje realmente bueno para escribir software rápidamente, y las aplicaciones basadas en servidor magnifican el efecto del desarrollo rápido, porque puedes lanzar el software en el momento en que está terminado.

Si otras empresas no querían utilizar Lisp, mucho mejor. Podría darnos una ventaja tecnológica y necesitábamos toda la ayuda que pudiéramos conseguir. Cuando empezamos Viaweb, no teníamos experiencia en el mundo de los negocios. No sabíamos nada de marketing, ni de contratar personal, ni de recaudar dinero, ni de conseguir clientes. Ninguno de los dos había tenido nunca lo que se llamaría un trabajo de verdad. Lo único en lo que éramos buenos era en escribir software. Esperábamos que eso nos salvara. Aprovecharíamos cualquier ventaja que pudiéramos conseguir en el departamento de software.

Así que se podría decir que el uso de Lisp fue un experimento. Nuestra hipótesis era que si escribíamos nuestro software en Lisp, seríamos capaces de realizar funciones más rápidamente que nuestros competidores, y también de hacer cosas en nuestro software que ellos no podían hacer. Y como Lisp era de tan alto nivel, no necesitaríamos un gran equipo de desarrollo, por lo que nuestros costes serían menores. Si esto fuera así, podríamos ofrecer un producto mejor por menos dinero y aun así obtener beneficios. Acabaríamos consiguiendo todos los usuarios, y nuestros competidores no conseguirían ninguno, y acabarían cerrando. Eso era lo que esperábamos que ocurriera, de todos modos.

¿Cuáles fueron los resultados de este experimento? Sorprendentemente, funcionó. Al final teníamos muchos competidores, del orden de veinte a treinta, pero ninguno de sus programas podía competir con el nuestro. Teníamos un constructor de tiendas online wysiwyg que se ejecutaba en el servidor y, sin embargo, parecía una aplicación de escritorio. Nuestros competidores tenían scripts CGI y siempre les llevábamos mucha ventaja en cuanto a características. A veces, en su desesperación, los competidores intentaban introducir características que nosotros no teníamos. Pero con Lisp nuestro ciclo de desarrollo era tan rápido que a veces podíamos duplicar una nueva característica en un día o dos después de que un competidor la anunciara en un comunicado de prensa. Para cuando los periodistas que cubrían el comunicado de prensa se decidían a llamarnos, ya teníamos la nueva característica también.

A nuestros competidores les debió parecer que teníamos algún tipo de arma secreta, que estábamos descifrando su tráfico de Enigma o algo así. De hecho, teníamos un arma secreta, pero era más simple de lo que ellos creían. Nadie nos estaba filtrando noticias de sus características. Simplemente, éramos capaces de desarrollar software más rápido de lo que nadie creía posible.

Cuando tenía unos nueve años, por casualidad, conseguí una copia de El día del chacal, de Frederick Forsyth. El personaje principal es un asesino contratado para matar al presidente de Francia. El asesino tiene que burlar a la policía para llegar a un apartamento que da a la ruta del presidente. Pasa junto a ellos, vestido como un anciano con muletas, y nunca sospechan de él.

Nuestra arma secreta era similar. Escribíamos nuestro software en un extraño lenguaje de inteligencia artificial, con una sintaxis extraña llena de paréntesis. Durante años me había molestado oír que se describiera a Lisp de esa manera, pero ahora funcionaba a nuestro favor. En los negocios, no hay nada más valioso que una ventaja técnica que tus competidores no entienden. En los negocios, como en la guerra, la sorpresa vale tanto como la fuerza.

Y por eso, me da un poco de vergüenza decirlo, nunca dije nada públicamente sobre Lisp mientras trabajábamos en Viaweb. Nunca lo mencionamos a la prensa, y si buscabas Lisp en nuestro sitio web, todo lo que encontrarías eran los títulos de dos libros en mi biografía. Esto no fue casualidad. Una startup debe dar a sus competidores la menor información posible. Si no sabían en qué lenguaje estaba escrito nuestro software, o no les importaba, quería que siguiera siendo así. [2]

Los que mejor entendían nuestra tecnología eran los clientes. A ellos tampoco les importaba en qué lenguaje estaba escrito Viaweb, pero se dieron cuenta de que funcionaba muy bien. Les permitía crear tiendas online de gran apariencia en cuestión de minutos. Y así, gracias sobre todo al boca a boca, fuimos ganando cada vez más usuarios. A finales de 1996 teníamos unas 70 tiendas online. A finales de 1997 teníamos 500. Seis meses después, cuando Yahoo nos compró, teníamos 1.070 usuarios. Hoy, con el nombre de Yahoo Store, este software sigue dominando su mercado. Es una de las piezas más rentables de Yahoo, y las tiendas creadas con él son la base de Yahoo Shopping. Dejé Yahoo en 1999, así que no sé exactamente cuántos usuarios tienen ahora, pero lo último que supe de ellos eran unos 20.000.

La paradoja de Blub

¿Qué tiene de bueno Lisp? Y si Lisp es tan bueno, ¿por qué no lo usa todo el mundo? Parecen preguntas retóricas, pero en realidad tienen respuestas sencillas. Lisp es tan bueno no por alguna cualidad mágica visible sólo para los devotos, sino porque es simplemente el lenguaje más poderoso que existe. Y la razón por la que no todo el mundo lo usa es que los lenguajes de programación no son simplemente tecnologías, sino también hábitos mentales, y nada cambia más lentamente. Por supuesto, ambas respuestas necesitan una explicación.

Comenzaré con una afirmación sorprendentemente controvertida: los lenguajes de programación varían en potencia.

Pocos discutirían, al menos, que los lenguajes de alto nivel son más poderosos que el lenguaje de máquina. La mayoría de los programadores de hoy estarían de acuerdo en que, por lo general, no se desea programar en lenguaje de máquina. En lugar de eso, se debe programar en un lenguaje de alto nivel y hacer que un compilador lo traduzca al lenguaje de máquina. Esta idea está incluso incorporada en el hardware ahora: desde la década de 1980, los conjuntos de instrucciones han sido diseñados para compiladores en lugar de programadores humanos.

Todo el mundo sabe que escribir un programa entero a mano en lenguaje de máquina es un error. Lo que no se entiende tan a menudo es que existe un principio más general: si se puede elegir entre varios lenguajes, en igualdad de condiciones, es un error programar en cualquier otro que no sea el más potente. [3]

Hay muchas excepciones a esta regla. Si estás escribiendo un programa que tiene que funcionar muy de cerca con un programa escrito en un lenguaje determinado, puede ser una buena idea escribir el nuevo programa en el mismo lenguaje. Si estás escribiendo un programa que sólo tiene que hacer algo muy simple, como el procesamiento de números o la manipulación de bits, también puedes usar un lenguaje menos abstracto, especialmente porque puede ser ligeramente más rápido. Y si estás escribiendo un programa corto y desechable, puede que sea mejor que uses el lenguaje que tenga las mejores funciones de biblioteca para la tarea. Pero en general, para el software de aplicación, quieres usar el lenguaje más potente (razonablemente eficiente) que puedas conseguir, y usar cualquier otro es un error, exactamente del mismo tipo, aunque posiblemente en menor grado, que programar en lenguaje de máquina.

Como puede verse, el lenguaje de máquina es de muy bajo nivel. Pero, al menos como una especie de convención social, los lenguajes de alto nivel suelen tratarse como equivalentes. No lo son. Técnicamente, el término "lenguaje de alto nivel" no significa nada muy definido. No hay una línea divisoria entre los lenguajes de máquina de un lado y todos los lenguajes de alto nivel del otro. Los lenguajes se dividen en un continuo [4] de abstracción, desde los más potentes hasta los lenguajes de máquina, que a su vez varían en potencia.

Pensemos en Cobol. Cobol es un lenguaje de alto nivel, en el sentido de que se compila en lenguaje de máquina. ¿Alguien podría argumentar seriamente que Cobol es equivalente en potencia a, por ejemplo, Python? Probablemente se acerque más al lenguaje de máquina que Python.

¿Y qué tal Perl 4? Entre Perl 4 y Perl 5, se añadieron al lenguaje los cierres léxicos. La mayoría de los hackers de Perl estarían de acuerdo en que Perl 5 es más potente que Perl 4. Pero una vez que se admite eso, se admite que un lenguaje de alto nivel puede ser más potente que otro. Y de ello se sigue inexorablemente que, excepto en casos especiales, se debe utilizar el lenguaje más potente que se pueda conseguir.

Sin embargo, esta idea rara vez se lleva a cabo hasta el final. Después de cierta edad, los programadores rara vez cambian de lenguaje voluntariamente. Cualquiera que sea el lenguaje al que la gente esté acostumbrada, tiende a considerarlo lo suficientemente bueno.

Los programadores se apegan mucho a sus lenguajes favoritos y no quiero herir los sentimientos de nadie, así que para explicar este punto voy a utilizar un lenguaje hipotético llamado Blub. Blub se encuentra justo en el medio del continuo de abstracción. No es el lenguaje más poderoso, pero es más poderoso que Cobol o el lenguaje de máquina.

Y, de hecho, nuestro hipotético programador de Blub no usaría ninguno de ellos. Por supuesto, no programaría en lenguaje de máquina. Para eso están los compiladores. Y en cuanto a Cobol, no sabe cómo alguien puede hacer algo con él. Ni siquiera tiene x (la característica de Blub que elija).

Mientras nuestro hipotético programador de Blub esté mirando hacia abajo en el continuo de potencia, sabe que está mirando hacia abajo. Los lenguajes menos potentes que Blub son obviamente menos potentes, porque les falta alguna característica a la que está acostumbrado. Pero cuando nuestro hipotético programador de Blub mira en la otra dirección, hacia arriba en el continuo de potencia, no se da cuenta de que está mirando hacia arriba. Lo que ve son simplemente lenguajes extraños. Probablemente los considera aproximadamente equivalentes en potencia a Blub, pero con todas estas otras cosas peliagudas añadidas también. Blub es lo suficientemente bueno para él, porque piensa en Blub.

Sin embargo, cuando pasamos al punto de vista de un programador que utiliza cualquiera de los lenguajes que se encuentran en un nivel superior del continuo de poder, vemos que, a su vez, él menosprecia a Blub. ¿Cómo se puede hacer algo en Blub? Ni siquiera tiene y.

Por inducción, los únicos programadores en posición de ver todas las diferencias de potencia entre los distintos lenguajes son aquellos que entienden el más potente. (Esto es probablemente lo que Eric Raymond quiso decir cuando dijo que Lisp te convierte en un mejor programador). No puedes confiar en las opiniones de los demás, debido a la paradoja de Blub: están satisfechos con cualquier lenguaje que utilicen, porque éste dicta la forma en que piensan sobre los programas.

Lo sé por experiencia propia, cuando era estudiante de secundaria y escribía programas en Basic. Ese lenguaje ni siquiera admitía la recursión. Es difícil imaginar escribir programas sin usar la recursión, pero en ese momento no la echaba de menos. Pensaba en Basic y era un genio en eso. Dominaba todo lo que estudiaba.

Los cinco lenguajes que Eric Raymond recomienda a los hackers se encuentran en distintos puntos del continuo de poder. Dónde se encuentran entre sí es un tema delicado. Lo que diré es que creo que Lisp está en la cima. Y para apoyar esta afirmación les contaré una de las cosas que encuentro que faltan cuando miro los otros cuatro lenguajes. ¿Cómo se puede hacer algo en ellos, creo, sin macros? [5]

Muchos lenguajes tienen algo llamado macro, pero las macros de Lisp son únicas. Y, créalo o no, lo que hacen está relacionado con los paréntesis. Los diseñadores de Lisp no pusieron todos esos paréntesis en el lenguaje solo para que fuera diferente. Para el programador de Blub, el código de Lisp se ve raro, pero esos paréntesis están ahí por una razón: son la evidencia externa de una diferencia fundamental entre Lisp y otros lenguajes.

El código Lisp está formado por objetos de datos Lisp. Y no en el sentido trivial de que los archivos fuente contienen caracteres y las cadenas son uno de los tipos de datos admitidos por el lenguaje. El código Lisp, después de que el analizador lo lea, está formado por estructuras de datos que se pueden recorrer.

Si comprendes cómo funcionan los compiladores, lo que realmente ocurre no es tanto que Lisp tenga una sintaxis extraña, sino que Lisp no tiene sintaxis. Escribes programas en los árboles de análisis que se generan dentro del compilador cuando se analizan otros lenguajes. Pero estos árboles de análisis son completamente accesibles para tus programas. Puedes escribir programas que los manipulen. En Lisp, estos programas se denominan macros. Son programas que escriben programas.

¿Programas que escriben programas? ¿Cuándo querrías hacer eso? No muy a menudo, si piensas en Cobol. Todo el tiempo, si piensas en Lisp. Sería conveniente aquí si pudiera dar un ejemplo de una macro poderosa y decir: ¡ahí! ¿Qué tal eso? Pero si lo hiciera, parecería un galimatías para alguien que no supiera Lisp; no hay espacio aquí para explicar todo lo que necesitas saber para entender lo que significa. En Ansi Common Lisp traté de hacer las cosas lo más rápido que pude, y aún así no llegué a las macros hasta la página 160.

Pero creo que puedo ofrecer un argumento que podría ser convincente. El código fuente del editor de Viaweb probablemente estaba compuesto en un 20-25% por macros. Las macros son más difíciles de escribir que las funciones Lisp ordinarias, y se considera de mal estilo utilizarlas cuando no son necesarias. Por lo tanto, cada macro en ese código está ahí porque tiene que estar. Lo que eso significa es que al menos el 20-25% del código de este programa está haciendo cosas que no se pueden hacer fácilmente en ningún otro lenguaje. Por escéptico que pueda ser el programador de Blub sobre mis afirmaciones sobre los misteriosos poderes de Lisp, esto debería despertar su curiosidad. No estábamos escribiendo este código para nuestra propia diversión. Éramos una pequeña empresa emergente, programando tan duro como podíamos para poner barreras técnicas entre nosotros y nuestros competidores.

Una persona suspicaz podría empezar a preguntarse si había alguna correlación aquí. Una gran parte de nuestro código hacía cosas que son muy difíciles de hacer en otros lenguajes. El software resultante hacía cosas que el software de nuestros competidores no podía hacer. Tal vez había algún tipo de conexión. Te animo a que sigas ese hilo. Puede que haya más de lo que parece en ese anciano que cojea con sus muletas.

Aikido para startups

Pero no espero convencer a nadie ( mayor de 25 años ) de que salga a aprender Lisp. El propósito de este artículo no es cambiar la opinión de nadie, sino tranquilizar a las personas que ya están interesadas en usar Lisp, personas que saben que Lisp es un lenguaje poderoso, pero que se preocupan porque no se usa ampliamente. En una situación competitiva, eso es una ventaja. El poder de Lisp se multiplica por el hecho de que sus competidores no lo entienden.

Si piensas utilizar Lisp en una startup, no deberías preocuparte de que no sea ampliamente comprendido. Deberías esperar que siga siendo así. Y es probable que así sea. La naturaleza de los lenguajes de programación es hacer que la mayoría de la gente esté satisfecha con lo que utiliza actualmente. El hardware de las computadoras cambia mucho más rápido que los hábitos personales, por lo que la práctica de la programación suele estar entre diez y veinte años por detrás del procesador. En lugares como el MIT escribían programas en lenguajes de alto nivel a principios de los años 60, pero muchas empresas siguieron escribiendo código en lenguaje de máquina hasta bien entrados los años 80. Apuesto a que mucha gente siguió escribiendo en lenguaje de máquina hasta que el procesador, como un camarero ansioso por cerrar y volver a casa, finalmente los echó a patadas al cambiar a un conjunto de instrucciones de riesgo.

Por lo general, la tecnología cambia rápido, pero los lenguajes de programación son diferentes: no son solo tecnología, sino lo que piensan los programadores. Son mitad tecnología y mitad religión.[6] Y así, el lenguaje promedio, es decir, cualquier lenguaje que use el programador promedio, se mueve tan lento como un iceberg. La recolección de basura, introducida por Lisp en 1960, ahora se considera ampliamente como algo bueno. La tipificación en tiempo de ejecución, lo mismo, está creciendo en popularidad. Los cierres léxicos, introducidos por Lisp a principios de los años 70, ahora están, apenas, en la pantalla del radar. Las macros, introducidas por Lisp a mediados de los años 60, todavía son terra incognita.

Obviamente, el lenguaje medio tiene un enorme impulso. No estoy proponiendo que se pueda luchar contra esta poderosa fuerza. Lo que propongo es exactamente lo contrario: que, como un practicante de Aikido, se puede utilizar contra los oponentes.

Si trabajas para una gran empresa, esto puede no ser fácil. Te costará mucho convencer al jefe de pelo puntiagudo que te deje crear cosas en Lisp, cuando acaba de leer en el periódico que otro lenguaje está a punto, como Ada hace veinte años, de conquistar el mundo. Pero si trabajas para una empresa emergente que todavía no tiene jefes de pelo puntiagudo, puedes, como hicimos nosotros, sacar ventaja de la paradoja de Blub: puedes usar tecnología que tus competidores, pegados inamoviblemente al lenguaje medio, nunca podrán igualar.

Si alguna vez trabajas para una empresa emergente, te damos un consejo útil para evaluar a la competencia: lee sus ofertas de trabajo. Todo lo demás que aparece en su sitio puede ser fotografías de archivo o su equivalente en prosa, pero las ofertas de trabajo deben ser específicas sobre lo que buscan o conseguirán a los candidatos equivocados.

Durante los años que trabajamos en Viaweb leí muchas descripciones de puestos de trabajo. Parecía que surgía un nuevo competidor de la nada cada mes más o menos. Lo primero que hacía, después de comprobar si tenían una demostración en línea en vivo, era mirar sus listados de empleos. Después de un par de años de esto, podía saber de qué empresas debía preocuparme y de cuáles no. Cuanto más relacionadas con las TI eran las descripciones de los puestos de trabajo, menos peligrosa era la empresa. Las más seguras eran las que querían experiencia en Oracle. Nunca había que preocuparse por ellas. También estabas seguro si decían que querían desarrolladores de C++ o Java. Si querían programadores de Perl o Python, eso sería un poco aterrador; eso empieza a sonar como una empresa donde el lado técnico, al menos, está dirigido por verdaderos hackers. Si alguna vez hubiera visto una oferta de trabajo que buscara hackers de Lisp, me habría preocupado mucho.

Notas

[1] Viaweb al principio tenía dos partes: el editor, escrito en Lisp, que la gente usaba para crear sus sitios, y el sistema de pedidos, escrito en C, que manejaba los pedidos. La primera versión era principalmente en Lisp, porque el sistema de pedidos era pequeño. Más tarde agregamos dos módulos más, un generador de imágenes escrito en C y un administrador de back-office escrito principalmente en Perl.

En enero de 2003, Yahoo lanzó una nueva versión del editor escrita en C++ y Perl. Sin embargo, es difícil decir si el programa ya no está escrito en Lisp, porque para traducir este programa a C++ tuvieron que escribir literalmente un intérprete de Lisp: los archivos fuente de todas las plantillas generadoras de páginas siguen siendo, hasta donde yo sé, código Lisp. (Véase la décima regla de Greenspun ).

[2] Robert Morris dice que no necesitaba ser reservado, porque incluso si nuestros competidores hubieran sabido que estábamos usando Lisp, no habrían entendido por qué: "Si fueran tan inteligentes, ya estarían programando en Lisp".

[3] Todos los lenguajes son igualmente poderosos en el sentido de ser equivalentes a Turing, pero ese no es el sentido de la palabra que les importa a los programadores. (Nadie quiere programar una máquina de Turing). El tipo de poder que les importa a los programadores puede no ser definible formalmente, pero una forma de explicarlo sería decir que se refiere a características que solo se podrían obtener en el lenguaje menos poderoso escribiendo un intérprete para el lenguaje más poderoso en él. Si el lenguaje A tiene un operador para eliminar espacios de las cadenas y el lenguaje B no, eso probablemente no hace que A sea más poderoso, porque probablemente se pueda escribir una subrutina para hacerlo en B. Pero si A admite, digamos, la recursión, y B no, no es probable que sea algo que se pueda solucionar escribiendo funciones de biblioteca.

[4] Nota para nerds: o posiblemente una red, estrechándose hacia la parte superior; no es la forma lo que importa aquí sino la idea de que hay al menos un orden parcial.

[5] Es un poco engañoso tratar las macros como una característica separada. En la práctica, su utilidad se ve enormemente mejorada por otras características de Lisp, como los cierres léxicos y los parámetros de descanso.

[6] Como resultado, las comparaciones entre lenguajes de programación adoptan la forma de guerras religiosas o de libros de texto universitarios tan decididamente neutrales que en realidad son obras de antropología. Las personas que valoran su paz o quieren un puesto fijo evitan el tema. Pero la cuestión es sólo a medias religiosa; hay algo ahí que vale la pena estudiar, especialmente si se quiere diseñar nuevos lenguajes.