SUPERANDO LOS PROMEDIOS
Abril de 2001, revisado Abril de 2003.
(Este artículo se deriva de una conferencia pronunciada en el Simposio de Desarrolladores Franz en 2001)
En el verano de 1995, mi amigo Robert Morris y yo comenzamos una nueva empresa llamada Viaweb. Nuestro plan era escribir software que le permitiera a los usuarios finales crear tiendas en línea. La novedad acerca de este software, en ese momento, era que corría en nuestro servidor, utilizando páginas Web ordinarias como interfaz.
Mucha gente podría haber tenido esta idea al mismo tiempo, por supuesto, pero hasta donde sé, Viaweb fue la primera aplicación basada en Web. Nos parecía una idea tan novedosa que nombramos la empresa de acuerdo a ello: Viaweb, ya que nuestro software trabajaba a través de la Web, en lugar de ejecutarse en una computadora de escritorio.
Otra cosa inusual acerca de este software es que fue escrito principalmente en un lenguaje de programación llamado Lisp. Fue una de las primeras grandes aplicaciones para usuarios finales a ser escrita en Lisp, que hasta entonces había sido utilizado sobre todo 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 este, entre otras cosas, le dice a los aspirantes a hackers [a] qué lenguajes deben aprender. Sugiere comenzar con Python y Java, ya que son fáciles de aprender. El hacker serio también querrá aprender C, con el fin de hackear Unix y Perl para administración de sistemas y scripts cgi. Por último, el hacker realmente serio debe considerar aprender Lisp:
Vale la pena aprender Lisp por la profunda experiencia de iluminación que obtendrás cuando finalmente lo comprendas, esa experiencia te hará un mejor programador por el resto de tus días, incluso si nunca utilizas Lisp mucho.
Este es el mismo argumento que tiendes a escuchar para aprender Latín. No te va a conseguir un trabajo, excepto tal vez como profesor de clásicos, pero mejorará tu mente y te hará un mejor escritor en idiomas que desees utilizar, como el Inglés.
Pero espera un minuto. Esta metáfora no se extiende tan lejos. 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 te entenderá. Pero Lisp es un lenguaje de programación, y las computadoras hablan el lenguaje que tú, el programador, les digas.
Así que 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, me parece que querria usarlo en todos sus cuadros, ¿no? No estoy tratando de burlarme de Eric Raymond aquí. En general, su consejo es bueno. Lo que dice acerca de 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? Los lenguajes de programación son sólo herramientas, después de todo. Si Lisp realmente produce mejores programas, deberías usarlo. Y si no es así, entonces ¿quién lo necesita?
Esto no es sólo una cuestión teórica. El software es un negocio muy competitivo, con tendencia a los monopolios naturales. Una empresa que consiga escribir software más rápido y mejor pondrá, todas las cosas en igualdad de condiciones, a sus competidores fuera del negocio. Y cuando estás iniciando una startup [b], sentirás esto muy profundamente. Las startups tienden a ser una proposición de todo o nada. O te haces rico, o no consigues nada. En una startup, si apuestas a la tecnología equivocada, tus competidores te aplastaran.
Robert y yo conocíamos Lisp bien, y no veíamos ninguna razón para no confiar en nuestros instintos e ir con Lisp. Sabíamos que todo el mundo estaba 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ás ejecutando Windows. Al elegir la tecnología, hay que ignorar lo que hacen los demás y considerar sólo lo que funcionará mejor.
Esto es especialmente cierto en una startup. En una empresa grande, puedes hacer lo que todas las otras empresas grandes están haciendo. Sin embargo, en una startup no puedes hacer lo que todas las demás hacen. No creo que mucha gente se dé cuenta de esto, incluso en las startups.
La gran empresa promedio crece aproximadamente un diez por ciento al año. Así que si estás administrando una gran empresa y haces todo de la manera en que la gran empresa promedio lo hace, puedes esperar hacerlo tan bien como la gran empresa promedio: es decir, un crecimiento de alrededor del diez por ciento al año.
Lo mismo ocurrirá si se está dirigiendo una startup, por supuesto. Si haces todo de la forma en que la startup promedio lo hace, debes esperar el rendimiento promedio. El problema aquí es, que el rendimiento promedio significa que irás a la quiebra. La tasa de supervivencia para startups es menor al cincuenta por ciento. Así que 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 creo, nuestros competidores no entendían, y pocos entienden, incluso ahora: cuando estás escribiendo software que sólo tiene que ejecutarse en tus propios servidores, puedes utilizar cualquier lenguaje que desees. Cuando se está escribiendo software de escritorio, hay una fuerte tendencia hacia la creación de aplicaciones en el mismo lenguaje que el sistema operativo. Hace diez años, escribir aplicaciones significaba la creación de aplicaciones en C. Pero con software basado en Web, sobre todo cuando se tiene el código fuente tanto del lenguaje como del sistema operativo, puedes utilizar cualquier lenguaje que desees.
Sin embargo, esta nueva libertad es una espada de doble filo. Ahora que puedes utilizar cualquier lenguaje, tienes que pensar acerca de cuál usar. Las compañías que pretenden fingir que nada ha cambiado corren el riesgo de descubrir que sus competidores no lo hacen.
Si puedes utilizar cualquier lenguaje, ¿cual utilizas? Elegimos Lisp. Por un lado, era obvio que el desarrollo rápido sería importante en este mercado. Todos estábamos empezando desde cero, por lo que una empresa que pudiera conseguir sacar nuevas características antes que sus competidores tendria una gran ventaja. Sabíamos que Lisp era un lenguaje muy bueno para escribir software rápido, y las aplicaciones basadas en servidor magnifican el efecto de un rápido desarrollo, ya que puedes liberar el software al minuto que se hace.
Si otras empresas no querían usar Lisp, tanto mejor. Podría ser que nos diera una ventaja tecnológica, y necesitábamos toda la ayuda que pudiéramos conseguir. Cuando empezamos Viaweb, no teníamos experiencia en los negocios. No sabíamos nada acerca de comercialización, o contratación de personas, o recaudación de dinero, o conseguir clientes. Ninguno de nosotros había tenido nunca, incluso, lo que se dice, un trabajo de verdad. Lo único en lo que éramos buenos era escribiendo software. Esperábamos que eso nos salvaría. Cualquier ventaja que pudiéramos obtener en el apartado del software, la tomaríamos.
Por lo tanto 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 implementar prestaciones más rápido que nuestros competidores, y también hacer cosas en nuestro software que ellos no podrían. Y como Lisp era de tan alto nivel, no necesitaríamos un gran equipo de desarrollo, por lo que los costos serían menores. Si esto fuera así, podríamos ofrecer un mejor producto por menos dinero, y aún así, obtener utilidades. Terminaríamos consiguiendo todos los usuarios, nuestros competidores no obtendrían ninguno, y eventualmente quebrarian. En cualquier caso, eso era lo que esperábamos que sucediera.
¿Cuáles fueron los resultados de este experimento? Sorprendentemente, de alguna manera, funcionó. Llegamos a tener muchos competidores, del orden de veinte a treinta, pero ningúno de ellos podía competir con nuestro software. Teníamos un creador de tiendas en línea del tipo WYSIWYG que corría 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 funciones. A veces, en su desesperación, nuestros competidores trataban de introducir funciones que no teníamos. Pero con Lisp nuestro ciclo de desarrollo era tan rápido que a veces podíamos duplicar una nueva función un día o dos después que un competidor lo anunciara en un comunicado de prensa. Para cuando los periodistas que cubrían la noticia nos llamaban, también teníamos la nueva función.
A nuestros competidores debió haberles parecido que teníamos algún tipo de arma secreta― que estábamos descifrando su tráfico de mensajes Enigma [c] o algo así. De hecho, sí teníamos un arma secreta, pero era más sencilla de lo que se imaginaban. Nadie estaba filtrando información de sus funciones para nosotros. Simplemente éramos capaces de desarrollar software más rápido de lo que nadie creía posible.
Cuando tenía unos nueve años pude hacerme con un ejemplar del libro 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 a la policía para llegar hasta el apartamento que da a la ruta del presidente. Camina justo a un lado de ellos, disfrazado como un anciano con muletas, y nunca sospechan de él.
Nuestra arma secreta era similar. Escribimos nuestro software en un extraño lenguaje de IA, con una sintaxis extraña llena de paréntesis. Durante años me había molestado escuchar a Lisp ser 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 entienden. En los negocios, como en la guerra, la sorpresa vale tanto como la fuerza.
Así, estoy un poco avergonzado al decir que nunca dije nada en público sobre Lisp, mientras estábamos trabajando en Viaweb. Nunca se lo mencionamos a la prensa, y si buscabas algo de Lisp en nuestro sitio Web, todo lo que ibas a encontrar eran los títulos de dos libros en mi biografía. Esto no fue un accidente. Una startup debe dar a sus competidores tan poca información como sea posible. Si ellos no sabían en qué lenguaje estaba escrito nuestro software, o no les importaba, yo quería mantenerlo de esa manera [2].
La gente que mejor entendió nuestra tecnología fueron los clientes. Tampoco les importaba en que lenguaje estaba escrito Viaweb, pero se dieron cuenta de que funcionaba muy bien. Los dejaba crear tiendas en línea visualmente grandiosas, literalmente, en cuestión de minutos. Y así, de boca en boca, sobre todo, conseguimos 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 más tarde, cuando Yahoo nos compró, teníamos 1,070 usuarios. Hoy en día, como Yahoo Store, este software sigue dominando el mercado. Es una de las piezas más rentables de Yahoo, y las tiendas creadas con ella son la base de Yahoo Shopping. Salí de Yahoo en 1999, así que no sé exactamente cuántos usuarios tienen ahora, pero lo último que escuche es que había cerca de 20,000.
Pero espera un minuto. Esta metáfora no se extiende tan lejos. 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 te entenderá. Pero Lisp es un lenguaje de programación, y las computadoras hablan el lenguaje que tú, el programador, les digas.
Así que 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, me parece que querria usarlo en todos sus cuadros, ¿no? No estoy tratando de burlarme de Eric Raymond aquí. En general, su consejo es bueno. Lo que dice acerca de 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? Los lenguajes de programación son sólo herramientas, después de todo. Si Lisp realmente produce mejores programas, deberías usarlo. Y si no es así, entonces ¿quién lo necesita?
Esto no es sólo una cuestión teórica. El software es un negocio muy competitivo, con tendencia a los monopolios naturales. Una empresa que consiga escribir software más rápido y mejor pondrá, todas las cosas en igualdad de condiciones, a sus competidores fuera del negocio. Y cuando estás iniciando una startup [b], sentirás esto muy profundamente. Las startups tienden a ser una proposición de todo o nada. O te haces rico, o no consigues nada. En una startup, si apuestas a la tecnología equivocada, tus competidores te aplastaran.
Robert y yo conocíamos Lisp bien, y no veíamos ninguna razón para no confiar en nuestros instintos e ir con Lisp. Sabíamos que todo el mundo estaba 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ás ejecutando Windows. Al elegir la tecnología, hay que ignorar lo que hacen los demás y considerar sólo lo que funcionará mejor.
Esto es especialmente cierto en una startup. En una empresa grande, puedes hacer lo que todas las otras empresas grandes están haciendo. Sin embargo, en una startup no puedes hacer lo que todas las demás hacen. No creo que mucha gente se dé cuenta de esto, incluso en las startups.
La gran empresa promedio crece aproximadamente un diez por ciento al año. Así que si estás administrando una gran empresa y haces todo de la manera en que la gran empresa promedio lo hace, puedes esperar hacerlo tan bien como la gran empresa promedio: es decir, un crecimiento de alrededor del diez por ciento al año.
Lo mismo ocurrirá si se está dirigiendo una startup, por supuesto. Si haces todo de la forma en que la startup promedio lo hace, debes esperar el rendimiento promedio. El problema aquí es, que el rendimiento promedio significa que irás a la quiebra. La tasa de supervivencia para startups es menor al cincuenta por ciento. Así que 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 creo, nuestros competidores no entendían, y pocos entienden, incluso ahora: cuando estás escribiendo software que sólo tiene que ejecutarse en tus propios servidores, puedes utilizar cualquier lenguaje que desees. Cuando se está escribiendo software de escritorio, hay una fuerte tendencia hacia la creación de aplicaciones en el mismo lenguaje que el sistema operativo. Hace diez años, escribir aplicaciones significaba la creación de aplicaciones en C. Pero con software basado en Web, sobre todo cuando se tiene el código fuente tanto del lenguaje como del sistema operativo, puedes utilizar cualquier lenguaje que desees.
Sin embargo, esta nueva libertad es una espada de doble filo. Ahora que puedes utilizar cualquier lenguaje, tienes que pensar acerca de cuál usar. Las compañías que pretenden fingir que nada ha cambiado corren el riesgo de descubrir que sus competidores no lo hacen.
Si puedes utilizar cualquier lenguaje, ¿cual utilizas? Elegimos Lisp. Por un lado, era obvio que el desarrollo rápido sería importante en este mercado. Todos estábamos empezando desde cero, por lo que una empresa que pudiera conseguir sacar nuevas características antes que sus competidores tendria una gran ventaja. Sabíamos que Lisp era un lenguaje muy bueno para escribir software rápido, y las aplicaciones basadas en servidor magnifican el efecto de un rápido desarrollo, ya que puedes liberar el software al minuto que se hace.
Si otras empresas no querían usar Lisp, tanto mejor. Podría ser que nos diera una ventaja tecnológica, y necesitábamos toda la ayuda que pudiéramos conseguir. Cuando empezamos Viaweb, no teníamos experiencia en los negocios. No sabíamos nada acerca de comercialización, o contratación de personas, o recaudación de dinero, o conseguir clientes. Ninguno de nosotros había tenido nunca, incluso, lo que se dice, un trabajo de verdad. Lo único en lo que éramos buenos era escribiendo software. Esperábamos que eso nos salvaría. Cualquier ventaja que pudiéramos obtener en el apartado del software, la tomaríamos.
Por lo tanto 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 implementar prestaciones más rápido que nuestros competidores, y también hacer cosas en nuestro software que ellos no podrían. Y como Lisp era de tan alto nivel, no necesitaríamos un gran equipo de desarrollo, por lo que los costos serían menores. Si esto fuera así, podríamos ofrecer un mejor producto por menos dinero, y aún así, obtener utilidades. Terminaríamos consiguiendo todos los usuarios, nuestros competidores no obtendrían ninguno, y eventualmente quebrarian. En cualquier caso, eso era lo que esperábamos que sucediera.
¿Cuáles fueron los resultados de este experimento? Sorprendentemente, de alguna manera, funcionó. Llegamos a tener muchos competidores, del orden de veinte a treinta, pero ningúno de ellos podía competir con nuestro software. Teníamos un creador de tiendas en línea del tipo WYSIWYG que corría 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 funciones. A veces, en su desesperación, nuestros competidores trataban de introducir funciones que no teníamos. Pero con Lisp nuestro ciclo de desarrollo era tan rápido que a veces podíamos duplicar una nueva función un día o dos después que un competidor lo anunciara en un comunicado de prensa. Para cuando los periodistas que cubrían la noticia nos llamaban, también teníamos la nueva función.
A nuestros competidores debió haberles parecido que teníamos algún tipo de arma secreta― que estábamos descifrando su tráfico de mensajes Enigma [c] o algo así. De hecho, sí teníamos un arma secreta, pero era más sencilla de lo que se imaginaban. Nadie estaba filtrando información de sus funciones para nosotros. Simplemente éramos capaces de desarrollar software más rápido de lo que nadie creía posible.
Cuando tenía unos nueve años pude hacerme con un ejemplar del libro 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 a la policía para llegar hasta el apartamento que da a la ruta del presidente. Camina justo a un lado de ellos, disfrazado como un anciano con muletas, y nunca sospechan de él.
Nuestra arma secreta era similar. Escribimos nuestro software en un extraño lenguaje de IA, con una sintaxis extraña llena de paréntesis. Durante años me había molestado escuchar a Lisp ser 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 entienden. En los negocios, como en la guerra, la sorpresa vale tanto como la fuerza.
Así, estoy un poco avergonzado al decir que nunca dije nada en público sobre Lisp, mientras estábamos trabajando en Viaweb. Nunca se lo mencionamos a la prensa, y si buscabas algo de Lisp en nuestro sitio Web, todo lo que ibas a encontrar eran los títulos de dos libros en mi biografía. Esto no fue un accidente. Una startup debe dar a sus competidores tan poca información como sea posible. Si ellos no sabían en qué lenguaje estaba escrito nuestro software, o no les importaba, yo quería mantenerlo de esa manera [2].
La gente que mejor entendió nuestra tecnología fueron los clientes. Tampoco les importaba en que lenguaje estaba escrito Viaweb, pero se dieron cuenta de que funcionaba muy bien. Los dejaba crear tiendas en línea visualmente grandiosas, literalmente, en cuestión de minutos. Y así, de boca en boca, sobre todo, conseguimos 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 más tarde, cuando Yahoo nos compró, teníamos 1,070 usuarios. Hoy en día, como Yahoo Store, este software sigue dominando el mercado. Es una de las piezas más rentables de Yahoo, y las tiendas creadas con ella son la base de Yahoo Shopping. Salí de Yahoo en 1999, así que no sé exactamente cuántos usuarios tienen ahora, pero lo último que escuche es que había cerca de 20,000.
La Paradoja Blub
¿Qué hay de grandioso en Lisp? Y si Lisp es tan grandioso, ¿por qué no lo utiliza todo el mundo? Estas suenan como preguntas retóricas, pero en realidad tienen respuestas sencillas. Lisp es grandioso no por alguna cualidad mágica visible sólo para los devotos, sino simplemente porque es el lenguaje más potente disponible. Y la razón por la que no todos lo usan es que los lenguajes de programación no son sólo tecnologías, sino hábitos de la mente también, y nada cambia mas lento. Por supuesto, estas dos respuestas necesitan explicación.
Empezaré con una declaración sorprendentemente polémica: los lenguajes de programación varían en potencia.
Pocos cuestionaran, al menos, que los lenguajes de alto nivel son más potentes que el lenguaje de máquina. La mayoría de los programadores de hoy estarán de acuerdo en que normalmente no querrías programar en lenguaje de máquina. En su lugar, se deberá programar en un lenguaje de alto nivel, y tener un compilador que traduzca a lenguaje de máquina por ti. Esta idea esta incluso integrada en el hardware de hoy: desde la década de 1980 los conjuntos de instrucciones han sido diseñados para los compiladores más que para los programadores humanos.
Todo el mundo sabe que es un error escribir todo tu programa a mano en lenguaje de máquina. Lo que con mayor frecuencia es menos comprendido es que hay un principio más general aquí: si tienes una opción de varios lenguajes, es, todas las cosas en igualdad de condiciones, un error programar en otra cosa que no sea el más potente. [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 lenguaje determinado, sería 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 cálculo de números o manipulación de bits, es posible también utilizar un lenguaje menos abstracto, sobre todo porque puede ser un poco más rápido. Y si estás escribiendo un programa corto, para usar y desechar, puede ser mejor utilizar sólo el lenguaje que tenga las mejores funciones de biblioteca para la tarea. Pero, en general, para software de aplicación, deseas usar el lenguaje más potente (razonablemente eficiente) que puedas conseguir, y usar cualquier otra cosa es un error, exactamente del mismo tipo, aunque posiblemente en menor grado, como 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 son a menudo tratados todos 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 continuum [4] de abstracción, desde el más potente hasta abajo a 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. ¿Trataría alguien seriamente de argumentar que Cobol es equivalente en potencia a, por ejemplo, Python? Es probablemente más cercano a lenguaje de máquina que Python.
¿O qué tal Perl 4? Entre Perl 4 y Perl 5, se añadieron clausuras léxicas al lenguaje. La mayoría de los hackers de Perl estarán de acuerdo en que Perl 5 es más potente que Perl 4. Pero una vez que admites esto, has admitido que un lenguaje de alto nivel puede ser más potente que otro. Y se sigue inexorablemente qué, salvo en casos especiales, debes utilizar el más potente que puedas conseguir.
Sin embargo esta idea rara vez es seguida hasta su conclusión. Después de una cierta edad, los programadores rara vez cambian de lenguaje de forma voluntaria. Cualquiera sea el lenguaje al que están acostumbrados, tienden a considerarlo lo suficientemente bueno.
Los programadores son muy apegados a sus lenguajes preferidos, y no quiero herir los sentimientos de nadie, por lo que para explicar este punto voy a utilizar un lenguaje hipotético llamado Blub. Blub cae justo en medio del continuum 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 hipotético programador Blub no utilizara ninguno de ellos. Por supuesto que no programara en lenguaje de máquina. Para eso son los compiladores. Y en cuanto a Cobol, no sabe cómo alguien pueda hacer algo con él. Ni siquiera tiene x (la función Blub de tu elección).
En tanto nuestro hipotético programador Blub está observando hacia abajo del continuum de poder, sabe que está mirando hacia abajo. Lenguajes menos potentes que Blub son obviamente menos potentes, porque carecen de alguna característica a la que está acostumbrado. Pero cuando nuestro hipotético programador Blub mira en la otra dirección, hacia la parte alta del continuum de poder, no se da cuenta que está mirando hacia arriba. Lo que ve simplemente son lenguajes extraños. Es probable que los considere equivalentes en poder a Blub, pero con todas esas otras cosas peludas incluidas también. Blub es lo suficientemente bueno para él, porque piensa en Blub.
Sin embargo, cuando cambiamos hasta el punto de vista de un programador usando cualquiera de los lenguajes más arriba en el continuum de poder, nos encontramos con que 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 para ver todas las diferencias de poder entre los distintos lenguajes son los que entienden el más potente. (Esto es probablemente lo que Eric Raymond quería decir acerca de que Lisp te haría un mejor programador.) No puedes confiar en las opiniones de los demás, debido a la paradoja Blub: están satisfechos con el lenguaje que usan, ya que determina su manera de pensar acerca de los programas.
Lo sé por mi propia experiencia, como un chico de bachillerato que escribía programas en Basic. Ese lenguaje ni siquiera soportaba la recursividad. Es difícil imaginar la escritura de programas sin utilizar la recursividad, pero en su momento no lo extrañaba. Pensaba en Basic. Y era un genio en eso. Maestro de todos los encuestados.
Los cinco lenguajes que Eric Raymond recomienda a los hackers caen en varios puntos del continuum de poder. Dónde caen respecto a los otros es un tema delicado. Lo que diré es que creo que Lisp esta en la parte superior. Y para apoyar esta afirmación te diré una de las cosas que me parece que faltan cuando miro a los otros cuatro lenguajes. ¿Cómo puedes hacer algo en ellos, creo, sin las macros? [5]
Muchos lenguajes tienen algo que se llama una macro. Sin embargo, las macros de Lisp son únicas. 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 sólo para ser diferentes. Para el programador Blub, el código de Lisp luce raro. Sin embargo, los paréntesis están allí por una razón. Son la evidencia externa de una diferencia fundamental entre Lisp y otros lenguajes.
El código Lisp se hace de los datos de objetos 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 Lisp, después de que ha sido leído por el analizador, se compone de estructuras de datos que se pueden recorrer.
Si sabes cómo funcionan los compiladores, lo que sucede en realidad 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 en el compilador cuando se analizan otros lenguajes. Sin embargo, estos árboles de análisis son totalmente accesibles a 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 potente, y decir: ¡Helo ahí! ¿Qué tal eso? Pero si lo hiciera, se verían sólo como garabatos para alguien que no conoce Lisp, no hay espacio aquí para explicar todo lo que se necesita saber para entender lo que significa. En ANSI Common Lisp traté de llevar las cosas tan rápido como pude, y aún 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 Viaweb era probablemente cerca de 20-25% macros. Las macros son más difíciles de escribir que las funciones Lisp ordinarias, y es considerado como un mal estilo utilizarlas cuando no son necesarias. Así que cada macro en ese código está ahí porque tiene que estarlo. Lo que esto significa es que al menos un 20-25% del código de este programa esta haciendo cosas que no podrías hacer fácilmente en cualquier otro lenguaje. Sin importar que tan escéptico pueda estar el programador Blub acerca de mis argumentos por los misteriosos poderes de Lisp, esto debería hacerlo curioso. No estábamos escribiendo este código para nuestra propia diversión. Éramos una pequeña startup, programando tan duro como podíamos para poner obstáculos técnicos entre nosotros y nuestros competidores.
Una persona suspicaz puede empezar a preguntarse si habrá 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 hizo cosas que el software de nuestros competidores no podía hacer. Tal vez haya algún tipo de conexión. Te invito a seguir ese hilo. Puede haber más de lo que parece en ese viejo cojeando sobre muletas.
Empezaré con una declaración sorprendentemente polémica: los lenguajes de programación varían en potencia.
Pocos cuestionaran, al menos, que los lenguajes de alto nivel son más potentes que el lenguaje de máquina. La mayoría de los programadores de hoy estarán de acuerdo en que normalmente no querrías programar en lenguaje de máquina. En su lugar, se deberá programar en un lenguaje de alto nivel, y tener un compilador que traduzca a lenguaje de máquina por ti. Esta idea esta incluso integrada en el hardware de hoy: desde la década de 1980 los conjuntos de instrucciones han sido diseñados para los compiladores más que para los programadores humanos.
Todo el mundo sabe que es un error escribir todo tu programa a mano en lenguaje de máquina. Lo que con mayor frecuencia es menos comprendido es que hay un principio más general aquí: si tienes una opción de varios lenguajes, es, todas las cosas en igualdad de condiciones, un error programar en otra cosa que no sea el más potente. [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 lenguaje determinado, sería 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 cálculo de números o manipulación de bits, es posible también utilizar un lenguaje menos abstracto, sobre todo porque puede ser un poco más rápido. Y si estás escribiendo un programa corto, para usar y desechar, puede ser mejor utilizar sólo el lenguaje que tenga las mejores funciones de biblioteca para la tarea. Pero, en general, para software de aplicación, deseas usar el lenguaje más potente (razonablemente eficiente) que puedas conseguir, y usar cualquier otra cosa es un error, exactamente del mismo tipo, aunque posiblemente en menor grado, como 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 son a menudo tratados todos 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 continuum [4] de abstracción, desde el más potente hasta abajo a 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. ¿Trataría alguien seriamente de argumentar que Cobol es equivalente en potencia a, por ejemplo, Python? Es probablemente más cercano a lenguaje de máquina que Python.
¿O qué tal Perl 4? Entre Perl 4 y Perl 5, se añadieron clausuras léxicas al lenguaje. La mayoría de los hackers de Perl estarán de acuerdo en que Perl 5 es más potente que Perl 4. Pero una vez que admites esto, has admitido que un lenguaje de alto nivel puede ser más potente que otro. Y se sigue inexorablemente qué, salvo en casos especiales, debes utilizar el más potente que puedas conseguir.
Sin embargo esta idea rara vez es seguida hasta su conclusión. Después de una cierta edad, los programadores rara vez cambian de lenguaje de forma voluntaria. Cualquiera sea el lenguaje al que están acostumbrados, tienden a considerarlo lo suficientemente bueno.
Los programadores son muy apegados a sus lenguajes preferidos, y no quiero herir los sentimientos de nadie, por lo que para explicar este punto voy a utilizar un lenguaje hipotético llamado Blub. Blub cae justo en medio del continuum 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 hipotético programador Blub no utilizara ninguno de ellos. Por supuesto que no programara en lenguaje de máquina. Para eso son los compiladores. Y en cuanto a Cobol, no sabe cómo alguien pueda hacer algo con él. Ni siquiera tiene x (la función Blub de tu elección).
En tanto nuestro hipotético programador Blub está observando hacia abajo del continuum de poder, sabe que está mirando hacia abajo. Lenguajes menos potentes que Blub son obviamente menos potentes, porque carecen de alguna característica a la que está acostumbrado. Pero cuando nuestro hipotético programador Blub mira en la otra dirección, hacia la parte alta del continuum de poder, no se da cuenta que está mirando hacia arriba. Lo que ve simplemente son lenguajes extraños. Es probable que los considere equivalentes en poder a Blub, pero con todas esas otras cosas peludas incluidas también. Blub es lo suficientemente bueno para él, porque piensa en Blub.
Sin embargo, cuando cambiamos hasta el punto de vista de un programador usando cualquiera de los lenguajes más arriba en el continuum de poder, nos encontramos con que 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 para ver todas las diferencias de poder entre los distintos lenguajes son los que entienden el más potente. (Esto es probablemente lo que Eric Raymond quería decir acerca de que Lisp te haría un mejor programador.) No puedes confiar en las opiniones de los demás, debido a la paradoja Blub: están satisfechos con el lenguaje que usan, ya que determina su manera de pensar acerca de los programas.
Lo sé por mi propia experiencia, como un chico de bachillerato que escribía programas en Basic. Ese lenguaje ni siquiera soportaba la recursividad. Es difícil imaginar la escritura de programas sin utilizar la recursividad, pero en su momento no lo extrañaba. Pensaba en Basic. Y era un genio en eso. Maestro de todos los encuestados.
Los cinco lenguajes que Eric Raymond recomienda a los hackers caen en varios puntos del continuum de poder. Dónde caen respecto a los otros es un tema delicado. Lo que diré es que creo que Lisp esta en la parte superior. Y para apoyar esta afirmación te diré una de las cosas que me parece que faltan cuando miro a los otros cuatro lenguajes. ¿Cómo puedes hacer algo en ellos, creo, sin las macros? [5]
Muchos lenguajes tienen algo que se llama una macro. Sin embargo, las macros de Lisp son únicas. 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 sólo para ser diferentes. Para el programador Blub, el código de Lisp luce raro. Sin embargo, los paréntesis están allí por una razón. Son la evidencia externa de una diferencia fundamental entre Lisp y otros lenguajes.
El código Lisp se hace de los datos de objetos 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 Lisp, después de que ha sido leído por el analizador, se compone de estructuras de datos que se pueden recorrer.
Si sabes cómo funcionan los compiladores, lo que sucede en realidad 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 en el compilador cuando se analizan otros lenguajes. Sin embargo, estos árboles de análisis son totalmente accesibles a 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 potente, y decir: ¡Helo ahí! ¿Qué tal eso? Pero si lo hiciera, se verían sólo como garabatos para alguien que no conoce Lisp, no hay espacio aquí para explicar todo lo que se necesita saber para entender lo que significa. En ANSI Common Lisp traté de llevar las cosas tan rápido como pude, y aún 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 Viaweb era probablemente cerca de 20-25% macros. Las macros son más difíciles de escribir que las funciones Lisp ordinarias, y es considerado como un mal estilo utilizarlas cuando no son necesarias. Así que cada macro en ese código está ahí porque tiene que estarlo. Lo que esto significa es que al menos un 20-25% del código de este programa esta haciendo cosas que no podrías hacer fácilmente en cualquier otro lenguaje. Sin importar que tan escéptico pueda estar el programador Blub acerca de mis argumentos por los misteriosos poderes de Lisp, esto debería hacerlo curioso. No estábamos escribiendo este código para nuestra propia diversión. Éramos una pequeña startup, programando tan duro como podíamos para poner obstáculos técnicos entre nosotros y nuestros competidores.
Una persona suspicaz puede empezar a preguntarse si habrá 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 hizo cosas que el software de nuestros competidores no podía hacer. Tal vez haya algún tipo de conexión. Te invito a seguir ese hilo. Puede haber más de lo que parece en ese viejo cojeando sobre muletas.
Aikido para Startups
Pero no espero convencer a nadie (mayor de 25) a salir y aprender Lisp. No es el propósito de este artículo cambiar la forma de pensar de nadie, sino tranquilizar a las personas ya interesadas en el uso de Lisp, —personas que saben que Lisp es un lenguaje potente—, pero que se preocupan porque no se utiliza mucho. En una situación de competencia, eso es una ventaja. El poder de Lisp se multiplica por el hecho de que tus competidores no lo entienden.
Si piensas utilizar Lisp en una startup, no debería preocuparte el que no sea ampliamente comprendido. Deberías esperar que esto siga siendo así. Lo cual es muy probable. Es la naturaleza de los lenguajes de programación hacer que la mayoría de las personas se sientan satisfechas con lo que actualmente utilizan. El hardware de computación cambia mucho más rápido que los hábitos personales, tanto, que la práctica de la programación esta generalmente de diez a veinte años 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 continuó escribiendo en lenguaje de máquina hasta que el procesador, como un cantinero con ganas de cerrar y volver a casa, finalmente los echó cambiando a un conjunto de instrucciones risc.
Por lo general la tecnología cambia rápido. Sin embargo, los lenguajes de programación son diferentes: los lenguajes de programación no son sólo tecnología, sino lo que los programadores piensan. Son mitad tecnología y mitad religión.[6] Así que el lenguaje medio, es decir, el lenguaje que utiliza el programador medio, se mueve tan lento como un iceberg. La recolección de basura, introducida por Lisp alrededor de 1960, es ahora ampliamente considerada como una cosa buena. La escritura en tiempo de ejecución, ídem, está creciendo en popularidad. Las clausuras léxicas, introducidas por Lisp a principios de 1970, están apenas ahora en la pantalla del radar. Las macros, introducidas por Lisp a mediados de 1960, siguen siendo terra incognita.
Evidentemente, el lenguaje medio tiene enorme impulso. No estoy proponiendo que se puede luchar contra esta fuerza poderosa. Lo que estoy proponiendo es exactamente lo contrario: que, como un practicante de Aikido, se puede utilizar contra tus oponentes.
Si trabajas para una empresa grande, puede que esto no sea fácil. Pasarás un rato difícil tratando de convencer al jefe de pelo-puntiagudo [d] para que te permita crear cosas en Lisp, cuando acaba de leer en el periódico que otro lenguaje está a punto, al igual que Ada hace veinte años, de apoderarse del mundo. Pero si trabajas para una startup que no tiene jefes de pelo-puntiagudo todavía, puedes, como lo hicimos, inclinar la paradoja Blub a tu favor: puedes utilizar tecnología que tus competidores, apegados inamoviblemente al lenguaje medio, nunca serán capaces de 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. Es probable que todo lo demás en su sitio sean fotos o su equivalente en prosa, pero las ofertas de trabajo tienen que ser específicas acerca de lo que quieren, u obtendrán los candidatos equivocados.
Durante los años que trabaje en Viaweb leí muchas descripciones de puestos. Un nuevo competidor parecía surgir de la nada cada mes. Lo primero que hacia, después de comprobar si había una demostración en línea, era mirar las ofertas de trabajo. Después de un par de años de esto, me di cuenta de cuáles empresas debía preocuparme y de cuáles no. Mientras más tenían las ofertas de trabajo un tinte empresarial, a Tecnologías de la Información, menos peligrosa era la compañía. Las más seguras eran las que querían experiencia en Oracle. No tenias que preocuparte 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, era un poco aterrador— empezaba a sonar como una empresa donde el aspecto técnico, al menos, estaba a cargo de verdaderos hackers. Si en alguna ocasión hubiera visto una oferta de trabajo solicitando programadores Lisp, habría estado muy preocupado.
Notas
[1] En un principio Viaweb constaba de dos partes: el editor, escrito en Lisp, que la gente utilizaba para crear sus sitios, y el sistema de pedidos, escrito en C, que manejaba las ordenes. La primera versión era en su mayoría Lisp, ya que el sistema de pedidos era pequeño. Posteriormente añadimos dos módulos más, un generador de imágenes escrito en C, y un gestor back-office escrito en su mayoría en Perl.
En enero de 2003, Yahoo lanzó una nueva versión del editor escrito en C++ y Perl. Sin embargo es difícil decir si el programa ya no está escrito en Lisp, porque para traducir este programa en C++ literalmente tuvieron que escribir un intérprete de Lisp: los archivos fuente de todas las plantillas generadoras de paginas siguen siendo, hasta donde yo sé, código Lisp. (Vease Regla Decima de Greenspun.)
[2] Robert Morris dice que no tenía que ser tan 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 potentes en el sentido de ser equivalentes de Turing, pero ese no es el sentido de la palabra que les interesa a los programadores. (Nadie quiere programar una máquina de Turing.) El tipo de potencia que les interesa a los programadores no puede ser formalmente definido, pero una manera de explicarlo sería decir que se refiere a funciones que sólo se podrían conseguir en el lenguaje menos potente escribiendo un intérprete para el lenguaje más potente en este. Si el lenguaje A tiene un operador para la eliminación de los espacios de las cadenas y el lenguaje B no lo tiene, eso probablemente no hace a A más potente, ya que probablemente sea posible escribir una subrutina para hacerlo en B. Pero si por ejemplo A admite recursividad, y B no lo hace, es probable que sea algo que no se pueda arreglar escribiendo funciones de biblioteca.
[4] Nota para los nerds: o posiblemente una red, que se estrecha en 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 función separada. En la práctica su utilidad es mejorada en gran medida por otras características de Lisp como clausuras lexicas y parámetros rest.
[6] Como resultado, la comparación de lenguajes de programación toman ya sea la forma de guerras religiosas o libros de texto de pasantes tan decididamente neutrales que en realidad son obras de antropología. Las personas que valoran su paz, o desean una plaza, evitan el tema. Pero la pregunta es sólo la mitad de religiosa, hay algo ahí que vale la pena estudiar, sobre todo si deseas diseñar nuevos lenguajes.
*Traducido del original Beating The Averages por Paul Graham. Traducción: Armando Alvarez con la asesoría técnica de Hanedi Salas.
Notas del Traductor
[a] En La Palabra "Hacker" Paul Graham nos da una buena descripción del sentido en que hay que entender esta palabra: “Para la prensa popular, "hacker" significa alguien que irrumpe en las computadoras. Entre los programadores significa: un buen programador. Pero los dos sentidos están conectados. Para los programadores, "hacker" connota dominio en el sentido más literal: alguien que puede hacer que una computadora haga lo que él quiere—ya sea que la computadora quiera o no.”
[b] El termino startup define a una empresa de reciente creación orientada a la tecnología. En Como Financiar una Startup encontramos la siguiente descripción: "Una empresa tiene que ser más que pequeña y de reciente creación para ser una startup. Hay millones de pequeñas empresas en Estados Unidos, pero sólo unas pocas miles son startups. Para ser una startup, una compañía tiene que ser un negocio de productos, no un negocio de servicios. Lo que no quiere decir que tiene que hacer algo físico, sino que tiene que tener una cosa que vende a mucha gente, en vez de hacer trabajos a medida para clientes individuales. El trabajo sobre encargo no es escalable. Para ser una startup tienes que ser la banda que vende un millón de copias de una canción, no el grupo que gana dinero tocando en bodas y Bar Mitzvahs individuales."
[c] Enigma era el nombre de una máquina que disponía de un mecanismo de cifrado rotatorio, que permitía usarla tanto para cifrar como para descifrar mensajes. Varios de sus modelos fueron muy utilizados en Europa desde inicios de los años 1920.
Su fama se debe a haber sido adoptada por las fuerzas militares de Alemania desde 1930. Su facilidad de manejo y supuesta inviolabilidad fueron las principales razones para su amplio uso. Su sistema de cifrado fue finalmente descubierto y la lectura de la información que contenían los mensajes supuestamente protegidos es considerado, a veces, como la causa de haber podido concluir la Segunda Guerra Mundial al menos dos años antes de lo que hubiera acaecido sin su descifrado. [Fuente: Wikipedia. Ver.]