¿Hay desventajas o problemas con Haskell?

Algunas desventajas que se me ocurren:

• Debido a la naturaleza del lenguaje y sus sólidas raíces en el mundo académico, la comunidad tiene una mentalidad muy matemática; Si eres una persona pragmática, esto puede ser abrumador a veces, y si no hablas la jerga, te será más difícil que con muchos otros idiomas.
• Si bien hay una increíble riqueza de bibliotecas, la documentación suele ser escasa.
• Los tutoriales de nivel de entrada suaves son pocos y difíciles de encontrar, por lo que la curva de aprendizaje inicial es bastante pronunciada.
• Algunas características del lenguaje son innecesariamente torpes; un ejemplo destacado es cómo la sintaxis de registro no introduce un ámbito de denominación, por lo que no hay forma de tener el mismo nombre de campo de registro en dos tipos diferentes dentro del mismo espacio de nombres de módulo.
• Haskell utiliza de manera predeterminada la evaluación perezosa, y aunque a menudo esto es una gran cosa, a veces puede morderte de forma desagradable. El uso ingenuo de la evaluación perezosa en situaciones no triviales puede llevar a cuellos de botella innecesarios en el rendimiento, y entender lo que sucede debajo del capó no es exactamente sencillo.
• La evaluación perezosa (especialmente combinada con la pureza y un compilador de optimización agresiva) también significa que no se puede razonar fácilmente sobre el orden de ejecución; de hecho, ni siquiera sabe si un determinado fragmento de código realmente se evalúa en una situación determinada. En consecuencia, la depuración del código de Haskell requiere una mentalidad diferente, aunque solo sea porque revisar su código es menos útil y menos significativo.
• Debido a la pureza de Haskell, no puede usar efectos secundarios para hacer cosas como I / O; tienes que usar una evaluación monádica y perezosa de "abuso" para lograr la interactividad, y tienes que arrastrar el contexto monádico a cualquier lugar donde desees hacer I / O. (En realidad, esta es una buena característica de muchas maneras, pero a veces hace que la codificación pragmática sea imposible).

La mayoría de las desventajas de Haskell (así como la mayor parte de la de Haskell) provienen de sus dos características definitorias: es perezoso y puramente funcional.

Ser perezoso hace que sea más difícil razonar acerca del rendimiento. Especialmente para las personas que no están acostumbradas a la pereza, pero incluso para los Haskeller experimentados puede ser difícil ver cómo la pereza afectará el rendimiento en ciertos casos.

La pereza también significa que es más difícil crear puntos de referencia precisos sin usar bibliotecas como Criterion.

Ser puramente funcional significa que siempre que necesite utilizar estructuras de datos mutables (en los casos en los que no es posible lograr el rendimiento deseado sin ellos), aunque gracias al optimizador de GHC que no ocurre con la frecuencia que usted piensa, quedará atrapado en la mónada IO (o ST), lo que hace que el código sea más engorroso.

Como mencionó la velocidad como uno de sus objetivos, debo señalar que a menudo hay grandes diferencias en el rendimiento entre el código Haskell optimizado a mano y el código Haskell que se escribió sin pensar mucho en el rendimiento (más que en otros idiomas). ). Y el código Haskell optimizado a mano a menudo es bastante feo (aunque supongo que también es cierto en la mayoría de los otros idiomas).

No soy un experto en Haskell: he aprendido lo básico pero desafortunadamente no lo he hecho. tuve la oportunidad de hacer un proyecto serio en Haskell (aunque me gustaría, porque me gusta mucho este idioma).

Sin embargo, por lo que sé y por una discusión con alguien que ha estado trabajando en un campo bastante cercano a la programación funcional, Haskell podría no ser el mejor Solución cuando desee implementar algoritmos de gráficos, donde los necesite, por ejemplo. para recorrer el gráfico y realizar muchos cambios locales en la estructura del gráfico.

Dado que una gráfica no tiene una estructura recursiva en general, mi sensación es que el mejor enfoque es construir una copia del gráfico usando estructuras y punteros entre ellos (como puede hacer, por ejemplo, en C ++) y manipular eso copiar cambiando los punteros, creando o destruyendo nodos, y así sucesivamente.

Me pregunto cómo estas estructuras de datos y operaciones pueden manejarse adecuadamente. en Haskell, ya que, según mi conocimiento, en Haskell no es posible utilizar la representación / enfoque anterior. Algunos problemas con los algoritmos de gráficos en Haskell se tratan brevemente en este artículo

EDIT

Hace poco hablé con un experto en programación funcional y él confirmó que implementar cierto algoritmo de graficación de manera eficiente puede ser bastante complicado en Haskell: mover los punteros como lo hace en C o C ++ puede ser mucho más rápido.

El lado negativo de Haskell es que es diferente. Es un paso más lejos de los idiomas que se enseñan o hablan más comúnmente, por lo que habrá una curva de aprendizaje más grande. También es un lenguaje menos popular que puede limitar la disponibilidad de ayuda si te quedas atascado. Sin embargo, estos realmente no son inconvenientes importantes.

Lo único que es un inconveniente potencial es que es un lenguaje funcional, por lo que es menos útil para ciertos dominios de problemas, pero esto también es válido para lenguajes orientados a objetos. En general, los idiomas no tienen negativos verdaderos más allá de las curvas de aprendizaje, al menos para los idiomas relativamente populares. Mientras un idioma esté completo, Turing es teóricamente capaz de cualquier cosa.

  

Entonces, dado esto, lo que busco son las desventajas o los problemas que vienen con Haskell

Los "problemas con Haskell" tienden a aparecer en ciertos dominios. Haskell es un lenguaje maravilloso para la programación de aplicaciones, mucho más agradable de escribir que cualquier otra cosa. Los problemas tienden a surgir cuando intentas hacer algo para lo que no hay un buen soporte, como:

• compilación cruzada. GHC puede construirse como un compilador cruzado, pero el proceso es bastante complicado.
• Aplicaciones integradas. Haskell tiene gestión de memoria a través de un recolector de basura, por lo que este no es demasiado sorprendente.
• velocidad. Haskell no es tan rápido como Rust, aunque en la mayoría de los casos competirá bastante bien. Depende mucho del dominio de la aplicación: los cálculos puros se optimizan bien, pero algo como "leer un archivo en un búfer y contar el número de líneas" es más difícil de expresar en Haskell.