Superando a los Promedios | undefined | Ensayos de Paul Graham

¿Quieres empezar una startup? Obtén financiación de Y Combinator.

Abril 2001, rev. Abril 2003

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

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

Por supuesto, mucha gente podría 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 nombramos a la empresa en su honor: Viaweb, porque nuestro software funcionaba a través de la web, en lugar de ejecutarse en tu ordenador 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 importantes para usuarios finales escrita 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, dice a los aspirantes a hackers qué lenguajes deben 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 administración de sistemas y scripts cgi. Finalmente, el hacker verdaderamente serio debería considerar aprender Lisp:

Aprender Lisp vale la pena 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.

Este es el mismo argumento que se suele escuchar para aprender latín. No te conseguirá un trabajo, excepto quizás como profesor de clásicas, 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 cualquier 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 se le ofreciera un pincel que lo hiciera un mejor pintor, ¿no crees que querría usarlo en todas sus pinturas? No estoy tratando de burlarme de Eric Raymond aquí. En general, sus consejos son buenos. Lo que dice sobre Lisp es bastante 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? Los lenguajes de programación son solo herramientas, después de todo. Si Lisp realmente produce mejores programas, deberías usarlo. Y si no, ¿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 escribe software más rápido y mejor, manteniendo todo lo demás igual, pondrá a sus competidores fuera del negocio. Y cuando estás empezando 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 veíamos 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 eligieras la tecnología de esa manera, estarías ejecutando Windows. Cuando eliges tecnología, tienes que ignorar lo que hacen los demás 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. Así que si diriges una empresa grande 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 diriges 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 irás a la quiebra. La tasa de supervivencia de las startups es mucho menor al cincuenta por ciento. Así que si diriges una startup, más vale que estés haciendo algo raro. Si no, estás en problemas.

En 1995, sabíamos algo que creo que nuestros competidores no entendieron, y pocos entienden incluso ahora: cuando escribes software que solo tiene que ejecutarse en tus propios servidores, puedes usar cualquier lenguaje que quieras. Cuando escribes 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.

Sin embargo, esta nueva libertad es un arma de doble filo. 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 empezando de cero, por lo que una empresa que pudiera completar 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 software en el momento en que está listo.

Si otras empresas no querían usar Lisp, 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 negocios. No sabíamos nada de marketing, ni de contratar gente, ni de recaudar dinero, ni de conseguir clientes. Ninguno de los dos había tenido siquiera 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, seríamos capaces de completar funciones más rápido que nuestros competidores, y también de hacer cosas en nuestro software que ellos no podían hacer. Y como Lisp era tan de alto nivel, no necesitaríamos un gran equipo de desarrollo, por lo que nuestros costos serían menores. Si esto fuera así, podríamos ofrecer un mejor producto por menos dinero, y aun así obtener ganancias. Terminaríamos consiguiendo todos los usuarios, y nuestros competidores no obtendrían ninguno, y eventualmente quebrarían. Al menos eso era lo que esperábamos que sucediera.

¿Cuáles fueron los resultados de este experimento? Sorprendentemente, funcionó. Eventualmente tuvimos 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 en línea wysiwyg que se ejecutaba en el servidor y aun así 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, desesperados, 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 uno o dos días después de que un competidor la anunciara en un comunicado de prensa. Para cuando los periodistas que cubrían el comunicado de prensa nos llamaban, nosotros también tendríamos la nueva característica.

A nuestros competidores les debió parecer 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 creían. Nadie nos filtraba noticias de sus características. Simplemente éramos capaces de desarrollar software más rápido de lo que nadie pensaba posible.

Cuando tenía unos nueve años, tuve en mis manos una copia de The Day of the Jackal, de Frederick Forsyth. El personaje principal es un asesino contratado para matar al presidente de Francia. El asesino tiene que pasar a la policía para llegar a un apartamento que da a la ruta del presidente. Camina junto a ellos, disfrazado de anciano con muletas, y nunca sospechan de él.

