SUPERANDO LOS PROMEDIOS

Abril 2001, rev. Abril 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 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.

Muchas personas podrían haber tenido esta idea al mismo tiempo, por supuesto, pero que yo sepa, Viaweb fue la primera aplicación web. Nos parecía una idea tan novedosa que le pusimos el nombre a la compañía: Viaweb, porque nuestro software funcionaba a través de la web, en lugar de ejecutarse en tu computadora de escritorio.

Otra cosa inusual de este software era que estaba escrito principalmente en un lenguaje de programación llamado Lisp. Fue una de las primeras aplicaciones de usuario final importantes que se escribieron 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 futuros hackers qué lenguajes deben 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 administración de sistemas 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 uses realmente Lisp mucho.

Este es el mismo argumento que sueles 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 sí quieres usar, como el inglés.

Pero espera un minuto. 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 el idioma que tú, el programador, les digas.

Entonces, si Lisp te hace un mejor programador, como él dice, ¿por qué no querrías usarlo? Si a un pintor le ofrecieran un pincel que lo haría un mejor pintor, me parece que querría usarlo en todos sus cuadros, ¿no? No estoy tratando de burlarme de Eric Raymond aquí. 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? Al fin y al cabo, los lenguajes de programación son solo herramientas. Si Lisp realmente produce mejores programas, deberías usarlo. Y si no, entonces, ¿quién lo necesita?

Esta no es solo una pregunta teórica. El software es un negocio muy competitivo, propenso a los monopolios naturales. Una empresa que escribe software más rápido y mejor, todo lo demás siendo igual, sacará a sus competidores del negocio. Y cuando estás comenzando una startup, sientes esto muy intensamente. Las startups tienden a ser una proposición 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 e ir con 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 eligieras tecnología de esa manera, estarías ejecutando Windows. Cuando eliges tecnología, tienes que ignorar lo que hacen otras personas y considerar solo lo que funcionará mejor.

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

La empresa grande promedio crece alrededor del diez por ciento al año. Entonces, si estás dirigiendo una empresa grande y haces todo como lo hace la empresa grande promedio, puedes esperar tener un desempeño 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 desempeño promedio. El problema aquí es que el desempeño promedio significa que te irás a la quiebra. La tasa de supervivencia de las startups es mucho menos del cincuenta por ciento. Entonces, si estás dirigiendo una startup, más vale 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 quieras. 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 quieras.

Esta nueva libertad es una espada de doble filo, sin embargo. Ahora que puedes usar cualquier lenguaje, tienes que pensar en cuál usar. Las empresas que intentan fingir 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 partiendo de cero, así que una empresa que pudiera hacer 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 servidores amplifican el efecto del desarrollo rápido, porque puedes lanzar software en el momento en que se termina.

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 los negocios. No sabíamos nada sobre marketing, o contratar gente, o recaudar dinero, o conseguir clientes. Ninguno de nosotros había tenido lo que se podría llamar un trabajo real. Lo único en lo que éramos buenos era en escribir software. Esperábamos que eso nos salvara. Cualquier ventaja que pudiéramos obtener en el departamento de software, la tomaríamos.

Así que se podría decir que usar Lisp fue un experimento. Nuestra hipótesis era que si escribíamos nuestro software en Lisp, podríamos completar las características más rápido que nuestros competidores, y también hacer cosas en nuestro software que ellos no podrían hacer. Y debido a que Lisp era tan de alto nivel, no necesitaríamos un gran equipo de desarrollo, por lo 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 a 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 sus programas 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 intentarían introducir características que 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 pusieran en contacto con nosotros, también tendríamos la nueva característica.

Debe haber parecido a nuestros competidores que teníamos algún tipo de arma secreta, que estábamos descifrando su tráfico Enigma o algo así. De hecho, teníamos un arma secreta, pero era más simple de lo que se daban cuenta. Nadie les estaba filtrando noticias sobre sus características a nosotros. Simplemente podíamos desarrollar software más rápido de lo que cualquiera pensaba posible.

Cuando tenía alrededor de nueve años, tuve la oportunidad de conseguir una copia de The Day of the Jackal, 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. Camina justo delante 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 ha molestado escuchar a Lisp descrito 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 entiendan. En los negocios, como en la guerra, la sorpresa vale tanto como la fuerza.

Y así, me avergüenza un poco decir, 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 serían los títulos de dos libros en mi biografía. Esto no fue un accidente. 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]

Las personas que mejor entendían nuestra tecnología eran los clientes. Tampoco les importaba en qué lenguaje estaba escrito Viaweb, pero notaron que funcionaba realmente bien. Les permitía construir excelentes tiendas en línea literalmente en minutos. Y así, en su mayor parte por el boca a 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 sigue 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 me enteré había alrededor de 20,000.

La Paradoja de Blub

