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 2001.)

En el verano de 1995, mi amigo Robert Morris y yo comenzamos una startup llamada Viaweb. Nuestro plan era escribir software que permitiera a los usuarios finales construir tiendas en línea. Lo novedoso de este software, en ese momento, era que se ejecutaba en nuestro servidor, utilizando páginas web ordinarias como interfaz.

Por supuesto, muchas personas podrían haber tenido esta idea al mismo tiempo, pero hasta donde sé, Viaweb fue la primera aplicación basada en la web. Nos parecía una idea tan novedosa que nombramos a la empresa en su honor: Viaweb, porque nuestro software funcionaba a través de la web, en lugar de ejecutarse en tu computadora de escritorio.

Otra cosa inusual sobre este software era que estaba escrito principalmente en un lenguaje de programación llamado Lisp. Fue una de las primeras grandes aplicaciones para el usuario final 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 llamado "Cómo convertirse en un hacker", y en él, entre otras cosas, les dice a los aspirantes a hackers qué lenguajes deberían aprender. Sugiere comenzar 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 del sistema y scripts CGI. Finalmente, el hacker verdaderamente serio debería considerar aprender Lisp:

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

Este es el mismo argumento que tiendes a escuchar para aprender latín. No te conseguirá un trabajo, excepto quizás como profesor de clásicos, pero mejorará tu mente y te hará un mejor escritor en los idiomas que realmente quieres usar, como el inglés.

Pero espera un momento. Esta metáfora no se extiende tanto. La razón por la que el latín no te conseguirá un trabajo es que nadie lo habla. Si escribes en latín, nadie puede entenderte. Pero Lisp es un lenguaje de computadora, y las computadoras hablan cualquier lenguaje que tú, el programador, les digas.

Así que si Lisp te hace un mejor programador, como dice, ¿por qué no querrías usarlo? Si a un pintor se le ofreciera un pincel que lo hiciera un mejor pintor, me parece que querría usarlo en todas sus pinturas, ¿no? No estoy tratando de burlarme de Eric Raymond aquí. En general, su consejo es bueno. Lo que dice sobre Lisp es prácticamente la sabiduría convencional. Pero hay una contradicción en la sabiduría convencional: Lisp te hará un mejor programador, y aun así no lo usarás.

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

Esta no es solo una pregunta teórica. El software es un negocio muy competitivo, propenso a monopolios naturales. Una empresa que obtiene software escrito más rápido y mejor, todas las demás cosas siendo iguales, dejará fuera del negocio a sus competidores. Y cuando estás comenzando una startup, sientes esto muy intensamente. Las startups tienden a ser una propuesta de todo o nada. O te haces rico, o no obtienes 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 podíamos ver ninguna razón para no confiar en nuestros instintos y optar por Lisp. Sabíamos que todos los demás estaban escribiendo su software en C++ o Perl. Pero también sabíamos que eso no significaba nada. Si eliges la tecnología de esa manera, estarías ejecutando Windows. Cuando eliges tecnología, tienes que ignorar lo que están haciendo 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 todas las demás grandes empresas están haciendo. Pero una startup no puede hacer lo que hacen todas las demás startups. No creo que muchas personas se den cuenta de esto, incluso en startups.

La empresa grande promedio crece alrededor del diez por ciento al año. Así que si estás dirigiendo una gran empresa y haces todo como lo hace la empresa grande promedio, puedes esperar hacerlo tan bien como la empresa grande promedio, es decir, crecer alrededor del diez por ciento al año.

Lo mismo sucederá si estás dirigiendo una startup, por supuesto. Si haces todo como lo hace la startup promedio, deberías esperar un rendimiento promedio. El problema aquí es que el rendimiento promedio significa que saldrás del negocio. La tasa de supervivencia de las startups es mucho menor al cincuenta por ciento. Así que si estás dirigiendo una startup, es mejor que estés haciendo algo raro. 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 desees. Cuando estás escribiendo software de escritorio, hay un fuerte sesgo hacia 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 desees.