Nuestra arma secreta era similar. Escribimos nuestro software en un lenguaje de IA extraño, con una sintaxis bizarra llena de paréntesis. Durante años me molestó que Lisp se describiera 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 así, 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, solo encontrabas los títulos de dos libros en mi biografía. Esto no fue una coincidencia. 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 así.[2]

Las personas que mejor entendían nuestra tecnología eran los clientes. A ellos tampoco les importaba en qué lenguaje estaba escrito Viaweb, pero notaron que funcionaba muy bien. Les permitía crear tiendas en línea geniales literalmente en minutos. Y así, principalmente de boca en boca, conseguimos más y más usuarios. A finales de 1996 teníamos unas 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 creadas con él son la base de Yahoo Shopping. Dejé Yahoo en 1999, así que no sé exactamente cuántos usuarios tienen ahora, pero hasta donde sé, había alrededor de 20.000.

La Paradoja Blub

¿Qué tiene de genial Lisp? Y si Lisp es tan genial, ¿por qué no lo usa todo el mundo? Suenan como 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 es simplemente el lenguaje más potente 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 lento. Por supuesto, ambas respuestas necesitan explicación.

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

Pocos discutirían, al menos, que los lenguajes de alto nivel son más potentes que el lenguaje de máquina. La mayoría de los programadores hoy en día estarían de acuerdo en que no quieres, normalmente, programar en lenguaje de máquina. En cambio, deberías programar en un lenguaje de alto nivel, y que un compilador lo traduzca a lenguaje de máquina por ti. Esta idea está incluso integrada 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.

