Y a-t-il des inconvénients ou des problèmes avec Haskell?

Je cherche à plonger dans Haskell pour mon prochain projet personnel (relativement trivial). Les raisons pour lesquelles je m'attaque à Haskell sont les suivantes:

1. Me lancer dans un langage purement fonctionnel
2. La vitesse. Bien que je sois sûr que cela puisse être discuté, le profil que j’ai vu des clous Haskell proches du C ++ (et qui semble être un peu plus rapide que Erlang).
3. La vitesse. Le serveur Web de Warp semble être fou rapide par rapport à pratiquement tout le reste .

Donc, étant donné cela, ce que je recherche, ce sont les inconvénients ou les problèmes qui accompagnent Haskell. Le Web contient énormément d’informations sur les raisons pour lesquelles Haskell est une bonne chose, mais je n’ai pas trouvé beaucoup de sujets sur son côté laid (à part des reproches sur sa syntaxe qui ne me dérangent pas du tout).

Un exemple de ce que je recherche pourrait être le GIL de Python. Quelque chose qui n'a pas fait son chemin jusqu'à ce que je commence vraiment à envisager l'utilisation de la simultanéité dans un environnement CPython.

Quelques inconvénients auxquels je peux penser:

• En raison de la nature de la langue et de ses racines solides dans le monde universitaire, la communauté est très soucieuse des mathématiques; Si vous êtes une personne pragmatique, cela peut parfois être accablant, et si vous ne parlez pas le jargon, vous aurez plus de difficulté que dans beaucoup d'autres langues.
• Bien qu'il existe une richesse incroyable de bibliothèques, la documentation est souvent laconique.
• Les tutoriels d'entrée de gamme sont rares et difficiles à trouver. La courbe d'apprentissage initiale est donc assez raide.
• Quelques fonctionnalités linguistiques sont inutilement maladroites; Un exemple frappant est la façon dont la syntaxe d'enregistrement n'introduit pas d'étendue de dénomination. Il est donc impossible de définir le même nom de champ d'enregistrement dans deux types différents dans le même espace de nom de module.
• Haskell adopte par défaut une évaluation paresseuse. Bien que ce soit souvent une bonne chose, cela peut parfois vous faire mal. Utiliser naïvement une évaluation paresseuse dans des situations non triviales peut entraîner des goulots d'étranglement inutiles en termes de performances. Comprendre ce qui se passe sous le capot n'est pas tout à fait simple.
• Une évaluation paresseuse (associée en particulier à la pureté et à un compilateur optimisant de manière agressive) signifie également que vous ne pouvez pas facilement raisonner à propos de l'ordre d'exécution; en fait, vous ne savez même pas si un certain morceau de code est réellement évalué dans une situation donnée. Par conséquent, le débogage du code Haskell nécessite un état d'esprit différent, ne serait-ce que parce que parcourir votre code est moins utile et moins significatif.
• En raison de la pureté de Haskell, vous ne pouvez pas utiliser les effets secondaires pour faire des choses comme I / O; vous devez utiliser une monade et une évaluation «abusive» paresseuse pour obtenir une interactivité, et vous devez faire glisser le contexte monadique partout où vous voudrez peut-être effectuer des E / S. (Ceci est en fait une bonne fonctionnalité à bien des égards, mais cela rend parfois impossible le codage pragmatique.)

La plupart des inconvénients de Haskell (ainsi que l'essentiel de ses avantages) proviennent de ses deux caractéristiques déterminantes: il est paresseux et purement fonctionnel.

Être paresseux rend plus difficile la raisonnement sur la performance. Surtout pour les personnes qui ne sont pas habituées à la paresse, mais même pour les Haskellers expérimentés, il peut être difficile de voir comment la paresse affectera les performances dans certains cas.

La paresse signifie également qu'il est plus difficile de créer des repères précis sans utiliser des bibliothèques telles que Criterion.

Être purement fonctionnel signifie que chaque fois que vous aurez besoin d'utiliser des structures de données modifiables (dans les cas où il n'est pas possible d'obtenir la performance souhaitée sans elles - bien que, grâce à l'optimiseur de GHC, cela ne se produise pas aussi souvent que vous ne le pensez), coincé dans la monade IO (ou ST), ce qui rend le code plus lourd.

