Quitter Haskell derrière soi

• L’auteur partage son parcours pour s’éloigner de Haskell, un langage de programmation fonctionnelle qu’il a utilisé pendant dix ans comme ingénieur logiciel.
• L’auteur a été attiré par la capacité de Haskell à comprendre le code de manière symbolique et algébrique, ainsi que par la robustesse de son système de types.
• Le système de types de Haskell permet une vérification stricte des types sans être excessivement restrictif ni trop verbeux, ce qui facilite l’écriture et la maintenance du code.
• L’auteur a particulièrement apprécié la capacité de Haskell à exprimer des invariants via les types, ce qui permet au compilateur de revérifier la logique et améliore la sécurité ainsi que la précision du code.
• Malgré ces avantages, l’auteur s’est éloigné de Haskell pour trois raisons principales : la recherche permanente de nouveauté stylistique, des outils maladroits et un changement continu.
• La nouveauté stylistique renvoie à la tendance de la communauté Haskell à expérimenter de nouvelles abstractions, ce qui peut être innovant mais aussi rendre la maintenance du code plus difficile.
• L’auteur juge les outils de Haskell « corrects », mais souligne qu’aucun n’est aussi simple d’utilisation et aussi fiable que cargo de Rust.
• L’évolution continue de Haskell, en particulier les modifications régulières sans compatibilité descendante, a accru les frictions liées à l’usage du langage.
• Bien qu’il se soit éloigné de Haskell, l’auteur continue de reconnaître ses points forts : la capacité à refactoriser le code de façon algébrique, son système de types et son écosystème de bibliothèques déclaratives.
• L’auteur conclut que l’usage de Haskell dépend des objectifs de chacun. Il recommande de l’apprendre pour devenir un meilleur programmeur, tout en appelant à la prudence avant d’en faire son langage principal en raison des difficultés qu’il a décrites.

[GN⁺]

Commentaires Hacker News

• La communauté Haskell est connue pour mettre fortement l’accent sur l’apprentissage et pour favoriser un environnement de curiosité et de partage des connaissances.
• Cependant, la communauté a souvent du mal à abandonner des idées après les avoir testées, ce qui rend les bases de code Haskell professionnelles confuses.
• L’outillage de Haskell est critiqué, même si certains soutiennent que la plupart des langages de programmation disposent d’un outillage encore inférieur.
• L’outillage de Haskell possède une fonctionnalité unique, Hoogle, qui est très appréciée pour son utilité.
• L’évolution de Haskell et de sa seule implémentation publique raisonnable, GHC, est critiquée en raison des changements constants et du manque de cohérence.
• Le lien entre GHC et certaines versions de la bibliothèque standard base est perçu comme un problème, car il force des changements dans les dépendances à chaque sortie d’une nouvelle version de GHC.
• La perte d’intérêt de l’auteur pour Haskell est attribuée à trois facteurs principaux : une recherche de nouveauté stylistique, un outillage maladroit et des changements permanents.
• La documentation et l’outillage de Haskell étaient difficiles à utiliser, et les allers-retours de la communauté entre Cabal, Stack, puis de nouveau Cabal sont vus comme un signe d’amélioration.
• D’autres langages de programmation ont intégré des éléments de programmation fonctionnelle, ce qui les rend plus attrayants pour certains développeurs.
• Certains développeurs sont passés de Haskell à F# parce qu’ils trouvent l’écriture du code plus simple.
• Haskell est considéré comme difficile à apprendre, et ses bibliothèques sont souvent obsolètes ou incomplètes.
• Les performances de Haskell sont critiquées, et l’évaluation paresseuse entraîne des problèmes de mémoire et des performances lentes.
• Les perspectives d’emploi sont jugées limitées pour les développeurs Haskell en raison du caractère très spécifique du langage.
• Le débogage en Haskell est décrit comme difficile en raison de la complexité du langage.
• Scala est considéré comme une bonne alternative à Haskell, offrant les avantages des deux mondes.
• Certains remettent en question la nécessité des fonctionnalités avancées du langage dans les tâches ordinaires d’ingénierie logicielle.
• L’accent mis par Haskell sur la recherche et la démarche académique est vu comme pouvant entrer en conflit avec les besoins de la programmation pratique.
• Le billet suggère qu’il faut un moyen de séparer les fonctionnalités expérimentales des fonctionnalités stables dans Haskell.
• L’auteur explique qu’il ne se sent pas poussé à utiliser les nouvelles fonctionnalités avancées du système de types de Haskell et suggère de développer une intuition sur le niveau de complexité typée à adopter.