¿Por qué Clojure sobre otros JVM Lisps: Kawa, Armed Bear o SISC?

Question

La JVM ya tenía tres Lisps antes de que Clojure llegara a escena: Kawa , Oso armado y SISC .

¿Qué vacío cubre Clojure que dejaron esos Lisps?

Answer 1

Kawa, ABCL y SISC son reimplementaciones de lenguajes existentes que son bastante largos. Son excelentes si por alguna razón desea utilizar Scheme estándar o Common Lisp estándar en la JVM.

Clojure es un nuevo lenguaje. No llena un vacío . Agrega posibilidades completamente nuevas. Favorece un enfoque puramente funcional: Scheme y CL son ambos paradigmas múltiples. Clojure toma mucho prestado del diseño de varios lenguajes FP (ML, Haskell).

Y sí, podría agregar soporte de concurrencia a otros Lisps, pero ese es el punto completamente perdido. Clojure fue diseñado desde el principio como lenguaje concurrente. Tanto es así que escribir programas concurrentes es trivial en Clojure, no en ciencia espacial como lo es en lenguajes no funcionales (Esquema, CL no excluido). Mire de esta manera:

La gente dice que C te permite escribir programas rápidos por defecto.

Bueno, Clojure te permite escribir programas concurrentes por defecto.

Answer 2

1. " Clojure es un Lisp no limitado por la compatibilidad con versiones anteriores " (eso es del sitio web de Clojure). Es un nuevo comienzo. Es progreso. Use las ideas que hacen que Lisp / Scheme sea poderoso, pero vuelva a pensarlas en la plataforma.

de Java

2. Clojure siempre será el Clojure más reciente. Con cualquier otro idioma portado a la JVM, la versión de la JVM siempre puede estar poniéndose al día. Si no necesita la plataforma Java, ¿por qué usar SISC sobre otro esquema? Si lo hace, ¿por qué no usar el Lisp (Clojure) que fue diseñado específicamente para él?

3. Diseñado teniendo en cuenta la concurrencia.

Answer 3

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 lenguaje construido para la JVM.

Answer 4

Simplemente no estaba al tanto de eso, lo cual es un gran beneficio para Clojure (que la gente hizo suficiente ruido que descubrí). Lo más importante que tiene Clojure que no vi en las personas enumeradas es Memoria transaccional de software .

Clojure también fue diseñado 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 tengas que hacer interoperación.

Answer 5

La página de justificación en clojure.org dice:

  

¿Por qué escribí otro lenguaje de programación más? Básicamente porque quería:

     

  
• A Lisp
  
• para programación funcional
  
• simbiótico con una plataforma establecida
  
• diseñado para concurrencia
  

     

y no pude encontrar uno.

¿Los 3 idiomas que mencionó (Kawa, ABCL y SISC) cumplen con estos requisitos? Ellos son:

• Lisps (ya sea los dialectos CL o Scheme) ?
• para programación funcional ?
• simbiótico con una Plataforma establecida (la JVM) ?

pero no están diseñados para la concurrencia (STM); sin embargo, para ser justos y completos, hay al menos 2 bibliotecas STM que encontré para CL que aún no se han mencionado:

1. STMX
   • Probado trabajando en ABCL. En desarrollo activo.
2. CL-STM
   • ¿Muerto? El último cambio fue en 2007.

Hmm ... Entonces, ¿por qué crear una nueva Lisp? Principalmente porque estas son bibliotecas . La página de justificación en clojure.org continúa (énfasis agregado):

  

¿Qué pasa con el Lisps estándar (Common Lisp y Scheme)?

     

  
• Normalización lenta / sin innovación posterior
  
• Estructuras de datos centrales mutables, no extensibles
  
• Sin concurrencia en las especificaciones
  
• Ya existen buenas implementaciones para JVM (ABCL, Kawa, SISC et al)
  
• Standard Lisps son sus propias plataformas
  

Es un problema de diseño de concurrencia de idiomas , como han mencionado otros.

Además, ¿por qué detenerse en la JVM? El soporte Clojure CLR está en desarrollo activo .