¿Qué tiene de tan genial Lisp? Y si Lisp es tan genial, ¿por qué no lo usa todo el mundo? Estas parecen preguntas retóricas, pero en realidad tienen respuestas sencillas. Lisp es tan genial no por alguna cualidad mágica visible solo para los devotos, sino porque simplemente es 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 simplemente tecnologías, sino también hábitos mentales, y nada cambia más lentamente. Por supuesto, ambas respuestas necesitan 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 no quieres, por lo general, programar en lenguaje de máquina. En su lugar, debes programar en un lenguaje de alto nivel y hacer que un compilador lo traduzca al 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 se han diseñado para compiladores en lugar de programadores humanos.

Todos saben que es un error escribir todo tu programa a mano en lenguaje de máquina. Lo que se entiende con menos frecuencia es que hay un principio más general aquí: que si tienes una elección entre varios lenguajes, es, todo lo demás siendo igual, un error programar en cualquier cosa que no sea el más poderoso.[3]

Hay muchas excepciones a esta regla. Si está escribiendo un programa que tiene que funcionar muy de cerca con un programa escrito en un cierto lenguaje, puede ser una buena idea escribir el nuevo programa en el mismo lenguaje. Si está escribiendo un programa que solo tiene que hacer algo muy simple, como cálculos numéricos o manipulación de bits, puede usar un lenguaje menos abstracto, especialmente si puede ser un poco más rápido. Y si está escribiendo un programa corto y desechable, es posible que le convenga usar el lenguaje que tenga las mejores funciones de biblioteca para la tarea. Pero en general, para el software de aplicación, quiere estar usando el lenguaje más poderoso (razonablemente eficiente) que pueda conseguir, y usar cualquier otra cosa es un error, del mismo tipo, aunque posiblemente en un grado menor, que programar en lenguaje de máquina.

Puede ver que el lenguaje de máquina es muy de bajo nivel. Pero, al menos como una especie de convención social, a menudo se trata a los lenguajes de alto nivel 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 con los lenguajes de máquina a un lado y todos los lenguajes de alto nivel al otro. Los lenguajes se encuentran a lo largo de un continuo [4] de abstracción, desde los más poderosos hasta los lenguajes de máquina, que a su vez varían en poder.

Considere 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 Python.

¿O qué hay de Perl 4? Entre Perl 4 y Perl 5, se agregaron 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 haya admitido eso, ha admitido que un lenguaje de alto nivel puede ser más poderoso que otro. Y se sigue inexorablemente que, excepto en casos especiales, debe usar el más poderoso que pueda conseguir.

Esta idea rara vez se sigue hasta su conclusión, sin embargo. Después de cierta edad, los programadores rara vez cambian de lenguaje voluntariamente. Cualquier lenguaje al que la gente esté acostumbrada, tienden a considerarlo simplemente 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 programador hipotético de Blub no usaría ninguno de ellos. Por supuesto que no programaría en lenguaje de máquina. Para eso están los compiladores. Y en cuanto a Cobol, no sabe cómo puede hacer algo con él. Ni siquiera tiene x (característica de Blub de su elección).

Mientras nuestro programador hipotético 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 programador hipotético 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 raros. Probablemente los considere aproximadamente equivalentes en poder a Blub, pero con todo este otro material complicado también. Blub es lo suficientemente bueno para él, porque piensa en Blub.

Cuando cambiamos al punto de vista de un programador que usa cualquiera de los lenguajes más arriba en el continuo de poder, sin embargo, encontramos que a su vez mira hacia abajo a Blub. ¿Cómo puede 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. (Probablemente esto es lo que Eric Raymond quiso decir sobre Lisp haciéndote un mejor programador). No se puede 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 estudiante de secundaria escribiendo programas en Basic. Ese lenguaje ni siquiera admitía recursión. Es difícil imaginar escribir programas sin usar recursión, pero no la echaba de menos en ese momento. Pensaba en Basic. Y era un as en eso. Maestro de todo lo que abarcaba.

Los cinco lenguajes que Eric Raymond recomienda a los hackers se ubican en varios puntos del continuo de poder. Dónde se ubican en relación 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é sobre una de las cosas que encuentro que falta cuando miro a los otros cuatro lenguajes. ¿Cómo pueden hacer algo sin macros? [5]

Muchos lenguajes tienen algo llamado macro. Pero los macros de Lisp son únicos. Y créanlo 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 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 de Lisp está hecho de objetos de datos de Lisp. Y no en el sentido trivial de que los archivos de origen contienen caracteres y las cadenas son uno de los tipos de datos admitidos por el lenguaje. El código de Lisp, después de que lo lee el analizador, está hecho de estructuras de datos que se pueden recorrer.