Todo el mundo sabe que es un error escribir todo tu programa a mano en lenguaje de máquina. Lo que menos se entiende es que hay un principio más general aquí: que si tienes la opción de varios lenguajes, es un error, manteniendo todo lo demás igual, programar en cualquier cosa 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 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 cálculos numéricos o manipulación de bits, 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 te convenga 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 potente (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 de muy 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é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 por un lado y todos los lenguajes de alto nivel por el otro. Los lenguajes caen a lo largo de un continuo[4] de abstracción, desde el más potente hasta los lenguajes de máquina, que a su vez varían en potencia.

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

¿O qué tal 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 potente que Perl 4. Pero una vez que admites eso, admites que un lenguaje de alto nivel puede ser más potente que otro. Y se deduce inexorablemente que, excepto en casos especiales, deberías usar el más potente que puedas conseguir.

Sin embargo, esta idea rara vez se lleva a su conclusión. Después de cierta edad, los programadores rara vez cambian de lenguaje voluntariamente. Cualquiera que sea el lenguaje al que la gente esté acostumbrada, tienden 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 usar un lenguaje hipotético llamado Blub. Blub se encuentra justo en el medio del continuo de abstracción. No es el lenguaje más potente, pero es más potente 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 nadie puede hacer nada con él. Ni siquiera tiene x (característica de Blub de tu elección).

Mientras nuestro programador hipotético de Blub mire 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 programador hipotético 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 meramente lenguajes extraños. Probablemente los considera aproximadamente equivalentes en potencia a Blub, pero con todo este otro material complicado añadido. Blub es suficiente 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 potencia, sin embargo, encontramos que a su vez mira con desdén 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 potencia entre los diversos lenguajes son aquellos que entienden el más potente. (Esto es probablemente lo que Eric Raymond quiso decir sobre que Lisp te hace un mejor programador). No puedes confiar en las opiniones de los demás, debido a la paradoja Blub: están satisfechos con cualquier lenguaje que usen, porque dicta la forma en que piensan sobre los programas.

Lo sé por mi propia experiencia, como un adolescente que escribía programas en Basic. Ese lenguaje ni siquiera soportaba la recursión. Es difícil imaginar escribir programas sin usar recursión, pero en ese momento no la echaba de menos. Pensaba en Basic. Y era un genio en ello. Maestro de todo lo que veía.

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

Muchos lenguajes tienen algo llamado macro. Pero las macros de Lisp son únicas. Y lo creas 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 Blub, el código Lisp se ve extraño. 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 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 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 para 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 potente, y decir ¡mira! ¿qué tal eso? Pero si lo hiciera, solo parecería galimatías para alguien que no supiera Lisp; no hay espacio aquí para explicar todo lo que necesitarías saber para entender lo que significaba. En Ansi Common Lisp intenté 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 era probablemente entre un 20% y un 25% 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. Así que cada macro en ese código está ahí porque tiene que estarlo. 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. Por escéptico que sea el programador Blub sobre mis afirmaciones de los misteriosos poderes de Lisp, esto debería darle curiosidad. No estábamos escribiendo este código para nuestra propia diversión. Éramos una pequeña startup, programando lo más duro que podíamos para poner barreras técnicas entre nosotros y nuestros competidores.

Una persona sospechosa podría empezar 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 seguir ese hilo. Puede haber más en ese anciano cojeando con sus muletas de lo que parece.

Aikido para Startups

Pero no espero convencer a nadie (mayores 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 ya interesadas en usar Lisp, personas que saben que Lisp es un lenguaje potente, pero se preocupan porque no está ampliamente utilizado. En una situación competitiva, eso es una ventaja. La potencia 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 esté ampliamente entendido. Deberías esperar que siga así. Y es probable que lo haga. Es la naturaleza de los lenguajes de programación que la mayoría de las personas se satisfagan 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 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 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 continuó escribiendo lenguaje de máquina hasta que el procesador, como un camarero ansioso por cerrar e irse a casa, finalmente los expulsó al cambiar a un conjunto de instrucciones risc.

Normalmente la tecnología cambia rápido. 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í, el lenguaje mediano, es decir, el lenguaje que usa el programador mediano, se mueve tan lento como un iceberg. La recolección de basura, introducida por Lisp alrededor de 1960, ahora es ampliamente considerada algo bueno. La tipificación en tiempo de ejecución, lo mismo, está ganando popularidad. Los cierres léxicos, introducidos por Lisp a principios de la década de 1970, ahora están, apenas, en el 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 propongo que puedas luchar contra esta poderosa fuerza. Lo que propongo es exactamente lo contrario: que, como un practicante de Aikido, puedes usarlo contra tus oponentes.

Si trabajas para una empresa grande, esto puede no ser fácil. Tendrás dificultades para convencer al jefe de pelo 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 de, como Ada hace veinte años, apoderarse del mundo. Pero si trabajas para una startup que aún no tiene jefes de pelo puntiagudo, puedes, como hicimos nosotros, usar la paradoja Blub a tu favor: puedes usar tecnología que tus competidores, pegados inamoviblemente al lenguaje mediano, nunca podrán igualar.

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

Durante los años que trabajamos en Viaweb leí muchas descripciones de puestos. Cada mes o así parecía surgir un nuevo competidor. Lo primero que hacía, después de comprobar si tenían una demostración en línea en vivo, era mirar sus ofertas de empleo. Después de un par de años de esto, podía saber qué empresas debían preocuparme y cuáles no. Cuanto más sabor a TI tuvieran las descripciones de los puestos, menos peligrosa era la empresa. Las más seguras eran las que querían experiencia en Oracle. Nunca tenías que preocuparte por esas. 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 empieza a sonar como una empresa donde el lado técnico, al menos, está dirigido por hackers reales. Si alguna vez hubiera visto una oferta de empleo buscando hackers de Lisp, me habría preocupado mucho.

Notas

[1] Viaweb tuvo inicialmente 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 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 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++ literalmente tuvieron que escribir un intérprete de Lisp: los archivos fuente de todas las plantillas que generan páginas siguen siendo, hasta donde yo sé, código Lisp. (Ver 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 listos, ya estarían programando en Lisp."

[3] Todos los lenguajes son igualmente potentes en el sentido de ser Turing equivalentes, pero ese no es el sentido de la palabra que importa a los programadores. (Nadie quiere programar una máquina de Turing.) El tipo de potencia que 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 potente escribiendo un intérprete para el lenguaje más potente en él. Si el lenguaje A tiene un operador para eliminar espacios de las cadenas y el lenguaje B no, eso probablemente no hace a A más potente, 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, que se estrecha hacia arriba; no es la forma lo que importa aquí, sino la idea de que existe 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 restantes.

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