guide - clojure tutorial
¿Por qué Clojure sobre otros Lisps de JVM: Kawa, Armed Bear o SISC? (11)
"Clojure es un Lisp no restringido por la compatibilidad con versiones anteriores" (es del sitio web de Clojure). Es un nuevo comienzo. Es progreso. Use las ideas que hacen que Lisp / Scheme sea poderoso, pero reconstrúyalos alrededor de 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 con simultaneidad en mente.
La JVM ya tenía tres Lisp antes de que Clojure llegara a la escena: Kawa , Armed Bear y SISC .
¿Qué brecha llena Clojure que dejaron esos Lisp?
¡Es nuevo! Lo que significa que no muchos de los antiguos usuarios lo usarán, ya que la comunidad de lisp tradicional es buena, tradicional, pero también significa que las personas sin experiencia previa de ceceo lo tomarán como algo nuevo.
Imho, Clojure es para los viejos Lisp 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.
Clojure es "un ceceo", no es ningún ceceo que usted ya sepa. Pasé los últimos días leyendo el material y viendo los videos, y estoy impresionado. Su premisa es que los programas funcionales (basados en datos inmutables) son la mejor manera de administrar la concurrencia. Clojure implementa un sistema de ceceo basado en JVM para proporcionarlo.
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 llena un espacio . 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ías 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 por defecto.
Bueno, Clojure te permite escribir programas simultáneos por defecto.
La página de justificación en clojure.org dice:
¿Por qué escribí otro lenguaje de programación? Básicamente porque yo quería:
- Un Lisp
- para la Programación Funcional
- simbiótico con una plataforma establecida
- diseñado para Concurrencia
y no pude encontrar uno.
¿Los 3 idiomas que mencionaste (Kawa, ABCL y SISC) cumplen con estos requisitos? Son:
- Lisps (los dialectos CL o Scheme) ✓
- para Programación Funcional ✓
- simbiótico con una Plataforma establecida (la JVM) ✓
pero no están diseñados para simultanear (STM); sin embargo, para ser justos y completos, hay al menos 2 bibliotecas de STM que encontré para CL que aún no se han mencionado:
- STMX
- Probado trabajando en ABCL. En desarrollo activo.
- CL-STM
- ¿Muerto? El último cambio fue en 2007.
Hmm ... ¿Por qué crear un nuevo 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)?
- Lento / sin innovación después de la estandarización
- Estructuras de datos principales mutables, no extensibles
- Sin concurrencia en las especificaciones
- Ya existen buenas implementaciones para JVM (ABCL, Kawa, SISC y otros)
- Los Lisp estándar son sus propias plataformas
Es un problema de diseño de simultaneidad del lenguaje , como han mencionado otros.
Además, ¿por qué parar en la JVM? El soporte Clojure CLR está en desarrollo activo .
Esas son las dos brechas 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.
La respuesta más simple que puedo encontrar es que Clojure no es Common-Lisp. Clojure no está limitado por la historia de otros Lisps. Es un nuevo lenguaje creado para la JVM.
La ventaja de Clojure es que le da acceso a todas las librerías / código de Java que existen, y soporte multi-threading 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.
Habiendo dicho eso, probé Clojure y odié la sintaxis y el dolor en el trasero que parece estar de acuerdo con cualquier cosa relacionada con Java.
No es necesario que tengamos una respuesta más (y no espero votos para esta), pero aquí hay algunas pequeñas mejoras para muchas 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 falta de uso).
Amo 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.
Amo a 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 la recursividad de cola que no es adecuada 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 necesariamente lo hace 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 que está 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.
Si fuera cínico, diría que es porque Clojure tiene un Clojure y un nombre más atractivo.
Simplemente no estaba al tanto de eso, lo cual es un beneficio serio para Clojure (que la gente hizo suficiente ruido como para enterarme). Lo más importante 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 hacer la interoperación.
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 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 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 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.