Original article: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

La maldición de Lisp

 

De Rudolf Winestock

 

Este ensayo es otro intento de reconciliar el poder del lenguaje de programación Lisp con la incapacidad de la comunidad Lisp para reproducir sus logros previos a la IA de invierno . Sin duda, Lisp ha sido una fuente influyente de ideas incluso durante su época de retiro. Ese hecho, además del brillo de las diferentes arquitecturas Lisp Machine, y el renacimiento actual Lisp después de más de una década en el desierto demuestran que los partidarios Lisp debe tener alguna justificación para su presunción. Sin embargo, no han podido traducir el poder de Lisp en un movimiento con un impulso abrumador.

En este ensayo, argumento que el poder expresivo de Lisp es en realidad una causa de su falta de impulso.

 

 

El poder de Lisp es su peor enemigo.

Aquí hay un experimento mental para demostrarlo: Tome dos lenguajes de programación, ninguno de los cuales está orientado a objetos. Su misión, si decide aceptarla, es hacerlas orientadas a objetos, manteniéndolas compatibles con los idiomas originales, modulo algunos casos de borde. Insertar cualquier par de lenguajes de programación en este experimento de pensamiento mostrará que esto es más fácil con algunos idiomas que con otros. Ese es el punto del experimento mental. He aquí un ejemplo trivial: Intercal y Pascal.

Ahora haga interesante este experimento de pensamiento: Imagine añadir orientación de objeto a los lenguajes de programación C y Scheme. Hacer Esquema orientado a objetos es una asignación de tarea de segundo año. Por otro lado, la adición de la orientación del objeto a C requiere las chuletas de programación de Bjarne Stroustrup.

Las consecuencias de esta divergencia en el talento necesario y la causa del esfuerzo La maldición Lisp :

Lisp es tan poderoso que los problemas que son problemas técnicos en otros lenguajes de programación son problemas sociales en Lisp.


Consideremos nuevamente el caso de Scheme. Puesto que hacer Scheme orientado a objetos es tan fácil, muchos hackers Scheme lo han hecho. Más al punto, muchos piratas individualesScheme lo han hecho. En la década de 1990, esto llevó a una verdadera lista de inventario de almacenes de paquetes orientados a objetos para el lenguaje. La Paradoja de la Elección , por sí sola, garantizaba que ninguno de ellos se convertiría en estándar. Ahora que algunas implementaciones Scheme tienen sus propias instalaciones de orientación de objetos, no es tan malo. Sin embargo, el hecho de que muchos de estos paquetes eran el trabajo de individuos solos condujo a los problemas que Olin Shivers escribió en documentar el Scheme Shell, scsh.

Los programas escritos por los hackers individuales tienden a seguir el modelo de rascarse-uno-picor. Estos programas resolverán el problema que el hacker, él mismo, está teniendo sin necesariamente manejar partes relacionadas del problema que harían el programa más útil para otros. Además, el programa está seguro de trabajar en la configuración de ese hacker solitario, pero no puede ser portátil para otras implementaciones de Scheme o para la misma implementación de Scheme en otras plataformas. Puede que falte documentación. Siendo esencialmente un proyecto hecho en tiempo libre copioso del hacker, el programa es susceptible de sufrir si las responsabilidades de la vida real se entrometen en el hacker. Como notó Olin Shivers, esto significa que estos proyectos de una sola banda tienden a resolver el ochenta por ciento del problema.

El ensayo del Dr. Mark Tarver, The Bipolar Lisp Programmer , tiene una descripción adecuada de este fenómeno.Escribe de estos piratas informáticos Lisp solitarios y sus

... incapacidad para terminar las cosas correctamente. La frase "diseño desechable" es absolutamente hecha para el BBM y viene de la comunidad de Lisp. Lisp te permite simplemente tirar las cosas tan fácilmente, y es fácil de tomar esto por sentado. Lo vi hace 10 años cuando buscaba una GUI para mi Lisp. No hay problema, había 9 ofertas diferentes. El problema era que ninguno de los 9 estaban debidamente documentados y ninguno estaba libre de errores.Básicamente cada persona había implementado su propia solución y funcionó para él, así que estaba bien. Esta es una actitud de BBM ; Funciona para mí y lo entiendo. También es el producto de no necesitar o querer la ayuda de nadie para hacer algo.


Una vez más, considere el lenguaje de programación C en ese experimento mental. Debido a la dificultad de hacer C objeto orientado, sólo dos intentos serios en el problema han hecho cualquier tracción: C + + y Objective-C. Objetivo-C es el más popular en Macintosh, mientras que C ++ gobierna en todas partes.Esto significa que, para una plataforma dada, ya se ha respondido definitivamente a la cuestión de qué extensión orientada a objetos de C se debe utilizar. Esto significa que se han documentado las facilidades orientadas a objetos para esos lenguajes, que los entornos de desarrollo integrados son conscientes de ellos, que las bibliotecas de código son compatibles con ellos, y así sucesivamente.