Sin embargo, esta nueva libertad es una espada de doble filo. Ahora que puedes usar cualquier lenguaje, tienes que pensar en cuál usar. Las empresas que intentan pretender que nada ha cambiado corren el riesgo de descubrir que sus competidores no lo hacen.

Si puedes usar cualquier lenguaje, ¿cuál usas? Elegimos Lisp. Por un lado, era obvio que el desarrollo rápido sería importante en este mercado. Todos estábamos comenzando desde cero, así que una empresa que pudiera terminar nuevas características 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 servidores amplifican el efecto del desarrollo rápido, porque puedes lanzar software en el minuto en que está terminado.

Si otras empresas no querían usar Lisp, tanto mejor. Podría darnos una ventaja tecnológica, y necesitábamos toda la ayuda que pudiéramos conseguir. Cuando comenzamos Viaweb, no teníamos experiencia en negocios. No sabíamos nada sobre marketing, o contratar personas, o recaudar dinero, o conseguir clientes. Ninguno de nosotros había tenido siquiera lo que podrías llamar un trabajo real. Lo único en lo que éramos buenos era en escribir software. Esperábamos que eso nos salvaría. Cualquier ventaja que pudiéramos obtener en el departamento de software, la tomaríamos.

Así que podrías decir que usar Lisp fue un experimento. Nuestra hipótesis era que si escribíamos nuestro software en Lisp, podríamos terminar características más rápido que nuestros competidores, y también hacer cosas en nuestro software que ellos no podían hacer. Y dado que Lisp era tan de alto nivel, no necesitaríamos un gran equipo de desarrollo, así que nuestros costos serían más bajos. Si esto fuera así, podríamos ofrecer un mejor producto por menos dinero, y aún así obtener ganancias. Terminaríamos obteniendo todos los usuarios, y nuestros competidores no obtendrían ninguno, y eventualmente saldrían del negocio. Eso era lo que esperábamos que sucediera, de todos modos.

¿Cuáles fueron los resultados de este experimento? Sorprendentemente, funcionó. Eventualmente tuvimos muchos competidores, del orden de veinte a treinta de ellos, pero ninguno de su software podía competir con el nuestro. Teníamos un constructor de tiendas en línea WYSIWYG que se ejecutaba en el servidor y, sin embargo, se sentía como una aplicación de escritorio. Nuestros competidores tenían scripts CGI. Y siempre estábamos muy por delante de ellos en características. A veces, en 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 dentro de 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 dignaban a llamarnos, nosotros también tendríamos la nueva característica.

Debió parecer a nuestros competidores 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 se dieron cuenta. Nadie estaba filtrando noticias sobre sus características a nosotros. Simplemente éramos capaces de desarrollar software más rápido de lo que cualquiera pensaba que era posible.

Cuando tenía alrededor de nueve años, conseguí una copia de El día del chacal, de Frederick Forsyth. El personaje principal es un asesino que es contratado para matar al presidente de Francia. El asesino tiene que pasar por la policía para llegar a un apartamento que da a la ruta del presidente. Pasa justo al lado de ellos, disfrazado de anciano con muletas, y nunca lo sospechan.

Nuestra arma secreta era similar. Escribimos nuestro software en un extraño lenguaje de IA, con una sintaxis bizarra llena de paréntesis. Durante años me había molestado escuchar que Lisp se describía de esa manera. Pero ahora funcionó 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 así, me siento un poco avergonzado de decir que 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, lo único que encontrarías eran los títulos de dos libros en mi biografía. Esto no fue un accidente. Una startup debería dar a sus competidores la menor cantidad de información posible. Si no sabían en qué lenguaje estaba escrito nuestro software, o no les importaba, quería mantenerlo así. [2]