Esas son las 2 lagunas que llena, desde mi perspectiva. Debe usar Clojure si satisface sus necesidades. No se preocupe por perder sus habilidades si Clojure se cae del mapa. Tus habilidades de Lisp, pero más importante aún tu forma de pensar, se transferirán a otros dialectos de Lisp.

Answer 6

Si estuviera siendo cínico, diría que es porque Clojure tiene un mejor sitio web y un nombre más atractivo.

Answer 7

También debo agregar que Clojure es un lenguaje relativamente nuevo, implementado por una persona, con buenas habilidades de marketing y mucha energía. Está invirtiendo mucho tiempo y exageración 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 gran cosa, 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 están promocionando 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 excelente ejemplo de esto. Tenía algunas deficiencias muy serias, pero debido a que se comercializó y promocionó tanto, logró un gran impulso, lo 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 odiaba programar en él. Clojure podría lograr un éxito similar donde otros Lisps no lo han hecho.

Answer 8

La ventaja de Clojure es que le da acceso a todas las bibliotecas / código de Java, 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 en lisp, aunque debido a las primitivas de mapeo, probablemente no sería difícil diseñar un lisp que admitiera bien la concurrencia.

Dicho esto, probé Clojure y odié la sintaxis y el dolor en el factor trasero que parece ir de la mano con todo lo relacionado con Java.

Answer 9

Clojure es '' un lisp '', no es un lisp que ya conoces. He pasado el ultimo Un par de días leyendo el material y viendo los videos, y estoy impresionado. Sus La premisa es que los programas funcionales (basados ??en datos inmutables) son la mejor manera de Gestionar la concurrencia. Clojure implementa un sistema similar a lisp basado en JVM para proporcionarlo.

Answer 10

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. (Nuevos idiomas salen regularmente, pero la mayoría de ellos se quedan en el camino debido al desuso).

Me encanta Common Lisp. Parte de su belleza es su peculiaridad, que proviene del hecho de que fue diseñado por comités con el objetivo de compatibilidad hacia atrás con varios dialectos incompatibles.

Me encanta Scheme. Es un lenguaje hermoso y elegante. Sin embargo, su desarrollo depende de comités, y tal vez eso lo haya frenado a veces. En cualquier caso, sus objetivos son diferentes a los de Clojure.

Common Lisp y Scheme tienen énfasis, como la recursividad de la cola, que no son adecuados para la eficiencia en la JVM. Clojure fue diseñado desde el principio para mapearse bien en la JVM y para 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 necesariamente lo hace mejor que un lenguaje controlado por comités. Si esa persona tomara 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 incluyó un conjunto de funciones sistemáticamente relacionadas que hacen que sea fácil hacer un Mucho con un poco. Eso se aplica tanto a la interoperabilidad JVM básica como al resto del lenguaje. Las personas que controlan Clojure continúan siendo estrictas con respecto a cumplir con los objetivos del lenguaje, hasta ahora.

Esta es una gran parte de lo que me encanta de Clojure: está bien diseñado tanto en su conjunto como en sus detalles. Eso significa que una vez que te acostumbras, es un placer programarlo.

Solo sería un poco exagerado (¿o subestimado?) decir que Clojure tiene el poder de Common Lisp con la elegancia de Scheme. Common Lisp tiene mucho de lo que necesita integrado en el lenguaje, pero es un desastre (lo digo con amor), y cuando necesita algo más que lo que está en el lenguaje, a veces hay varias bibliotecas incompatibles con diferentes compensaciones. El esquema por diseño es pequeño, aunque hay bibliotecas disponibles. Clojure tiene un creciente cuerpo 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 existen diferentes implementaciones de matrices 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 virtudes diferentes.

Answer 11

¡Es nuevo! Lo que significa que no muchos lispers viejos lo usarán, ya que la comunidad tradicional de lisp es buena, tradicional, pero también significa que las personas sin experiencia previa en lisp lo recogerán como algo nuevo.

En mi opinión, Clojure es para Lisps más viejo 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 es visto como un lenguaje en aumento, al igual que Ruby una vez.