El ensayo del Dr. Mark Tarver sobre Lispers bipolar hace el punto:

Ahora, en contraste, el enfoque C / C ++ es muy diferente. Es tan difícil hacer algo con pinzas y pegamento que cualquier cosa importante que hagas será un logro real. Quieres documentarlo. También es probable que necesite ayuda en cualquier proyecto C de tamaño significativo; Por lo que es susceptible de ser social y trabajar con los demás.Necesitas hacerlo, solo para llegar a alguna parte.

Y todo eso, desde el punto de vista de un empleador, es atractivo. Diez personas que se comunican, documentan las cosas correctamente y trabajan juntas son preferibles a un BBM hacking Lisp que sólo puede ser reemplazado por otro BBM(si puede encontrar uno) en el caso no poco probable que él, en algún momento, bajar sin ser Reinicializable.

Por lo tanto, aquellos que ya conocen C no preguntan "¿Qué sistema de objetos debo aprender?" En su lugar, utilizan C ++ u Objective-C dependiendo de lo que sus colegas están utilizando, a continuación, pasar a "¿Cómo se utiliza la función orientada a objetos X ?" Respuesta: "Goog él y lo encontrará."


Los verdaderos hackers, desde luego, saben desde hace mucho tiempo que la programación orientada a objetos no es la panacea que sus partidarios han reclamado. Real Hackers se han trasladado a conceptos más avanzados como estructuras de datos inmutables, inferencia de tipos, evaluación perezosa, monads, flechas, concordancia de patrones, programación basada en restricciones, etc. Real Hackers también han sabido, por un tiempo, que C y C ++ no son apropiados para la mayoría de los programas que no necesitan hacer arbitrario bit-fiddling. Sin embargo, la maldición Lisp todavía se mantiene.

Algunos amantes de Lisp presumidos han estudiado la cosecha actual de lenguas académicas (Haskell, Ocaml, etcétera) y los encontró desear, diciendo que cualquier característica de los suyos ya está presente en Lisp o puede ser fácilmente implementado - y mejorado - con Lisp Macros Probablemente tengan razón.

Lástima los hackers Lisp.


El Dr. Mark Tarver - dos veces citado, arriba - escribió un dialecto de Lisp llamado Qi . Es menos de diez mil líneas de macros corriendo sobre Clisp. Implementa la mayoría de las características únicas de Haskell y OCaml. En algunos aspectos, Qi los supera. Por ejemplo, el motor de inferencia tipo Qi es Turing completo . En un mundo en el que se necesitaban equipos de talentosos académicos para escribir a Haskell, un hombre, el Dr. Tarver escribió Qi todo por su solitario.

Lea el párrafo, una vez más, y extrapolarlo.


Ejercicio para el lector : Imagínese que se desarrolla una fuerte rivalidad entre Haskell y Common Lisp. ¿Qué pasa después?

Respuesta : La maldición de Lisp entra en acción. Cada segundo o tercer hacker grave de Lisp lanzará su propia aplicación de evaluación perezosa, pureza funcional, flechas, concordancia de patrones, inferencia de tipos y el resto. La mayoría de estos proyectos serán operaciones de lobos solitarios. Por lo tanto, tendrán el ochenta por ciento de las características que la mayoría de la gente necesita (un diferente ochenta por ciento en cada caso). Estarán mal documentados. No serán portátiles a través de los sistemas Lisp.Algunos mostrarán una gran promesa antes de ser abandonados mientras el mantenedor del proyecto se va a pagar sus facturas.Varios golpearán Haskell a lo largo de esta o aquella dimensión (otra vez, una diferente en cada caso), pero su aceptación será obstaculizada por las guerras de la llama en el grupo de comp.lang.lisp Usenet.

Endgame : Una colección de macros de Lisp hackers antiguos al azar se sumará a una implementación indocumentada, infructuosa, bug-ridden del 80% de Haskell porque Lisp es más potente que Haskell.


La moraleja de esta historia es que los efectos secundarios y terciarios importan . La tecnología no sólo afecta lo que podemos hacer con respecto a las cuestiones tecnológicas, también afecta a nuestro comportamiento social. Este comportamiento social puede retroceder y afectar a las cuestiones tecnológicas originales que se están considerando.

Lisp es un ejemplo dolorosamente elocuente de esta lección. Lisp es tan poderoso, que anima la independencia individual hasta el punto de la mente sangrienta. Esta independencia ha producido sorprendentemente buena innovación como en los días de la máquina Lisp. Esta misma independencia también obstaculiza los esfuerzos para revivir el "Lisp todo el camino hacia abajo" los sistemas de la antigüedad; No "Lisp OS" proyecto ha reunido masa crítica desde la desaparición de Symbolics y LMI.

