La JVM ya tenía tres Lisps antes de que llegara Clojure a la escena: Kawa, Armed Bear y SISC.¿Por qué Clojure sobre otros Lisps de JVM: Kawa, Armed Bear o SISC?
¿Qué hueco tiene el relleno Clojure que dejó ese Lisps?
Kawa, ABCL y SISC son reimplementaciones de idiomas existentes que son bastante largos en el diente. Son excelentes si, por algún motivo, desea utilizar el Esquema estándar o el Common Lisp estándar en la JVM.
Clojure es un nuevo idioma. No rellena un brecha. Agrega posibilidades completamente nuevas. Favorece un enfoque puramente funcional: Scheme y CL son ambos multi-paradigmas. Clojure toma prestado mucho del diseño de varios lenguajes de FP (ML, Haskell).
Y sí, podría agregar soporte de simultaneidad a otros Lisps, pero eso no tiene sentido. Clojure fue diseñado desde el principio como lenguaje concurrente. Tanto es así que escribir programas simultáneos es trivial en Clojure, no en ciencia espacial, como lo es en los lenguajes no funcionales (Scheme, CL no se excluye). Mire de esta manera:
La gente dice que C le permite escribir programas rápidos de forma predeterminada.
Bueno, Clojure le permite escribir programas simultáneos de forma predeterminada.
No sé por qué estás siendo degradado. Su última oración resume bien las cosas. Clojure proporciona la única forma viable y no académica para escribir programas STM de alto rendimiento para la JVM. Volver a la concurrencia basada en bloqueo es como volver a la administración manual de la memoria: a veces lo necesita, y puede ser un desafío agradable y no necesita ser tedioso, pero en general lo distrae de la lógica central de la aplicación, que es por qué no lo haces hasta que sea necesario. – pmf
Él está averiado porque ni siquiera se preocupó por consultar los otros Lisps mencionados: Kawa, ABCL SISC. La documentación de SISC dice, por ejemplo: 'SISC proporciona una biblioteca completa para ejecutar código Scheme en paralelo en múltiples hilos concurrentes'. Por lo tanto, no necesita agregar concurrencia a SISC, ya lo tiene. –
Casi todas las implementaciones de lenguaje serio admiten concurrencia basada en subprocesos. El punto es que las implementaciones prácticas de STM son muy raras. – pmf
"Clojure es un Lisp no limitado por la compatibilidad hacia atrás" (que es desde el sitio web Clojure). Es un nuevo comienzo. Es progreso. Use las ideas que hacen que Lisp/Scheme sea poderoso, pero repensarlas en torno a la plataforma Java .
Clojure siempre será el Clojure más reciente. Con cualquier otro idioma portado a la JVM, la versión de JVM siempre podría estar jugando catch-up. Si no necesita la plataforma Java, ¿por qué usar SISC sobre otro esquema? Si lo haces, ¿por qué no utilizar el único Lisp (Clojure) que fue diseñado específicamente para ello?
Diseñado teniendo en cuenta la simultaneidad.
Esto parece ser contradictorio con las otras publicaciones: Clojure se diseñó alrededor de la plataforma Java y JVM: concurrencia de nivel de subproceso con objetos mutables y sincronización basada en bloqueo, y bibliotecas basadas principalmente en getters, setters y bucles de eventos (lo contrario de estilo de programación funcional) - o está diseñado alrededor (alguna otra forma de concurrencia) y memoria transaccional de software, que la JVM no admite de forma nativa. –
Pete: Está diseñado para la JVM y para la concurrencia, no son mutuamente excluyentes y solo porque está diseñado para la JVM, no significa que tiene que hacer las cosas de la misma manera que Java, siempre que funcione bien. en la JVM y juega muy bien con bibliotecas/códigos JVM existentes. – Dan
Simplemente no estaba al tanto de eso, lo que es un beneficio serio para Clojure (que la gente hizo el ruido suficiente que descubrí). Lo más grande que Clojure tiene que no vi en los que enumeró es Software Transactional Memory.
Clojure también se diseñó para la JVM, en lugar de ser una capa para otro idioma, por lo que es un poco más "Java-y" que imagino que serían los otros cuando tenga que interoperar.
Clojure tiene una buena interoperabilidad con la JVM pero es bastante Lisp-y en términos del lenguaje: la sintaxis de la llamada al método es '(.method someopject param1 param2)' por ejemplo. La gran parte de Java-y de Clojure está alrededor de la configuración del entorno (tiene una JVM, classpath, archivos .jar, etc.) – mikera
La ventaja de Clojure es que le da acceso a todas las librerías/códigos de java que existen, y soporte multihilo porque está basado en la JVM. Además, se diseñó teniendo en cuenta la concurrencia, algo que generalmente no está diseñado para el ceceo, aunque debido a las primitivas de mapeo probablemente no sería difícil diseñar un ceceo que apoye bien la concurrencia.
Dicho esto, probé Clojure y odié la sintaxis y el dolor en el trasero que parece ir junto con cualquier cosa relacionada con Java.
sí, pero la pregunta fue en comparación con otros Lisps en la JVM, que también tienen acceso a las bibliotecas de Java . –
Tienen acceso a bibliotecas de Java a través de una interfaz de función externa, pero con Clojure, dado que el código/datos se compila en la JVM, el código de Java también puede operar en las estructuras de datos de Clojure. Esto proporciona una integración más estrecha y perfecta con Java. Pero, para mí, esto es como tener una relación más cercana e íntima con una chica que no te gusta o encontrar atractiva :) Puedes hacerlo pero ¿cuál es el punto? –
Larry, estos otros Lisps también se ejecutan en la JVM y tienen acceso directo a las bibliotecas de Java. No FFI. Enumeró Kawa, ABCL y SISC. Se están ejecutando en la JVM. Para ABCL es un Common Lisp que también se compila a las instrucciones de JVM. –
Si fuera cínico, diría que es porque Clojure tiene un nicer website y un nombre más sexy.
Podrías tener razón ... tu respuesta provocó algunos pensamientos en mi cabeza que llevaron a mi respuesta. –
Clojure ofrece algo muy diferente de lo que ofrecen CL y Scheme. ¿Alguno de ustedes tiene experiencia en los tres (CL, Scheme, Clojure)? De lo contrario, ambos estarían haciendo comentarios más informativos. – dnolen
También debo añadir que Clojure es un lenguaje relativamente nuevo, implementado por una sola persona, con buenas habilidades de marketing y mucha energía. Está invirtiendo mucho tiempo y exagerando en clojure ... a veces, la exageración es una profecía autocumplida en el sentido de que si puedes convencer a suficientes personas de que es la última novedad, entonces puedes obtener suficiente apoyo e impulso para hacerlo realidad trabajo.
Sospecho que los implementadores de Kawa etc. no tienen tanto en juego, por lo tanto, no promocionan su producto. Además, ¿qué hay para exagerar? "Tenemos un gran lenguaje ... se llama Lisp" Es una venta de marketing más difícil.
Creo que Java es un buen ejemplo de esto. Tenía algunas deficiencias muy graves, pero debido a que se comercializaba y publicitaba mucho, logró un gran impulso que significó el apoyo de proveedores de hardware/software, productores de herramientas, inversión por industria, etc. De cualquier manera, logró un cierto grado de éxito, aunque odié programar en él. Clojure podría lograr un éxito similar donde otros Lisp no lo han logrado.
No creo que Rich Hickey ponga mucho "bombo" en el lenguaje. De hecho, parece positivamente "anti-hype" y bastante moderado en sus descripciones del idioma en sí. Personalmente, habiendo usado CL (ligeramente) y Scheme (SICP), puedo decir que Clojure se beneficia de haber sido desarrollado después del año 2000 A.D y no por comité. Y si bien no me gusta el lenguaje Java, hay muchas, muchas bibliotecas bien diseñadas (Joda, JOGL, jSynth, Lucene, ...). También creo que los ingenieros detrás de la JVM sabían lo que estaban haciendo teniendo la experiencia de StrongTalk, Self (y habiendo pasado a V8) – dnolen
, sí, tiene mucha exageración. – fedvasu
Java fue muy promocionado, pero el único evento que hizo que Java sea lo que es hoy, fue cuando Netscape incluyó compatibilidad con Java en su navegador. Si eso no hubiera sucedido, no creo que Java se hubiera convertido en la corriente principal. Como lo atestiguan los esfuerzos actuales de Google, el tiempo también es crítico; no creo que ninguno de los nuevos lenguajes de Google sea compatible con IE. –
Clojure es "un ceceo", no es ningún ceceo que usted ya conozca. Pasé los últimos días compartiendo el material y viendo los videos, y estoy impresionado. Su premisa es que los programas funcionales (basados en datos inmutables) son la mejor forma de administrar concurrencia . Clojure implementa un sistema de ceceo basado en JVM para proporcionarlo.
La respuesta más simple que se me ocurre es que Clojure no es Common-Lisp. Clojure no está limitado por la historia de otros Lisps. Es un nuevo idioma construido para la JVM.
La página de justificación en los estados clojure.org:
¿Por qué escribí otro lenguaje de programación? Básicamente porque quería:
- Un Lisp
- de programación funcional
- simbiótica con una plataforma establecida
- diseñado para la concurrencia
y no podía encontrar uno.
¿Los 3 idiomas mencionados (Kawa, ABCL y SISC) cumplen estos requisitos?Ellos son:
pero no son diseñado para (STM) Concurrencia; Sin embargo, para ser justos y completa, hay por lo menos 2 STM bibliotecas que he encontrado en el CL que aún no se han mencionado:
Hmm ... Entonces, ¿por crear un nuevo Lisp? Principalmente porque estas son las bibliotecas . Continúa la página de justificación en clojure.org (énfasis añadido):
¿Qué pasa con el Lisps estándar (Common Lisp and Scheme)?
- normalización
estructuras de datos- Core/no colocar la innovación lenta mutable, no extensible
- Sin la concurrencia en las especificaciones
- buenas implementaciones ya existen para JVM (ABCL, Kawa, SISC et al)
- Lisps estándar son sus propias plataformas
Es un diseño de simultaneidad de idioma problema, como han mencionado otros.
Además, ¿por qué parar en la JVM? El soporte Clojure CLR está en desarrollo activo.
Esos son los 2 huecos que llena, desde mi punto de vista. Debe usar Clojure si satisface sus necesidades. No te preocupes por perder tus habilidades si Clojure se cae del mapa. Tus habilidades de Lisp, pero lo más importante, tu forma de pensar, se trasladarán a otros dialectos de Lisp.
No tenemos que tener una respuesta más (y no espero votos para esta), pero aquí hay algunas pequeñas mejoras a varias otras respuestas.
Más nuevo no es necesariamente mejor. Más nuevo y mal diseñado no es bueno, más nuevo y no mantenido no es bueno, y más nuevo sin una comunidad de usuarios más grande (o al menos creciente) no es bueno. (Los nuevos idiomas salen regularmente, pero la mayoría de ellos se quedan en el camino por desuso.)
I love Common Lisp.Parte de su belleza es su extravagancia, que proviene del hecho de que fue diseñada por comités con el objetivo de compatibilidad con versiones anteriores de varios dialectos incompatibles.
I love Scheme. Es un lenguaje hermoso y elegante. Sin embargo, su desarrollo depende de los comités, y tal vez eso lo ha ralentizado en ocasiones. En cualquier caso, sus objetivos son diferentes a los de Clojure.
Common Lisp y Scheme tienen énfasis como recursividad de cola que no son adecuados para la eficiencia en la JVM. Clojure fue diseñado desde el principio para mapearse bien en la JVM e interoperar (bastante) bien con Java. (No estoy seguro de lo que eso significa sobre los dialectos Clojurescript y CLR.)
El hecho de que Clojure fue desarrollado, inicialmente, por una persona, Rich Hickey, y es controlado por él junto con un pequeño equipo, no lo hace necesariamente lo hacen mejor que un lenguaje controlado por comités. Si esa persona tomó malas decisiones, Clojure no sería un buen lenguaje.
Sin embargo, y este es el punto importante: Hickey diseñó un lenguaje bien pensado, elegante, y que desde el principio incluía un conjunto de funciones sistemáticamente relacionadas que hacen que sea fácil hacer mucho con un poco . Eso se aplica a la interoperabilidad básica de JVM, así como al resto del lenguaje. Las personas que controlan Clojure continúan siendo estrictas en cuanto a apegarse a los objetivos del idioma, hasta ahora.
Esto es una gran parte de lo que me encanta de Clojure: está bien diseñado tanto en conjunto como en sus detalles. Eso significa que una vez que te acostumbras, es un placer programar en él.
Sería un poco exagerado (¿o entendible?) Decir que Clojure tiene el poder de Common Lisp con la elegancia de Scheme. Common Lisp tiene mucho y mucho de lo que necesita integrado en el lenguaje, pero es un desastre (lo digo con amor), y cuando necesita algo más de lo que hay en el idioma, a veces hay varias bibliotecas incompatibles con diferentes intercambios. El esquema por diseño es pequeño, aunque hay bibliotecas disponibles. Clojure tiene un cuerpo creciente de bibliotecas estándar (a diferencia de CL) que son más o menos partes del lenguaje. Una buena ilustración de esto es el proyecto core.matrix, que proporciona una interfaz común para varias implementaciones de matrices diferentes. Esto es importante, porque hay diferentes implementaciones de matriz que son mejores para el uso ocasional de matrices pequeñas, o para el uso extensivo de matrices enormes, por ejemplo.
Nada de esto pretende decir que Clojure es mejor que Common Lisp o Scheme; no es. Los tres idiomas tienen diferentes virtudes.
¡Es nuevo! Lo que significa que no muchos usuarios antiguos lo usarán, ya que la comunidad tradicional de lisp está bien, es tradicional, pero también significa que las personas sin experiencia de ceceo previa lo tomarán como algo nuevo.
Imho, Clojure es para los viejos Lisps lo que Ruby era para Smalltalk. No necesariamente mejor, pero lo suficientemente bueno. Y, lo que es más importante, es más aceptable para su empleador porque tiene un impulso y se ve como un lenguaje en aumento, al estilo de Ruby.
moda, tal vez? – skaffman
hay una gran cantidad de lenguajes Lisp para la JVM: http://www.is-research.de/info/vmlanguages/lisp/ Algunos se utilizan, otros no. –
Como buen programador de Lisp pasado de moda, puedo asegurarle que básicamente nunca hacemos las cosas por el bien de la moda. Hemos sido acusados de muchas cosas, pero creo que estamos a salvo de eso.:-) – Ken