¿En qué casos es mejor usar Clojure? [cerrado]

https://stackoverflow.com/questions/1800896

05-07-2019
|

Pregunta

Me desarrollo en Lisp y en Scheme, pero estaba leyendo sobre Clojure y luego quiero saber, ¿en qué casos es mejor usarlo que usar Lisp o Scheme? Gracias

Solución

" Clojure se ejecuta en la JVM " significa que obtienes toda la cornucopia de bibliotecas Java disponibles. Puede crear interfaces gráficas de usuario bonitas en Swing, usar el código de servidor o cliente web de Apache, conectar un solucionador de Sudoku listo ... lo que quiera.

Otra gran ventaja de Clojure es su soporte de concurrencia muy pulido, con aproximadamente 3 sabores diferentes. Si tiene una tarea paralelizada intensiva en cómputo, Clojure puede facilitarlo. Bueno, más fácil.

Actualización: otro argumento. Clojure es bastante funcional, por lo que es una ventaja si quiere obligarse a pensar y escribir funcionalmente.

Otros consejos

Esta pregunta es imposible de responder. Debería usar Clojure casi el 100% del tiempo sobre CL y Scheme, es lo que yo diría. Pero eso no significa que debas escucharme. Otros pueden argumentar que lo contrario es el caso.

Para mí, la sintaxis y los nombres de funciones en Clojure son estéticamente agradables. Ciertas bibliotecas de Java son invaluables para lo que hago para el munging de datos y la programación web y cosas de GUI. La programación funcional es desafiante y agradable. Los defectos de Clojure no son importantes y se ven compensados ??por sus beneficios en mis ojos. Ciertos defectos intolerables en otros Lisps son "fijos" en Clojure, porque es nuevo y puede ignorar la compatibilidad con versiones anteriores. Tiene un enfoque novedoso y posiblemente poderoso para la concurrencia. La comunidad de Clojure es vibrante, acogedora e increíble. Todo esto dice tanto sobre mí y lo que valoro como sobre Clojure u otros Lisps.

Hay bibliotecas para CL y Scheme que no existen en Clojure o Java. Hay personas a las que no les gusta cómo Clojure usa demasiada sintaxis como [] y {} y quieren usar parens en todas partes. Si desea OOP de estilo CLOS o muchas estructuras de datos mutables, podría decirse que otro Lisp es mejor. El JVM es pesado, quizás demasiado pesado y demasiado equipaje para algunas personas. Una gran cantidad de Java se filtra en Clojure (por diseño) y esto ofende la sensibilidad de algunas personas. El STM y las estructuras de datos inmutables tienen gastos generales que hacen que ciertas cosas (por ejemplo, el procesamiento de números) sean más lentas o menos elegantes. Clojure es nuevo y todavía es difícil en ciertas áreas, todavía está cambiando y evolucionando rápidamente en otras. Clojure aún no ha pasado la prueba del tiempo, mientras que otros Lisps ya lo han hecho. Clojure no es un " estándar " y algunas personas encuentran que un lenguaje definido por una implementación no es atractivo. Y así. Ninguna de estas cosas es importante para mí, pero pueden serlo para usted.

Esto es casi completamente subjetivo. El idioma que debe usar depende de lo que ya sabe, lo que está dispuesto a aprender, las bibliotecas que desea usar, los editores y las herramientas con las que se siente cómodo, los defectos de idioma con los que está dispuesto a vivir y trabajar y qué defectos no puedes tolerar y qué te ayuda a hacer tu trabajo más rápido, de manera más económica, más placentera o a alcanzar tus objetivos.

Básicamente, lo que sea que te haga sentir cálido y confuso. Apréndelos todos y luego haga una elección informada basada en sus propios gustos, y use el que más le guste. Todos están bien.

¿Cuándo? Cuanto más se pueda. ¿Por qué? Estructuras de datos inmutables: realmente son tan buenas. Hay muchas otras razones también.

Clojure debe usarse cuando

