Haskell, Lisp y verbosidad [cerrado]

Para aquellos de ustedes con experiencia tanto en Haskell como en Lisp, tengo curiosidad por saber cuán "agradable" (para usar un término horrible) es escribir código en Haskell vs. Lisp.

Algunos antecedentes: estoy aprendiendo Haskell ahora, habiendo trabajado anteriormente con Scheme y CL (y una pequeña incursión en Clojure). Tradicionalmente, podrías considerarme un fanático de los lenguajes dinámicos por la brevedad y rapidez que brindan. Rápidamente me enamoré de las macros Lisp, ya que me dieron otra forma de evitar la verbosidad y la repetición.

Haskell me parece increíblemente interesante, ya que me presenta formas de codificación que no sabía que existían. Definitivamente tiene algunos aspectos que parecen ayudar a lograr la agilidad, como la facilidad para escribir funciones parciales. Sin embargo, estoy un poco preocupado por perder las macros Lisp (supongo que las pierdo; la verdad es que es posible que aún no las haya aprendido) y el sistema de escritura estática.

¿A alguien que haya hecho una cantidad decente de codificación en ambos mundos le importaría comentar cómo difieren las experiencias, cuál prefiere y si dicha preferencia es situacional?

Respuesta corta:

• Casi todo lo que puede hacer con macros lo puede hacer con una función de orden superior (e incluyo mónadas, flechas, etc.), pero puede requerir más pensamiento (pero solo la primera vez, y es divertido y usted será un mejor programador para ello), y
• el sistema estático es lo suficientemente general como para que nunca se interponga en su camino, y de manera algo sorprendente en realidad "ayuda a lograr agilidad" (como usted dijo) porque cuando su programa se compila puede estar casi seguro de que es correcto, por lo que esta certeza le permite probar cosas que de otro modo tendrías miedo de probar; hay una sensación "dinámica" en la programación, aunque no es lo mismo que con Lisp.

[Nota: Hay una " Plantilla Haskell " que le permite escribir macros como en Lisp, pero estrictamente hablando, nunca debería necesitarla .]

En primer lugar, no se preocupe por perder características particulares como la escritura dinámica. Como está familiarizado con Common Lisp, un lenguaje notablemente bien diseñado, supongo que es consciente de que un lenguaje no se puede reducir a su conjunto de características. Se trata de un todo coherente, ¿no?

En este sentido, Haskell brilla tan intensamente como Common Lisp. Sus características se combinan para proporcionarle una forma de programación que hace que el código sea extremadamente corto y elegante. La falta de macros se mitiga un poco con conceptos más elaborados (pero, igualmente, más difíciles de entender y usar) como mónadas y flechas. El sistema de tipo estático aumenta su poder en lugar de interponerse en su camino como lo hace en la mayoría de los lenguajes orientados a objetos.

Por otro lado, la programación en Haskell es mucho menos interactiva que Lisp, y la enorme cantidad de reflexión presente en lenguajes como Lisp simplemente no encaja con la visión estática del mundo que presupone Haskell. Por lo tanto, los conjuntos de herramientas disponibles son bastante diferentes entre los dos idiomas, pero difíciles de comparar entre sí.

Personalmente, prefiero la forma de programación Lisp en general, ya que creo que encaja mejor con la forma en que trabajo. Sin embargo, esto no significa que esté obligado a hacerlo también.

Hay menos necesidad de metaprogramación en Haskell que en Common Lisp porque mucho se puede estructurar alrededor de mónadas y la sintaxis agregada hace que los DSL integrados se vean menos como árboles, pero siempre existe Template Haskell, como lo menciona ShreevatsaR , e incluso Liskell (Haskell semántica + Lisp sintaxis) si le gustan los paréntesis.

En cuanto a las macros, aquí hay una página en la que se habla de ello: Hola Haskell, Adiós Lisp . Explica un punto de vista donde las macros simplemente no son necesarias en Haskell. Viene con un pequeño ejemplo de comparación.

Caso de ejemplo en el que se requiere una macro LISP para evitar la evaluación de ambos argumentos:

(defmacro doif (x y) `(if ,x ,y))

Caso de ejemplo en el que Haskell no evalúa sistemáticamente ambos argumentos, sin la necesidad de nada como una definición de macro:

doif x y = if x then (Just y) else Nothing

Y voilá

Soy programador de Common Lisp.

Después de haber probado Haskell hace algún tiempo, mi resultado final personal era seguir con CL.

Razones:

• mecanografía dinámica (consulte la escritura dinámica frente a la estática: un análisis basado en patrones de Pascal Costanza )
• argumentos opcionales y de palabra clave
• sintaxis uniforme de lista homoicónica con macros
• sintaxis de prefijo (no es necesario recordar las reglas de precedencia)
• impuro y, por lo tanto, más adecuado para la creación rápida de prototipos
• potente sistema de objetos con protocolo de metaobjetos
• estándar maduro
• amplia gama de compiladores

Haskell tiene sus propios méritos, por supuesto, y hace algunas cosas de una manera fundamentalmente diferente, pero para mí no es suficiente a largo plazo.

En Haskell puede definir una función if, lo cual es imposible en LISP. Esto es posible debido a la pereza, que permite una mayor modularidad en los programas. Este artículo clásico: Por qué es importante la FP de John Hughes, explica cómo la pereza mejora la composibilidad.

Hay cosas realmente interesantes que puedes lograr en Lisp con macros que son engorrosas (si es posible) en Haskell. Tomemos, por ejemplo, la macro "memoize" (véase el capítulo 9 del PAIP de Peter Norvig). Con él, puede definir una función, digamos foo, y luego simplemente evaluar (memoize 'foo), que reemplaza la definición global de foo con una versión memoizada. ¿Puede lograr el mismo efecto en Haskell con funciones de orden superior?

A medida que continúo mi viaje de aprendizaje de Haskell, parece que una cosa que ayuda a "reemplazar" las macros es la capacidad de definir sus propios operadores infijos y personalizar su precedencia y asociatividad. Un poco complicado, ¡pero un sistema interesante!