Un resultado de estos efectos secundarios y terciarios es que, incluso si Lisp es el lenguaje más expresivo jamás visto, de modo que es teóricamente imposible hacer un lenguaje más expresivo, Lispers todavía tendrá cosas que aprender de otros lenguajes de programación . Los chicos de Smalltalk enseñaron a todos - incluyendo a los hackers Lisp - una o dos cosas acerca de la programación orientada a objetos. El lenguaje de programación Cleany el combo Mozart / Oz pueden tener algunas sorpresas propias.


La maldición de Lisp no contradice la máxima de Stanislav Datskovskiy : Los empleadores prefieren mucho que los trabajadores sean fungibles, en vez de maximizar la productividad. Demasiado cierto. Con gran dificultad cualquiera plomo la venalidad de la clase directiva. Sin embargo, las últimas líneas de su ensayo son problemáticas. Esto es:

En cuanto al mundo del "software libre", se opone con avidez a los dogmas industriales en la retórica, pero no en absoluto en la práctica. Ningún concepto evitado por los infiernos de la granja del cubo ha ganado nunca la tracción real entre las masas aficionadas.

En una nota de pie de página, ofrece Linux como un ejemplo de esta falta de voluntad para perseguir ideas diferentes. Para ser seguro, él tiene un punto cuando se trata de sistemas operativos(el comentario más alto, en particular, es obviamente enfurecido). Él no tiene un punto cuando se trata de lenguajes de programación.Python y Ruby fueron influenciados por Lisp. Muchos de sus fans expresan respeto por Lisp y parte de su interés ha aumentado el renacimiento Lisp. Con cierta justicia, JavaScript se ha descrito como "Esquema en la ropa de C" a pesar de originar en esos infiernos de la cuba de la granja .

Sin embargo, a pesar de esta influencia, tanto en los mundos corporativos como en los de código abierto, Lisp todavía tiene sólo una fracción de la parte de mente del desarrollador que ha atraído la actual cosecha de lenguajes de scripting avanzados. La cerrada mentalidad de MBA no puede ser la única explicación para esto. La maldición Lisp tiene más poder explicativo.


Los entornos de desarrollo libre disponibles para Lisp ejemplifican más la Maldición Lisp.

Es embarazoso señalar esto, pero debe ser hecho. Olvídate de la máquina Lisp; Ni siquiera tenemos sistemas de desarrollo que coincidan con lo que el hacker Smalltalk promedio da por sentado ("Siempre he sentido Lisp es el lenguaje superior y Smalltalk es el entorno superior." - Ramón León ). A menos que paguen miles de dólares, los hackers de Lisp todavía están atascados con Emacs.

James Gosling, el autor del primer Emacs que funcionó en Unix, ha señalado correctamente que Emacs no ha cambiado fundamentalmente en más de veinte años. Esto se debe a que los mantenedores de Emacs siguen estandardizando el código encima de un diseño que se resolvió cuando Emacs era un proyecto de estudiante graduado en el Laboratorio AI del MIT, es decir, cuando el desarrollo de Emacs seguía siendo financiado indirectamente por la deuda nacional. Un Slashdotter puede objetar que Emacs ya es bastante capaz y puede hacer cualquier cosa que cualquier otro entorno de desarrollo puede hacer, sólo que mejor. Aquellos que han usado Lisp Machines dicen lo contrario.

Entonces, ¿por qué los hackers Lisp no ponen a los Smalltalk en su lugar? ¿Por qué no hacen un sistema de desarrollo gratuito que recuerda algunas de las glorias perdidas del LispM, aunque no puedan reproducir otro LispM?

La razón por la que esto no sucede es a causa de la Maldición Lisp. Un gran número de hackers Lisp tendría que cooperar entre sí. Mire más de cerca: Un gran número de personas que se convierten en hackers Lisp tendría que cooperar entre sí. Y tendrían que cooperar unos con otros en un diseño que no era ya un dado desde el principio. Y no habría ninguna disciplina externa, tal como un capitalista de riesgo u otro maestro corporativo, para mantenerlos en el buen camino.

Cada proyecto tiene fricción entre miembros, desacuerdos, conflictos de estilo y filosofía. Estos problemas sociales son contrarrestados por el hecho de que no se puede lograr un gran proyecto de otra manera. "Debemos todos colgar juntos, o todos vamos a colgar por separado." Pero la expresividad de Lisp hace que esta fuerza compensatoria sea mucho más débil; Uno siempre puede iniciar su propio proyecto. Así, los hackers individuales deciden que el problema no vale la pena. De modo que abandonan el proyecto o no se unen al proyecto para empezar. Esta es la maldición Lisp.

Incluso se podría hackear a Emacs para conseguir algo que sea lo suficientemente bueno . Así, la Maldición Lisp es el aliado de Peor es Mejor.


El poder expresivo de Lisp tiene desventajas. No hay tal cosa como un almuerzo gratis.

 

 

 

 

¿Como la manera que pienso y diseño Web site?¡Contratame!


 Rudolf Winestock , Todos los Derechos Reservados 

Este ensayo fue publicado el viernes, 15 de abril de 2011.