¿Por qué no está Lisp más extendido? [cerrado]

Estoy empezando a aprender Scheme por los videos de SICP, y me gustaría pasar a Common Lisp a continuación.

El lenguaje parece muy interesante, y la mayoría de las personas que escriben libros sobre él defienden que tiene un poder expresivo inigualable. CL parece tener una biblioteca estándar decente.

¿Por qué no está Lisp más extendido? Si realmente es tan poderoso, la gente debería estar usándolo todo, pero en cambio es casi imposible encontrar, por ejemplo, anuncios de trabajo de Lisp.

Espero que no sea solo el paréntesis, ya que no son un gran problema después de un tiempo.

La expresividad no siempre es un rasgo positivo del lenguaje en un entorno corporativo. Java es extremadamente popular en parte porque es fácil de aprender, fácil de escribir y fácil de leer. Los programadores mediocres aún pueden ser muy productivos en Java, incluso si su código es prolijo y poco elegante.

Además, es fácil abusar de los lenguajes expresivos. Un programador experto de Java puede refactorizar código mal escrito rápidamente. Cuanto más expresivo es el lenguaje, más difícil resulta la comprensión y la refactorización de códigos horribles. Las macros LISP son un buen ejemplo. Las macros son herramientas poderosas en las manos correctas. En las manos equivocadas, pueden resultar en código confuso y difícil de depurar.

LISP es una opción arriesgada para la alta gerencia. Si las cosas salen mal, nadie va a culpar a la administración por elegir un lenguaje popular orientado a objetos respaldado por una gran corporación como Oracle o Microsoft. Es mucho más fácil contratar programadores con experiencia en idiomas populares y fáciles de aprender.

Incluso las empresas progresistas que desean utilizar un lenguaje más potente no suelen elegir LISP. Esto se debe a que muchos de los idiomas más nuevos intentan y se comprometen al tomar prestadas características potentes de LISP, mientras se mantienen fáciles de aprender para las masas. Scala y Ruby siguen este modelo. Los malos programadores pueden recogerlos rápidamente y seguir escribiendo el mismo código mediocre que hicieron en Java. Los buenos programadores pueden aprovechar las características más avanzadas para escribir código hermoso.

Los paréntesis no son el problema. Haskell es un lenguaje increíblemente poderoso y expresivo con una sintaxis similar a Python o Ruby y no ha sido ampliamente adoptado por muchas de las mismas razones que LISP.

A pesar de todo esto, espero ...

Clojure tiene una posibilidad de hacerse popular. Se ejecuta en la JVM, tiene una gran interoperabilidad con Java y hace que la programación concurrente sea mucho más simple. Todas estas son cosas importantes para muchas empresas.

* Esta es mi perspectiva como programador profesional de JVM con experiencia en Java, Clojure, JRuby y Scala.

¿Por qué no está Lisp más extendido? Si realmente es tan poderoso, la gente debería estar usándolo todo,

Si crees que los idiomas se eligen por sus méritos técnicos, te encontrarás con una desilusión desgarradora.

Dichas decisiones se toman en base a Strippers And Steaks . Microsoft puede permitírselos. Oracle puede. Sun gastó tanto dinero promocionando Java que se declararon en quiebra. Dos veces. Una comunidad voluntaria descentralizada, heterogénea no puede competir con eso.

pero en cambio es casi imposible encontrar, por ejemplo, anuncios de trabajo de Lisp.

