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

50

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.

Andrea
fuente
3
xkcd2.heroku.com/297
Michelle Tilley
55
El LISP de Steel Bank (común) es en realidad más popular de lo que puedas imaginar. LISP como macroprocesadores (por ejemplo, M4) también se utilizan ampliamente. Es posible que no lo vea en su dominio de elección, pero todavía está disponible (para bien o para mal).
Tim Post
8
El reciente terremoto y el tsunami destruyeron la fábrica de paréntesis en Japón. :-(
oosterwal
1
¿Qué versión de Lisp deberíamos usar? Recuerde que los dialectos de Lisp son más o menos incompatibles.
2
LISP (o dialectos de) se usan en todas partes, por ejemplo, AutoLISP es un dialecto de LISP utilizado por Autocad en.wikipedia.org/wiki/AutoLISP o EMACS en.wikipedia.org/wiki/Emacs_Lisp
Jaydee

Respuestas:

68

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.

revs dbyrne
fuente
24
La objeción sobre la dificultad de encontrar programadores calificados es un poco como un perro persiguiendo su cola. Si Lisp estuviera más extendido, sería más fácil encontrar buenos programadores.
Andrea
2
@Andrea Eso es definitivamente cierto. Sin embargo, es más difícil aprender lisp, lo que también contribuye al problema. Me doy cuenta de que podría ser una opinión controvertida, ya que muchos profesores enseñan el esquema como lengua materna.
dbyrne
8
Sí, APL es un excelente ejemplo de un lenguaje expresivo. Además, un buen ejemplo de por qué la expresividad no es lo más importante;)
dbyrne
99
No creo que esta definición realmente transmita lo que significa expresivo. Personalmente, antes de llamar a un lenguaje expresivo, me aseguraría de poder leer lo que he escrito. Por ejemplo, el uso de lógica no trivial en el inicializador de bucle en C puede ahorrarle algunas líneas de código, pero no es fácilmente comprensible. Por otro lado, una comprensión de la lista en Python puede guardar un par de líneas y ser más legible. Así que realmente has encontrado una manera de expresar lo que querías decir de manera más concisa. Si no es legible, no ha encontrado la manera de expresar nada.
Andrea
3
Creo que tal vez salgo como alguien a quien no le gusta el lisp. En verdad, me encanta. Clojure es un lenguaje increíble. Creo que es una opción muy viable para un determinado tipo de empresa. Solo estoy señalando que hay muchas compañías donde no tendría sentido, y usar algo como Scala es una opción mucho más práctica.
dbyrne
17

¿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, ...)

Jörg W Mittag
fuente
3
Dónde vivo (Italia) Dudo que exista una sola compañía Lisp ...
Andrea
1
¿Qué grandes empresas están promoviendo Ruby, Python y JavaScript? JS es un caso ciertamente especial, pero los otros dos parecen bastante populares sin el respaldo masivo de la empresa / proveedor
Ben Hughes
Sí, eso también es cierto para otros idiomas. La mayoría de los buenos codificadores de COBOL ya tienen trabajo, y de todos modos no están leyendo los anuncios. ¿Por qué molestarse con la publicidad?
Bo Persson
¿Lo que realmente? Codificaré en cualquier idioma que no sea convencional, aunque Haskell suena muy por encima de mi cabeza. La pequeña cantidad de código que he codificado es extremadamente hermosa, pero sin un buen mentor no tengo idea de cuándo usar cada Mónada y los Funcionarios Aplicativos.
aoeu256
9

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.

jsternberg
fuente
1
PLT Racket (anteriormente PLT Scheme) funciona bien tanto en Linux como en Windows.
Larry Coleman
Interesante, esperaría que Common Lisp sea mucho más estándar y utilizable para aplicaciones reales que Scheme. (Estoy leyendo Practical Common Lisp en este momento.)
Giorgio
Te felicito por elegir Haskell (que es un mejor idioma en mi opinión), pero ¿qué pasa con Clojure? Se ejecuta en la JVM, por lo que debe ser portátil y tener acceso a todas las bibliotecas que necesita.
Andres F.
¿Los argumentos de la línea de comando son difíciles de usar en C ++? De Verdad?
Nick Keighley
¿No es trivial construir una compilación cruzada que cambie Lisp a Scheme a Clojure? ¿Por qué la gente no los usa?
aoeu256
8

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.

donkey_lz
fuente
1
"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". Una y otra vez tengo la sensación de que Lisp es para la élite.
Giorgio
2
"También debe aprender una forma completamente diferente de trabajar y pensar, y aunque está bien si lo está haciendo como un hobby, es cuestionable si vale la pena hacerlo en un negocio". razón suficiente?
Giorgio
¿Se ha demostrado esta "mayor productividad"? Ciertamente no está claro para mí (sí, lo he programado en un dialecto Lisp). No hay balas de plata.
Nick Keighley
5

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.