Si entiende 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. Escribe 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 sus programas. Puede 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, solo parecería jerga para alguien que no conociera Lisp; no hay espacio aquí para explicar todo lo que necesitarías saber para entender lo que significa. 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 una especie de argumento que podría ser convincente. El código fuente del editor de Viaweb probablemente era aproximadamente un 20-25% de macros. Las macros son más difíciles de escribir que las funciones Lisp ordinarias, y se considera un mal estilo usarlas cuando no son necesarias. Entonces cada macro en ese código está allí porque tiene que estar. Lo que eso significa es que al menos el 20-25% de este código está haciendo cosas que no se pueden hacer fácilmente en ningún otro lenguaje. Por muy escéptico que el programador Blub pueda ser sobre mis afirmaciones sobre los misteriosos poderes de Lisp, esto debería hacerlo curioso. No estábamos escribiendo este código para nuestro propio entretenimiento. Éramos una startup diminuta, programando lo más duro que 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í. Una gran parte 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 que sigas ese hilo. Puede haber más en ese viejo hombre cojeando con sus muletas de lo que parece.

Aikido para Startups

Pero no espero convencer a nadie (más de 25) para que salga y aprenda 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, esa 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 siga siendo así. Y es probable que lo sea. Es la naturaleza de los lenguajes de programación hacer que la mayoría de las personas se conformen con lo que usan actualmente. El hardware de las computadoras cambia mucho más rápido que los hábitos personales, por lo que la práctica de programación suele estar de 10 a 20 años por detrás del procesador. En lugares como el 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 mucha gente siguió escribiendo lenguaje de máquina hasta que el procesador, como un camarero ansioso por cerrar y irse a casa, finalmente los echó cambiando a un conjunto de instrucciones RISC.

Normalmente, la tecnología cambia rápidamente. Pero los lenguajes de programación son diferentes: los lenguajes de programación no son solo tecnología, sino en lo que piensan los programadores. Son mitad tecnología y mitad religión.[6] Y así la mediana del lenguaje, lo que significa cualquier lenguaje que use el programador mediano, se mueve tan lento como un iceberg. La recolección de basura, introducida por Lisp alrededor de 1960, ahora se considera ampliamente una cosa buena. El tipado en tiempo de ejecución, igual, está ganando popularidad. Los cierres léxicos, introducidos por Lisp a principios de la década de 1970, ahora, apenas, están en la pantalla radar. Las macros, introducidas por Lisp a mediados de la década de 1960, siguen siendo terra incognita.

Obviamente, el lenguaje mediano 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 usarla contra tus oponentes.

Si trabajas para una empresa grande, esto puede no ser fácil. Tendrás dificultades para convencer al jefe de cabeza puntiaguda de que te permita construir cosas en Lisp, cuando acaba de leer en el periódico que otro lenguaje está a punto, como Ada hace veinte años, de dominar el mundo. Pero si trabajas para una startup que aún no tiene jefes de cabeza puntiaguda, puedes, como lo hicimos nosotros, aprovechar la paradoja de Blub a tu ventaja: puedes usar tecnología que tus competidores, pegados de manera inamovible al lenguaje mediano, 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 listados de empleos. Todo lo demás en su sitio web puede ser fotos de stock o el equivalente en prosa, pero los listados de empleos deben ser específicos sobre lo que quieren, o obtendrán los candidatos equivocados.

Durante los años que trabajamos en Viaweb, leí muchas descripciones de trabajos. Parecía que surgía un nuevo competidor de la nada cada mes más o menos. Lo primero que haría, después de verificar si tenían una demostración en línea activa, sería mirar sus listados de empleos. Después de un par de años de esto, podía decir qué empresas preocuparse y cuáles no. Cuanto más sabor a TI tuvieran las descripciones de trabajo, menos peligrosa era la empresa. Los más seguros eran los que querían 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 es dirigido por hackers reales. Si alguna vez hubiera visto un anuncio de trabajo buscando 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 construir sus sitios, y el sistema de pedidos, escrito en C, que manejaba los pedidos. La primera versión era principalmente 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 oficina trasera escrito principalmente en Perl.

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

[2] Robert Morris dice que no necesitaba ser discreto, porque incluso si nuestros competidores hubieran sabido que estábamos usando Lisp, no lo 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 Turing equivalentes, pero ese no es el sentido de la palabra que a los programadores les importa. (Nadie quiere programar una máquina de Turing). El tipo de poder que a los programadores les importa 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 del lenguaje más poderoso en él. Si el lenguaje A tiene un operador para eliminar espacios de las cadenas y el lenguaje B no lo tiene, probablemente eso no hace que A sea más poderoso, porque probablemente puedas escribir una subrutina para hacerlo en B. Pero si A admite, digamos, recursión, y B no, es poco probable que sea algo que puedas arreglar escribiendo funciones de biblioteca.

[4] Nota para los nerds: o posiblemente una retícula, 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 a las macros como una característica separada. En la práctica, su utilidad se ve muy mejorada 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 adoptan la forma de guerras religiosas o de libros de texto universitarios tan determinadamente neutrales que en realidad son obras de antropología. Las personas que valoran su paz, o quieren la titularidad, evitan el tema. Pero la pregunta solo es la mitad de religiosa; hay algo allí que vale la pena estudiar, especialmente si quieres diseñar nuevos lenguajes.