Curiosamente, las compañías de Lisp dicen exactamente lo contrario: constantemente tienen ofertas de trabajo pero no pueden encontrar suficientes personas para llenarlas. (Lo mismo se aplica a Haskell, ML, O'Caml, Forth, Smalltalk, ...)

No tengo experiencia en trabajar para una empresa real, pero sé por qué LISP me ha resultado difícil de usar.

En primer lugar, esto me recuerda a esta publicación de blog: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

El principal problema que tengo con Lisp es la pregunta "qué Lisp". Por lo general, trabajo en Linux como mi plataforma principal, pero las cosas que hago deben ser compatibles con Windows. Eso significa que cuando estoy evaluando una tecnología para usar, debe hacerme la vida más fácil cuando trabajo en dos sistemas operativos radicalmente diferentes. No me gusta este requisito, pero usarlo en un proyecto real es un requisito. Ahora usaré idiomas que no tienen muy buen soporte en Windows para mis propios proyectos secundarios personales, pero debido a que nunca tengo la oportunidad de escribir un gran proyecto de software en ellos, no tengo la experiencia necesaria.

Ahora, cuando intentaba aprender un lenguaje funcional, tenía muchas ganas de aprender Common Lisp. Parecía lo correcto. Comencé a leer Practical Common Lisp como punto de partida, ya que realmente no conocía las funciones integradas y necesitaba un proyecto para trabajar en Lisp. Las expresiones S eran hermosas y fáciles. Todos esos paréntesis fueron increíblemente hermosos para mí, ya que estaba claro como el día exactamente lo que estaba sucediendo en el código.

Así que trato de escribir mi primer programa en Lisp fuera del libro. Quería una herramienta de línea de comando que contara líneas de código y eliminara líneas triviales del recuento de códigos. No es la herramienta más útil, pero divertida de hacer. Implica el acceso a archivos, un poco de análisis y recuento. Había implementado la misma herramienta en Python aproximadamente una semana antes.

Necesito acceder a los argumentos de la línea de comandos. Entonces aprendo que no hay una forma estándar de obtener argumentos de línea de comandos. Todas son características no estándar. No es multiplataforma en absoluto. En su mayoría, empeora a partir de ahí, ya que el lenguaje no tiene muchas bibliotecas integradas. Terminé cambiando a Haskell y no llegué muy lejos en Common Lisp (por lo que mis quejas pueden no ser válidas).

Este tipo de cosas no estándar siempre ha sido un dolor para mí en el pasado. C ++ tiene este mismo problema, pero con bibliotecas como Boost puede sortear esas debilidades.

Tampoco ayuda que la sintaxis de Lisp para todo lo que no sea Expresiones S sea un poco fea.

OMI, se debe principalmente a:

• Pobre soporte de la biblioteca. Claro, ahora hay Quicklisp, lo que facilita la instalación de bibliotecas, pero no compensa que sigan siendo bastante pocas, y muchas están mal documentadas o no están bien mantenidas. En comparación con Python, hay una buena posibilidad de que escribir una aplicación Lisp no trivial (independientemente del dialecto en particular) probablemente implique reinventar al menos parte de una rueda o dos.
• Falta de familiaridad con el modelo adoptado por las herramientas de desarrollo. La mayoría de la gente que conozco está bastante intimidada por tener que usar SLIME y Emacs, lo cual es comprensible para las personas acostumbradas a Eclipse y Visual Studio. Creo que hay dos complementos de Eclipse, solo probé uno de ellos hace unos años y estaba bastante defectuoso. Parece que todo el ecosistema de Lisp está atascado a mitad de camino entre los días en que era parte de un sistema completo de Lisp y el estándar moderno de oh-es-otro-idioma. Aprender Lisp no se limita a aprender un nuevo idioma: también debes aprender una forma completamente diferente de trabajar y pensar, y aunque está bien si lo haces como un hobby, es cuestionable si vale la pena hacerlo en un negocio.

Sin embargo, las cosas comienzan a verse un poco mejor, especialmente con Clojure alrededor.

Aprendí LISP hace mil millones de años en la universidad.

LISP, como FORTH, es excelente para la lógica. Pero la mayoría de la programación no se trata de lógica, se trata de manipular datos de formas mecánicas aburridas. Por ejemplo, en ese momento no hay forma de justificar a la derecha la salida numérica.

LISP trata sobre la funcionalidad anidada, y las personas simplemente no piensan de esa manera. Piensan en términos de DO A, B, C, D, luego E. No hacen A, que implica hacer B y C, luego D y E. Esto implica un tipo de concurrencia que es confusa. Excepto para tareas predefinidas como "presentar una declaración de impuestos", las personas no piensan simultáneamente, piensan secuencialmente. Es por eso que los lenguajes de procedimiento son dominantes hoy en día.

Como resultado, el código produral gusta Java y C puede traducirse fácilmente al inglés. El código LISP no puede; Ningún lenguaje humano está estructurado de esa manera.

Por lo tanto, es excelente para resolver problemas, pero la resolución de problemas no es muy importante en la programación. Entrada de datos, validación, formato de salida, todo lo cual LISP era terriblemente débil.

Creo que un problema con Lisp que aún no se menciona es que para un programador mediocre o novato (como yo, lo admito libremente), puede ser difícil ver cómo convierte el código de Lisp en un gran programa. Es fácil de escribir pero difícil de diseñar. No creo que ninguno de los conceptos sea particularmente difícil, pero la mentalidad de bricolaje es tan fuerte que a menudo me siento perdido por dónde empezar.

Con un lenguaje OOP como Java o C #, puede usar el sistema de tipos para impulsarse hacia un modelo de trabajo y construir a partir de eso. Con Lisp (o Lua, o Javascript, para el caso) existe la noción de que puedes salir y hacerlo de la forma que quieras. Si quieres OOP, ¡solo crea tu propio sistema OOP! Excepto hacer tu propia OOP, o aprender la de otra persona, es una nueva barrera además del idioma antes de que obtengas programas utilizables. Además, siempre siento que el OOP en Lisp o Lua no está realmente allí, como si pudiera ignorarlo si realmente quisiera, ¿cuál es el punto?

En resumen, creo que programar en Lisp requiere mucha disciplina, y eso es muy difícil de conseguir. Los idiomas fuertemente tipados y los idiomas OOP ofrecen un tipo de disciplina incorporada, por lo que el programador puede concentrar sus reservas limitadas en terminar proyectos en lugar de ajustar el idioma.

EDITAR: Como analogía que me llamó la atención, es como si necesitaras hacer un trabajo en madera y dos personas te ofrecen sus cajas de herramientas. Las herramientas de una persona son un poco malas, pero básicamente hacen el trabajo con un poco de esfuerzo. La otra persona tiene un gran contenedor de piezas, pero promete que puede combinar esas piezas para crear las mejores herramientas que haya utilizado, perfectamente adaptadas a su agarre y de la mejor calidad. Solo tienes que construirlos primero.

Me he estado preguntando lo mismo por mucho tiempo, e incluso fui a las conferencias de Lisp para tratar de entender qué es este "lado oscuro" de Lisp que impide que todos lo adopten.

No he encontrado una respuesta decente completa.

La ignorancia puede ser la razón de la falta de popularidad, pero lo que más me desconcierta es que incluso quién sabe con certeza sobre Lisp (por ejemplo, Google - Peter Norvig trabaja para ellos) no lo está usando.

La única explicación parcial que se me ocurre es que la mayoría de las grandes ideas de Lisp ahora son comunes, la única que falta realmente importante (una IMO enormemente importante) es la facilidad de la metaprogramación.

Desafortunadamente, no veo una manera fácil de adsorber este concepto para otros idiomas porque la metaprogramación para ser agradable requiere un lenguaje homicónico y regular (estoy hablando de metaprogramación general, no de la versión de plantilla simplificada). En otras palabras, básicamente requiere el enfoque de Lisp para la sintaxis: el código es datos y los datos son código. Escribir código en un lenguaje rico en sintaxis que manipule un AST es más difícil porque necesita saber dos idiomas: cómo escribir el código y cómo escribir el AST. Esto es especialmente difícil si su AST es fijo y también complejo e irregular con muchos tipos de nodos diferentes. Lisp en cambio tiene un AST razonablemente regular (¡y extensible!) Y usted normalmente codifica escribiendo directamente el AST.

La metaprogramación también es inherentemente más difícil (y la meta-metaprogramación aún más, etc.) y la mayoría de los programadores y gerentes aparentemente prefieren la respuesta "nadie necesitaría esa respuesta".

Me parece particularmente triste que "nuevos" lenguajes goterminaron usando metaprogramación basada en texto cuando es necesario (generadores de código externos que escriben archivos de texto) y "mágico" (es decir, el compilador puede hacer lo que los programadores no pueden hacer).

Creo que la solución al problema de la complejidad son herramientas y educación poderosas. Aparentemente, la tendencia son herramientas contundentes y pretender que el problema no está presente.

Parece que incluso CL no tiene muy buen soporte de biblioteca. Al menos según las personas que cambiaron de Lisp a Python:

http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

Personalmente, conozco algunos esquemas y disfruto jugando con ellos, pero no puedo imaginar hacer un proyecto no trivial en ese idioma.

Ser poderoso no implica necesariamente un uso generalizado. ¿Has oído hablar del término "Optimizar para el caso común"? Desafortunadamente, como muchos han dicho antes, la mediocridad, si se garantiza de manera consistente, es mucho mejor para las personas que los grandes éxitos con muchos fracasos entre ellos.

Este no es solo el caso con lisp, sino con muchas tecnologías. Un buen toque sobre las herramientas de procesamiento de texto de Unix, awk, sed, perl puede ahorrarle días de programación. Desafortunadamente, he visto a personas que llevan días haciendo este tipo de tareas en otras herramientas mal, lo que podría haber hecho con estas herramientas de manera más eficiente en minutos. Pero si uno pasa toda su vida en eclipse, nunca llegará a apreciar el valor de estas cosas. Puede escribir un gran programa con legibilidad y facilidad de mantenimiento y todo eso, pero cuál es el punto de escribir un programa de este tipo sin escribirlo podría haber hecho el trabajo fácilmente.

Otro aspecto al diseñar herramientas en estos días es lo útil que son para usarlas directamente para resolver un problema. No puede construir algo demasiado genérico y luego decir que cubrirá todo eso a través de bibliotecas y marcos. Es un poco difícil resolver las cosas de esa manera. Una buena herramienta funciona bien con el entorno y los problemas que la rodean. Es por eso que las herramientas como php, perl y awk continúan siendo relevantes a pesar de los interminables controles y ataques, porque son demasiado útiles para descartarlos y a menudo hacen mucho más trabajo que un lenguaje general con muchas bibliotecas y marcos atornillados.

De manera similar, verá que lenguajes como Java / Python son muy buenos y diría que son mejores para ciertas tareas. Python especialmente es muy bueno y fácil de aprender y escribir. Además, estos idiomas son realmente buenos si sus puntos finales de datos son estándar. Algún tipo de base de datos o XML o datos de ese tipo. Datos básicamente estructurados.

Lisp estará allí por mucho tiempo, pero no necesariamente generalizado. Como verá, cada herramienta tiene su nicho. Y resuelven cierto conjunto de problemas muy bien fuera de la caja. Creo y estoy seguro de que lisp está funcionando bien en áreas y problemas para los que está diseñado para resolver bien.

Para el desarrollo web con dialectos de Lisp, puede haber un pequeño problema de huevo y gallina, porque pocas personas usan Lisp, los anfitriones no lo permiten o no lo hacen fácil, y porque no es fácil, pocas personas úsalo. Pero en realidad, hacer que Lisp se ejecute en un host puede ser más fácil de lo que piensas, incluso si requiere un poco más de trabajo que su servicio PHP listo para usar. Recientemente obtuve aplicaciones engañosas de Scheme trabajando aquí con solo un pequeño esfuerzo.

En mi opinión, se trata principalmente de un mal momento: Lisp era viejo (y casi por definición ya no es emocionante) mucho antes de que fuera práctico para la mayoría de las personas o usos. Clojure (por ejemplo) tiene muchas más posibilidades. Sin embargo, su éxito dependerá mucho más de ser percibido como nuevo, moderno y genial que cualquier cosa tan práctica como la interoperación con Java (y todo lo demás que se ejecuta en la JVM).