necesita trabajar con el código java existente.
trabaja con personas alérgicas al lisp (" jefe, me gustaría utilizar una biblioteca de concurrencia de Java llamada clojue vs. Me gustaría volver a escribir esto en el esquema " [1]
estarás programando para un sistema multiprocesador.

El esquema sería mejor cuando:

necesitas probar que tu código es correcto. Clojures (llamada a Java) dificulta pero no impide esto.
está trabajando con personas alérgicas a Java.
está desarrollando una plataforma sin JVM (lo suficientemente nueva)

[1] sí, esta es una mala mala mala razón. tal es el mundo en que vivimos ...

ABCL (Armed Bear Common Lisp) y varias implementaciones de esquemas (KAWA, SISC , ...) también se están ejecutando en la JVM.

Generalmente Common Lisp está disponible en diferentes 'sabores' - ABCL es uno de ellos. Otros compilan a C, a código nativo, tienen amplios entornos de desarrollo o extensiones especializadas como lenguajes lógicos o bases de datos.

Clojure OTOH es un nuevo dialecto de Lisp con énfasis en programación funcional perezosa y programación concurrente. Su autor (Rich Hickey) es un desarrollador de software muy experimentado (también ha escrito interfaces Java y .net para Common Lisp) e hizo un excelente trabajo con Clojure. A pesar de que hay un poco de publicidad en torno al idioma, vale la pena echarle un vistazo: definitivamente es uno de los mejores dialectos de Lisp desarrollados en los últimos años (en comparación con Newlisp o Arc).

Hay muchas razones, algunas mencionadas anteriormente. Mi opinión es:

Las bibliotecas preexistentes. Esto es tal un beneficio. Simplemente no puedo alabar esta característica lo suficiente.
El lenguaje está más adaptado a la hardware actualmente disponible (multi-core) y el desarrollo paradigmas en uso hoy. Es mucho más fácil razonar sobre la concurrencia. Los aspectos funcionales también son más agradables. Puede hacer programación funcional en Lisp, obviamente, pero es muy fácil romper el paradigma sin saberlo, sin saberlo y sin querer.
Plataforma cruzada. Corro idéntico programas en Linux, Windows y el Mac. Hay muchos Lisps nativos que corren a través de plataformas, pero soporte para todas las funciones en todos plataformas es un poco irregular y usted constantemente tiene que estar alerta por cosas que faltan en uno plataforma o la otra. Asimismo, el las bibliotecas que necesita no siempre son constantemente apoyado a través de plataformas ABCL y algunas de las Las implementaciones del esquema JVM tienen esto apoyo constante también, pero yo Todavía prefiero Clojure debido a punto 2.
La naturaleza del lenguaje comunidad. Seamos realistas, muchos el tiempo que la comunidad Common Lisp es desagradable tratar con eso. Es decir No es el caso con Clojure en absoluto. Es fácil obtener ayuda útil sin la condescendencia y la mezquindad que a menudo viene con una respuesta de la Comunidad Lisp común. Como yo tengo aprendí por mí mismo varias veces, no hay duda tan estúpida que no serás educado y servicial respuesta de la comunidad de Clojure.

Si tuviera que encontrar algo de qué quejarme, sería el soporte de IDE. Tal vez sea una cuestión de aprender nuevos hábitos, pero aún es más fácil para mí manejar la mecánica del desarrollo de Java que Clojure. He intentado y uso Clojure Box, enclojure en NetBeas, La Clojure en Intellij IDEA y Counterclockwise en Eclipse. Todos funcionan bien si está trabajando principalmente desde REPL, pero para la compilación y ejecución de archivos de clase, todos se sienten un poco torpes.

Un subconjunto de Clojure también puede compilarse a javascript

Clojure se ejecuta en la JVM (y en el CLR), por lo que existe eso.

El diseño de Clojure se ocupa de acomodar varios estilos de programación concurrente de manera segura, lo que dificulta deliberadamente escribir por error el código peligroso, desvencijado y, a menudo, roto y tolerante a la concurrencia en otros idiomas. Si su dominio problemático involucra programación concurrente, la matriz de herramientas integradas de Clojure para administrar la concurrencia puede ser más adecuada que las bibliotecas específicas de implementación o de mínimo común denominador disponibles en otros Lisps y Esquemas.

Una de las mejores cosas de Clojure es la gran cantidad de bibliotecas que puede usar con él. Tienes el poder de Java con la expresividad de Lisp, y esa es una combinación increíble. Clojure es más adecuado para el desarrollo del mundo real, porque fue hecho para el desarrollo del mundo real. Con Clojure, tiene bibliotecas increíbles, características modernas increíbles y una comunidad increíble de personas útiles y afines.

Debo decir que Clojure es un lenguaje mejor, en todos los sentidos. Esa es una declaración muy argumentativa que hacer, por lo que señalaré aquí que esta es solo mi opinión honesta.

Clojure rocas.

Siempre trato de aprender nuevos idiomas, así que estoy interesado en aprender Clojure. Pero, ¿no son SBCL y otras implementaciones de Common Lisp mucho, mucho más rápidas que Clojure? ¿No necesitaría considerablemente más de 4 procesadores (y una tarea razonablemente paralela) para compensar la diferencia de rendimiento entre una aplicación Clojure e incluso una versión SBCL de un solo subproceso de la misma aplicación?

Como regla general, tiendo a favorecer Clojure sobre otros idiomas en los casos en que cualquiera de estos se ajusta a la ley: (1) El modelo de dominio tiende a parecer muy recursivo y / o gráfico. (2) Existe la oportunidad de aprovechar un entorno JVM multinúcleo (por ejemplo, Elastic Beanstalk) (3) Existe una barrera difusa entre los datos y el código (piense en la calculadora RPN donde los nodos pueden ser operadores o números)

Esto puede sonar un poco artificial, pero gran parte de mi trabajo implica lidiar con gráficos y árboles de información, ya sea mirando las redes sociales, algún tipo de optimización basada en restricciones o la construcción de relaciones semánticas. Me parece que mi otro lenguaje favorito, Ruby, no puede darme la combinación de expresividad y potencia informática en comparación con Clojure, particularmente cuando se trata de resolver problemas cuantitativos, recursivos y de tipo concurrente.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow