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

La expresividad no siempre es un rasgo positivo del idioma 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 experto programador de Java puede refactorizar código mal escrito rápidamente. Cuanto más expresivo sea el lenguaje, más difícil será comprender y refactorizar el código horrible. Las macros LISP son un buen ejemplo. Las macros son herramientas poderosas en las manos adecuadas. En las manos equivocadas, pueden resultar en un código confuso y difícil de depurar.

LISP es una opción arriesgada para la alta gerencia. Si las cosas van mal, nadie va a culpar a la administración por elegir un lenguaje popular orientado a objetos respaldado por una corporación importante 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 usar un lenguaje más poderoso generalmente no eligen LISP. Esto se debe a que muchos de los lenguajes más nuevos intentan y se comprometen al tomar prestadas funciones poderosas de LISP, a la vez que son 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 funciones 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 se ha adoptado ampliamente por muchas de las mismas razones que LISP.

A pesar de todo esto, espero ...

Clojure tiene la posibilidad de volverse popular. Se ejecuta en la JVM, tiene una excelente interoperabilidad con Java y hace que la programación concurrente sea mucho más simple. Estos son todos 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 es realmente tan poderoso, la gente debería usarlo por todas partes,

Si crees que los idiomas son elegidos por sus méritos técnicos, te espera una decepción aplastante.

Tales decisiones se toman en base a Strippers And Steaks . Microsoft puede pagarlos. Oracle puede. Sun gastó tanto dinero promocionando Java que quebraron. Dos veces. Una comunidad descentralizada, heterogénea y voluntaria 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 trabajando para una empresa real, pero sé por qué me ha costado usar LISP.

En primer lugar, esto me recuerda esta publicación del blog: enlace

El principal problema que tengo con Lisp es la pregunta "qué Lisp". Normalmente 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 facilitar mi vida 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 proyectos secundarios personales, pero como nunca tengo la oportunidad de escribir un proyecto de software grande en ellos, no tengo la experiencia necesaria.

Ahora, cuando intentaba aprender un lenguaje funcional, realmente quería aprender Common Lisp. Parecía lo correcto para hacer. Comencé a leer Practical Common Lisp como punto de partida, ya que realmente no conocía las funciones integradas y necesitaba un proyecto en el que trabajar en Lisp. Las expresiones en 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.

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

Necesito acceder a los argumentos de la línea de comandos. Luego me entero de que no hay una forma estándar de obtener argumentos de línea de comando. Todas son características no estándar. No es multiplataforma en absoluto. En su mayoría, la situación 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 el mismo problema, pero con las bibliotecas como Boost puedes superar esas debilidades.

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

OMI, se debe principalmente a:

• Soporte pobre de la biblioteca. Claro, ahora hay Quicklisp, lo que facilita la instalación de bibliotecas, pero no compensa que sean todavía muy pocas, y algunas están mal documentadas o no están muy 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 las personas que conozco están bastante intimidadas al tener que usar SLIME y Emacs, lo cual es comprensible para las personas que están acostumbradas a Eclipse y Visual Studio. Creo que hay dos plugins de Eclipse, solo probé uno de ellos hace unos años y estaba bastante lleno de errores. Todo el ecosistema de Lisp parece estar atrapado a medio camino entre los días en que formaba parte de un sistema de ejecución de Lisp de pleno derecho y el estándar moderno de oh-it-another-language. Aprender Lisp no se limita a aprender un nuevo idioma, sino que también necesita aprender una forma completamente diferente de trabajar y pensar, y aunque esto está bien si lo hace como un pasatiempo, es cuestionable si vale la pena hacerlo en una negocio.

Sin embargo, las cosas están empezando a verse un poco mejor, especialmente con Clojure alrededor.

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

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

LISP se trata de una funcionalidad anidada, y la gente simplemente no piensa de esa manera. Piensan en términos de DO A, B, C, D, luego E. No A, que implica hacer B y C, luego D y E. Esto implica un tipo de concurrencia que es confusa. Excepto las tareas predefinidas como "presentar una declaración de impuestos", las personas no piensan simultáneamente, piensan de forma secuencial. Esta es la razón por la cual los lenguajes procedurales son dominantes hoy.

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

Así que es genial para la resolución de 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 fue terriblemente débil en.

Creo que un problema con Lisp que todavía no se ha mencionado es que para un programador mediocre o novato (como yo, lo admito libremente), puede ser difícil ver cómo convierte el código 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 del bricolaje es tan fuerte que a menudo siento que no sé por dónde empezar.