Las personas que entendían mejor nuestra tecnología eran los clientes. A ellos tampoco les importaba en qué lenguaje estaba escrito Viaweb, pero notaron que funcionaba realmente bien. Les permitía construir tiendas en línea de gran apariencia literalmente en minutos. Y así, principalmente de boca en boca, obtuvimos más y más usuarios. A finales de 1996 teníamos alrededor de 70 tiendas en línea. A finales de 1997 teníamos 500. Seis meses después, cuando Yahoo nos compró, teníamos 1070 usuarios. Hoy, como Yahoo Store, este software continúa dominando su mercado. Es una de las piezas más rentables de Yahoo, y las tiendas construidas con él son la base de Yahoo Shopping. Dejé Yahoo en 1999, así que no sé exactamente cuántos usuarios tienen ahora, pero la última vez que escuché había alrededor de 20,000.

La Paradoja de Blub

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

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

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 hoy estarían de acuerdo en que no deseas, normalmente, programar en lenguaje de máquina. En su lugar, deberías programar en un lenguaje de alto nivel y hacer que un compilador lo traduzca a lenguaje de máquina por ti. Esta idea incluso está 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 es un error escribir todo tu programa a mano en lenguaje de máquina. Lo que se entiende menos a menudo es que hay un principio más general aquí: que si tienes la opción de varios lenguajes, es, todas las demás cosas siendo iguales, un error programar en cualquier cosa que no sea el más poderoso. [3]

Hay muchas excepciones a esta regla. Si estás escribiendo un programa que tiene que trabajar muy de cerca con un programa escrito en un cierto lenguaje, podría ser una buena idea escribir el nuevo programa en el mismo lenguaje. Si estás escribiendo un programa que solo tiene que hacer algo muy simple, como procesamiento de números o manipulación de bits, puedes usar un lenguaje menos abstracto, especialmente ya que puede ser ligeramente más rápido. Y si estás escribiendo un programa corto y desechable, puede que te convenga simplemente usar el lenguaje que tenga las mejores funciones de biblioteca para la tarea. Pero en general, para software de aplicación, quieres usar el lenguaje más poderoso (razonablemente eficiente) que puedas conseguir, y usar cualquier otra cosa es un error, del mismo tipo, aunque posiblemente en menor grado, que programar en lenguaje de máquina.

Puedes ver que el lenguaje de máquina es muy de bajo nivel. Pero, al menos como una especie de convención social, los lenguajes de alto nivel a menudo se tratan como equivalentes. No lo son. Técniamente, el término "lenguaje de alto nivel" no significa nada muy definido. No hay una línea divisoria con los lenguajes de máquina de un lado y todos los lenguajes de alto nivel del otro. Los lenguajes caen a lo largo de un continuo [4] de abstracción, desde el más poderoso hasta los lenguajes de máquina, que a su vez varían en poder.

Considera Cobol. Cobol es un lenguaje de alto nivel, en el sentido de que se compila en lenguaje de máquina. ¿Alguien argumentaría seriamente que Cobol es equivalente en poder a, digamos, Python? Probablemente está más cerca del lenguaje de máquina que de Python.

¿O qué tal Perl 4? Entre Perl 4 y Perl 5, se añadieron cierres léxicos al lenguaje. La mayoría de los hackers de Perl estarían de acuerdo en que Perl 5 es más poderoso que Perl 4. Pero una vez que has admitido eso, has admitido que un lenguaje de alto nivel puede ser más poderoso que otro. Y sigue inexorablemente que, excepto en casos especiales, deberías usar el más poderoso que puedas conseguir.

Sin embargo, esta idea rara vez se sigue hasta su conclusión. Después de cierta edad, los programadores rara vez cambian de lenguaje voluntariamente. Cualquier lenguaje al que la gente esté acostumbrada tienden a considerar 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 usar un lenguaje hipotético llamado Blub. Blub cae 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 de tu elección).

Mientras nuestro hipotético programador de Blub está mirando hacia abajo en el continuo de poder, sabe que está mirando hacia abajo. Los lenguajes menos poderosos que Blub son obviamente menos poderosos, 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 poder, no se da cuenta de que está mirando hacia arriba. Lo que ve son simplemente lenguajes extraños. Probablemente los considera aproximadamente equivalentes en poder a Blub, pero con toda esta otra cosa complicada añadida. Blub es lo suficientemente bueno para él, porque piensa en Blub.