Andy Canfield
fuente
77
La resolución de problemas es todo lo que hacemos. La manipulación de datos no es fácil en Java o C. La manipulación de datos en celdas en contra es mucho más fácil en Lisp y otros lenguajes funcionales. La mayoría de las operaciones con datos son exactamente las mismas y no les importa en qué orden las procese. Estas se realizan fácilmente con una llamada al mapa y un puntero de función. También diría que es más fácil pensar en la funcionalidad anidada que en la funcionalidad del procedimiento (ya que uno detalla su objetivo y el otro detalla cómo realizar dicho objetivo), pero no tengo pruebas de ello. De cualquier manera, no diría que esta es la razón por la que no se usa LISP.
jsternberg
44
¿La programación no se trata de resolver problemas? No lo creo. Y, por cierto, tampoco creo que puedas aprender un idioma en la universidad.
Adam Arold
+1, suena muy plausible para mí que no conozco ningún Lisp. Diría la misma razón por la que C / Java es mejor que Python para soluciones de tamaño empresarial.
Jonas Byström
Esta es la única respuesta hasta ahora que planteó el gran tema de funcional frente a procedimiento, pero no olvidemos que el pensamiento procesal tiende a gustar jugar con globos de datos en vars en todas partes que puede tocar desde muchos lugares e hilos creando problemas de sincronización. Funcional no sufre tan rápido de esto, funcional bien escrito no sufre en absoluto.
maxpolk
1
Un programador una vez me preguntó cuál es la mejor manera de expresar un bucle for utilizando un diagrama de flujo de datos. Para esas personas no tiene sentido utilizar lenguajes no procesales. El pensar en FORTRAN.
Nick Keighley
5

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.

CodexArcanum
fuente
2
Common Lisp, al menos, es explícitamente un lenguaje OO: Common Lisp Object System es parte del estándar.
Frank Shearar
Es cierto, y según tengo entendido, es muy poderoso, pero me parece una característica secundaria del lenguaje. No es como Java, donde necesita comprender los objetos desde el día 1. Practical Common Lisp no toca CLOS hasta el capítulo 16. También podría estar predispuesto hacia la escritura estática, aunque no me disgustan los lenguajes escritos dinámicamente .
CodexArcanum
Lisp le permite usar cierres (let-over-lambda) en lugar de objetos para OOP liviano, pero creo que es fácil de actualizar para usar OOP a través de CLOS.
aoeu256
2

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.

6502
fuente
+1 para "Creo que la solución al problema de la complejidad son herramientas y educación poderosas".
Giorgio
después de 50 años, la excusa de "ignorancia" se está agotando
Nick Keighley
1
@ NickKeighley: depende. Incluso hoy en día, la mayoría de los programadores realmente no saben nada sobre Lisp (por ejemplo, la mayoría de las veces escuchas a Lisp descrito como un lenguaje funcional). Incluso entre quienes "conocen" a Lisp, casi nadie vio la idea macro con suficiente detalle (no estoy hablando de la versión simplificada del esquema, sino del poder algorítmico completo con la conveniencia de una cuasi cita cuando eso encaja mejor).
6502
@ 6502: Si bien no es puramente funcional, IMO Lisp admite una programación funcional mucho mejor que muchos lenguajes convencionales como C #, Java, C ++, etc. Para muchos programadores, FP significa simplemente usar una expresión lambda de vez en cuando: estos programadores no echarán de menos a Lisp, Clojure o Haskell. Por lo tanto, agregaría: (1) Lisp es bastante compatible con FP y los programadores funcionales se beneficiarían de él, pero (2) la ignorancia sobre FP y sus beneficios es una de las razones por las que Lisp no se usa con más frecuencia.
Giorgio
1
@ 6502: Tener listas como estructura de datos básica y las funciones habituales de alto orden en las listas también es una característica que falta en Javascript. Y, hasta donde puedo recordar, Javascript también tiene la declaración / expresión de dualidad. Definitivamente colocaría Lisp (Common Lisp) unos pasos más en la dirección de FP que Javascript o Python. Con esto no quiero decir que Common Lisp sea un lenguaje puramente funcional, estoy de acuerdo en que es multi-paradigma, pero soporta FP mucho mejor que otros lenguajes multi-paradigmáticos.
Giorgio
1

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.

Nemanja Trifunovic
fuente
2
Esto ya no es verdad. Quicklisp resolvió ese problema.
2
También vale la pena mencionar que con CFFI, cualquier biblioteca C se puede usar desde Common Lisp. CFFI está bien documentado y funciona bien. Por otro lado, si pasar unas horas escribiendo envoltorios para las funciones de C tiene un impacto importante en su proyecto, Lisp probablemente no sea la opción correcta para ello de todos modos.
Larry Coleman
Hice un proyecto no trivial en Scheme y conozco una compañía que usa Scheme (Chicken Scheme) para varios productos.
Giorgio
1

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.

kamaal
fuente
+1 por citar el principio "Optimizar para el caso común".
Giorgio
Sí, pero los cierres de LISP son una optimización para el caso común de los objetos. También me preguntaba si alguien realiza cambios en su base de código LISP al tratarlo como un árbol y ejecutar consultas en él como JQuery para HTML.
aoeu256
1

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.

gcbenison
fuente
0

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).

Jerry Coffin
fuente