Con un lenguaje OOP como Java o C #, puedes usar el sistema de tipos para mejorar tu estilo de trabajo y construirlo. Con Lisp (o Lua, o Javascript, en realidad) existe la idea de que puedes salir y hacerlo de la manera que quieras. Si quieres OOP, haz tu propio sistema OOP! Excepto hacer su propio OOP, o aprender de otra persona, es una nueva barrera en la parte superior del idioma antes de obtener 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 la programación en Lisp requiere mucha disciplina, y eso es muy difícil de conseguir. Los lenguajes fuertemente tipados y los OOP ofrecen un tipo de disciplina incorporada, por lo que el programador puede concentrar sus reservas limitadas en terminar los proyectos en lugar de modificar el lenguaje.

EDITAR: Como una analogía que me llamó la atención, es como si tuvieras que hacer algo de madera y dos personas te ofrezcan sus cajas de herramientas. Las herramientas de una persona son un tanto desastrosas, pero básicamente harían el trabajo con un poco de esfuerzo. La otra persona tiene una gran cantidad de piezas, pero le promete que puede combinar esas piezas para crear las mejores herramientas que jamás haya utilizado, perfectamente adecuadas para su agarre y de la mejor calidad. Solo tienes que construirlos primero.

Parece que incluso CL no tiene muy buena compatibilidad con bibliotecas. Al menos según las personas que cambiaron de Lisp a Python:

enlace

Personalmente, conozco algunos Esquemas y disfruto jugando con él, 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 de la mediocridad, si se les asegura de manera consistente, es mucho mejor para las personas que los grandes éxitos con muchos fracasos entre ellos.

Este no es solo el caso de lisp, sino también 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 podrá apreciar el valor de estas cosas. Puede escribir un programa enorme con legibilidad y facilidad de mantenimiento y todo eso, pero ¿cuál es el punto principal de escribir un programa así mientras no escribirlo podría haber hecho el trabajo fácilmente?

Otro aspecto, al diseñar herramientas en estos días, es lo útil que es utilizarlas directamente para resolver un problema. No puedes construir algo demasiado genérico y luego decir que cubrirás todo eso a través de bibliotecas y marcos. Es un poco difícil resolver las cosas de esa manera. Una buena herramienta se adapta bien al entorno y al problema que la rodea. Es por eso que las herramientas como php, perl y awk siguen siendo relevantes a pesar de interminables trolling y ataques, porque son demasiado útiles para deshacerse de ellas y, a menudo, hacen mucho trabajo que un lenguaje general con muchas bibliotecas y marcos empotrados. p>

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

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

Me he estado preguntando lo mismo por mucho tiempo, e incluso fui a las conferencias de Lisp para tratar de entender qué es el "lado oscuro" de Lisp que evita 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 quien con seguridad conoce a Lisp (por ejemplo, Google - Peter Norvig trabaja para ellos) no lo está utilizando.

La única explicación parcial que se me ocurre es que la mayoría de las grandes ideas de Lisp son ahora un lugar común, la única que realmente falta es una metaprogramación sencilla.

Lamentablemente, no veo una manera fácil de absorber este concepto para otros idiomas porque la metaprogramación para ser agradable requiere un lenguaje homoicónico y regular (me refiero a la metaprogramación general, no a la versión estúpida de plantilla únicamente). En otras palabras, básicamente requiere el enfoque de Lisp para la sintaxis: el código es datos y el código es datos. Escribir código en un lenguaje rico en sintaxis que manipula 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 diferentes de nodos. En cambio, Lisp tiene un AST razonablemente regular (¡y extensible!) Y usted normalmente ya codifica al escribir 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 de "nadie lo necesitaría".

Me parece particularmente triste que "nuevos" lenguajes como go terminaron usando metaprogramación basada en texto cuando es necesario (generadores de código externos que escriben archivos de texto) y "magic" (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 poderosas y educación. Aparentemente, la tendencia es, en cambio, herramientas contundentes y fingir que el problema no está presente.

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 se volviera práctico para la mayoría de las personas o usos. Clojure (por ejemplo) tiene una oportunidad mucho mejor. Su éxito dependerá mucho más de ser percibido como nuevo, moderno y atractivo que cualquier cosa tan práctica como la interoperación con Java (y todo lo demás que se ejecuta en la JVM).

Para el desarrollo web con dialectos Lisp, puede haber un pequeño problema con la gallina y el huevo, porque pocas personas usan Lisp, los hosts no lo permiten o no lo facilitan, y porque no es fácil , pocas personas lo usan. 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 de PHP listo para usar. Hace poco recibí guile aplicaciones Scheme funcionando aquí con un poco de esfuerzo.