Sin embargo, cuando cambiamos al punto de vista de un programador que usa cualquiera de los lenguajes más altos en el continuo de poder, descubrimos que él, a su vez, mira hacia abajo a Blub. ¿Cómo puedes hacer algo en Blub? Ni siquiera tiene y.

Por inducción, los únicos programadores en posición de ver todas las diferencias de poder entre los diversos lenguajes son aquellos que entienden el más poderoso. (Esto es probablemente lo que Eric Raymond quiso decir sobre Lisp haciéndote 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 usen, porque dicta la forma en que piensan sobre los programas.

Sé esto por mi propia experiencia, como un chico de secundaria escribiendo programas en Basic. Ese lenguaje ni siquiera soportaba la recursión. Es difícil imaginar escribir programas sin usar recursión, pero no me faltaba en ese momento. Pensaba en Basic. Y era un genio en eso. Maestro de todo lo que veía.

Los cinco lenguajes que Eric Raymond recomienda a los hackers caen en varios puntos del continuo de poder. Dónde caen en relación unos con otros es un tema sensible. Lo que diré es que creo que Lisp está en la cima. Y para apoyar esta afirmación te contaré sobre una de las cosas que encuentro faltantes cuando miro los otros cuatro lenguajes. ¿Cómo puedes hacer algo en ellos, pienso, sin macros? [5]

Muchos lenguajes tienen algo llamado macro. Pero las macros de Lisp son únicas. Y créelo 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 ser diferentes. Para el programador de Blub, el código 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á hecho de objetos de datos de Lisp. Y no en el sentido trivial de que los archivos fuente contienen caracteres, y las cadenas son uno de los tipos de datos soportados por el lenguaje. El código Lisp, después de ser leído por el analizador, está hecho de estructuras de datos que puedes recorrer.

Si entiendes cómo funcionan los compiladores, lo que realmente está sucediendo no es tanto que Lisp tenga una sintaxis extraña como 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 a tus programas. Puedes escribir programas que los manipulen. En Lisp, estos programas se llaman 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í está, ¿qué tal eso? Pero si lo hiciera, simplemente parecería un galimatías para alguien que no conociera Lisp; no hay espacio aquí para explicar todo lo que necesitarías saber para entender lo que significaba. En Ansi Common Lisp traté de avanzar lo más rápido que pude, y aun así no llegué a las macros hasta la página 160.

Pero creo que puedo dar un tipo de argumento que podría ser convincente. El código fuente del editor de Viaweb era probablemente alrededor del 20-25% macros. Las macros son más difíciles de escribir que las funciones Lisp ordinarias, y se considera de mal gusto usarlas cuando no son necesarias. Así que 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 en este programa está haciendo cosas que no puedes hacer fácilmente en ningún otro lenguaje. Sin importar cuán escéptico pueda ser el programador de Blub sobre mis afirmaciones sobre los poderes misteriosos de Lisp, esto debería hacerle sentir curiosidad. No estábamos escribiendo este código para nuestro propio entretenimiento. Éramos una pequeña startup, programando tan duro como podíamos para poner barreras técnicas entre nosotros y nuestros competidores.

Una persona sospechosa podría comenzar a preguntarse si había alguna correlación aquí. Un gran trozo de nuestro código estaba haciendo 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 seguir ese hilo. Puede que haya más en ese anciano cojeando con sus muletas de lo que parece.

Aikido para Startups

Pero no espero convencer a nadie (más de 25) de salir y 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 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 tus competidores no lo entienden.

Si piensas en usar Lisp en una startup, no deberías preocuparte de que no se entienda ampliamente. Deberías esperar que se mantenga así. Y es probable que lo haga. Es la naturaleza de los lenguajes de programación hacer que la mayoría de las personas estén satisfechas con lo que actualmente usan. El hardware de computadora cambia mucho más rápido que los hábitos personales, por lo que la práctica de programación suele estar diez a veinte años detrás del procesador. En lugares como MIT estaban escribiendo programas en lenguajes de alto nivel a principios de la década de 1960, pero muchas empresas continuaron escribiendo código en lenguaje de máquina hasta bien entrada la década de 1980. Apuesto a que muchas personas continuaron escribiendo en lenguaje de máquina hasta que el procesador, como un barman ansioso por cerrar y volver a casa, finalmente los echó al cambiar a un conjunto de instrucciones RISC.

Ordinary technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They're half technology and half religion.[6] And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg. Garbage collection, introduced by Lisp in about 1960, is now widely considered to be a good thing. Runtime typing, ditto, is growing in popularity. Lexical closures, introduced by Lisp in the early 1970s, are now, just barely, on the radar screen. Macros, introduced by Lisp in the mid 1960s, are still terra incognita.

Obviamente, el lenguaje medio tiene un enorme impulso. No estoy proponiendo que puedas luchar contra esta poderosa fuerza. Lo que estoy proponiendo es exactamente lo contrario: que, como un practicante de Aikido, puedes usarlo en contra de tus oponentes.

Si trabajas para una gran empresa, esto puede no ser fácil. Tendrás dificultades para convencer al jefe de cabello puntiagudo de que te deje construir cosas en Lisp, cuando acaba de leer en el periódico que algún otro lenguaje está a punto, como Ada hace veinte años, de conquistar el mundo. Pero si trabajas para una startup que aún no tiene jefes de cabello puntiagudo, puedes, como hicimos nosotros, convertir la paradoja de Blub a tu favor: puedes usar tecnología que tus competidores, pegados inmoviblemente al lenguaje medio, nunca podrán igualar.

Si alguna vez te encuentras trabajando para una startup, aquí hay un consejo útil para evaluar a los competidores. Lee sus ofertas de trabajo. Todo lo demás en su sitio puede ser fotos de archivo o el equivalente en prosa, pero las ofertas de trabajo tienen que ser específicas sobre lo que quieren, o conseguirán a los candidatos equivocados.

Durante los años que trabajamos en Viaweb leí muchas descripciones de trabajo. Un nuevo competidor parecía surgir de la nada cada mes más o menos. Lo primero que hacía, después de verificar si tenían una demostración en línea activa, era mirar sus ofertas de trabajo. Después de un par de años de esto, podía decir qué empresas debían preocuparme y cuáles no. Cuanto más sabor a TI tenían las descripciones de trabajo, menos peligrosa era la empresa. El tipo más seguro era el que quería experiencia en Oracle. Nunca tenías que preocuparte por esos. También estabas a salvo 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 comienza a sonar como una empresa donde, al menos, el lado técnico está dirigido por verdaderos hackers. Si alguna vez hubiera visto una oferta de trabajo buscando hackers de Lisp, realmente me habría preocupado.

Notas

[1] Viaweb al principio tenía dos partes: el editor, escrito en Lisp, que las personas usaban para construir sus sitios, y el sistema de pedidos, escrito en C, que manejaba los pedidos. La primera versión era mayormente Lisp, porque el sistema de pedidos era pequeño. Más tarde añadimos dos módulos más, un generador de imágenes escrito en C, y un gestor de back-office escrito mayormente en Perl.

En enero de 2003, Yahoo lanzó una nueva versión del editor escrita en C++ y Perl. 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 son todavía, hasta donde sé, código Lisp. (Ver La Décima Regla de Greenspun.)

[2] Robert Morris dice que no necesitaba ser secreto, 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 formalmente definible, pero una forma de explicarlo sería decir que se refiere a características que solo podrías 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 cadenas y el lenguaje B no, eso probablemente no hace que A sea más poderoso, porque probablemente puedes escribir una subrutina para hacerlo en B. Pero si A soporta, digamos, recursión, y B no, eso no es algo que puedas arreglar 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 muy aumentada por otras características de Lisp como los cierres léxicos y los parámetros rest.

[6] Como resultado, las comparaciones de lenguajes de programación o bien toman la forma de guerras religiosas o de libros de texto de pregrado tan decididamente neutrales que son realmente obras de antropología. Las personas que valoran su paz, o quieren tenure, evitan el tema. Pero la pregunta es solo medio religiosa; hay algo que vale la pena estudiar, especialmente si quieres diseñar nuevos lenguajes.