Puisque vous avez mentionné la vitesse parmi vos objectifs, je tiens à souligner qu’il existe souvent d’énormes différences de performances entre le code Haskell optimisé à la main et le code Haskell qui a été écrit sans trop réfléchir aux performances (plus que dans d’autres langues). Et le code Haskell optimisé à la main est souvent très laid (bien que je suppose que cela est également vrai dans la plupart des autres langues).

Je ne suis pas un expert de Haskell: j'ai appris les bases mais, malheureusement, je n'ai pas eu la chance de faire un projet sérieux à Haskell (j'aimerais bien, car j'aime beaucoup cette langue).

Cependant, d'après ce que je sais et d'après une discussion avec quelqu'un qui travaille dans un domaine proche de la programmation fonctionnelle, Haskell n'est peut-être pas la meilleure solution lorsque vous souhaitez implémenter des algorithmes de graphes, où vous devez par exemple parcourir le graphique et effectuer des analyses. beaucoup de changements locaux sur la structure du graphe.

Comme un graphe n’a généralement pas de structure récursive, j’estime que la meilleure approche consiste à construire une copie du graphe en utilisant des structures et des pointeurs entre eux (comme vous pouvez le faire par exemple en C ++) et à manipuler cette copie en modifiant les pointeurs. créer ou détruire des nœuds, etc.

Je me demande comment de telles structures et opérations de données peuvent être traitées correctement dans Haskell, car à ma connaissance, il n'est pas possible d'utiliser la représentation / approche ci-dessus. Certains problèmes liés aux algorithmes de graphes dans Haskell sont brièvement décrits dans cet article.

MODIFIER

J'ai récemment parlé à un expert en programmation fonctionnelle et il a confirmé que la mise en œuvre efficace de certains algorithmes de graphes peut être assez délicate en Haskell: déplacer des pointeurs comme vous le faites en C ou C ++ peut être beaucoup plus rapide.

Le seul inconvénient de Haskell est que c'est différent. C’est un pas en avant par rapport aux langues qui sont plus couramment enseignées ou parlées, ce qui entraîne une courbe d’apprentissage plus longue. C'est également un langage moins populaire qui peut limiter la disponibilité de l'aide si vous êtes bloqué. Ce ne sont pas vraiment des inconvénients majeurs cependant.

L'inconvénient potentiel est qu'il s'agit d'un langage fonctionnel, ce qui le rend moins utile pour certains domaines problématiques, mais cela vaut également pour les langages orientés objet. En général, les langues ne présentent pas de véritables négatifs au-delà des courbes d'apprentissage, du moins pour les langues relativement populaires. Tant qu'une langue est complète, elle est théoriquement capable de tout.

Donc, étant donné cela, ce que je recherche, ce sont les inconvénients ou les problèmes qui viennent avec Haskell.

Les "problèmes avec Haskell" ont tendance à apparaître dans certains domaines. Haskell est un langage merveilleux pour la programmation d'applications, bien plus agréable à écrire que n'importe quoi d'autre. Les problèmes ont tendance à surgir lorsque vous essayez de faire quelque chose pour lequel il n’ya pas de soutien, comme:

• Cross compilation. GHC peut être construit en tant que compilateur croisé, mais le processus est plutôt impliqué.
• Applications embarquées. Haskell a la gestion de la mémoire via un ramasse-miettes, donc celui-ci n'est pas trop surprenant.
• La vitesse. Haskell n’est pas aussi rapide que Rust, bien que dans la plupart des cas, la concurrence soit assez bonne. Cela dépend beaucoup du domaine d'application - les calculs purs sont bien optimisés, mais quelque chose comme "lire un fichier dans un tampon et compter le nombre de lignes" est plus difficile à exprimer en Haskell.