J'approuve le commentaire de Dominus Carnufex (du moins, ce que j'en ai lu en diagonale), mais je vais encore une fois jouer le rôle du mauvais flic commentateur désagréable, parce qu'il en faut bien un : il reste encore beaucoup d'inexactitudes, voire d'erreurs dans ton article. Je ne le dis pas pour t'enfoncer, mais pour que tant qu'à écrire sur haskell (super idée, il en faut plus des comme toi !), tu en profites pour te perfectionner.
Une petite liste :
Une fonction dans un langage fonctionnel est une fonction au sens mathématique.
Non, c'est plus que ça. Sans pinailler sur la différence entre fonction et application, en mathématiques, on ne s'intéresse qu'aux images de chaque antécédent par une fonction. En programmation, la façon dont on les calcule est très importante : les fonctions mathématiques $x \mapsto x$ et $x \mapsto cos (arccos (\sqrt x^2))$ sont exactement les mêmes (sur le bon domaine), mais leurs traductions mot-à-mot en haskell ne sont pas du tout équivalentes.
Mon avis personnel est qu'on constate que les programmeurs haskell ont très facilement tendance à faire le raccourci "= en haskell c'est exactement comme le $=$ des maths" (à cause sans doute de l'insistance sur la pureté et sur une certaine mathématisation de la programmation, et probablement aussi d'un effet pervers de la paresse), et que c'est une des raisons pour lesquelles je n'aime pas orienter les gens qui veulent découvrir le fonctionnel vers haskell (surtout s'ils viennent d'un monde mathématique).
(…)
Le paradoxe sur la pureté est un peu fumeux et approximatif, mais il n'y a pas vraiment de bêtise apparente. Je passe.
(…)
L'évaluation paresseuse est une stratégie d'évaluation qui consiste à n'évaluer qu'en cas de besoin. Par exemple, dans le cas suivant:
(…)
calculSuperLourd 1 2 3 ne sera pas évalué, donc cela améliore les performances.
Ta formulation laisse croire que l'évaluation paresseuse par défaut permet d'obtenir des meilleures performances. En pratique, c'est l'inverse : dans certains cas précis (comme l'exemple que tu donnes, qui est artificiellement construit pour), ça permet d'éviter de faire des calculs (voire de terminer au lieu de boucler indéfiniment), mais dans le cas général, la machinerie supplémentaire nécessaire dégrade les performances. D'ailleurs, je ne fréquente pas énormément la communauté haskell, mais la plupart des gens avec lesquels j'ai discuté trouvent que la paresse par défaut est un mauvais choix (ce qui ne rend pas le langage mauvais - et d'ailleurs, c'était une bonne idée d'essayer). D'ailleurs, Idris, qui vient pourtant manifestement de la même communauté, a décidé d'être strict par défaut (ce qui n'empêche pas d'être explicitement paresseux quand c'est nécessaire, comme haskell permet d'être explicitement strict).
Haskell est probablement le langage le plus sûr utilisé en industrie. La notion d'erreur à l'exécution n'existe pas en Haskell (du moins si on évite une poignée de fonctions).
Un des langages les plus sûrs, sans aucun doute, mais "le langage le plus sûr utilisé en industrie", c'est un peu rapide. Par exemple, j'ai entendu dire qu'airbus utilisait CompCert, un compilateur écrit en Coq. Dans le domaine de la sûreté, haskell est à la ramasse 
Quant aux erreurs à l'exécution, c'est faux :
| λ head []
*Exception: Prelude.head: empty list
|
Haskell (comme tous les langages typés statiquement) permet d'éviter les erreurs de type à l'exécution (on est sûr qu'un programme qui compile n'essayera pas d'additionner un entier et une chaîne de caractères). Il existe quand même un paquet d'autres erreurs à l'exécution, et le système de types de haskell n'est pas assez puissant pour toutes les éviter. C'est un compromis nécessaire si on ne veut pas à avoir à écrire des preuves qui font environ la taille du programme pour convaincre le typeur qu'il est correct. C'est ce qu'on fait par exemple en Coq, et ça allonge nettement le temps de développement : il faut choisir le bon compromis pour les tâches qu'on doit résoudre.
Haskell a la philosophie suivante: si le programme compile, alors il est mathématiquement impossible que celui-ci crash.
La même chose que plus haut, mais j'insiste : le système de types de haskell est loin d'être assez puissant pour permettre ce genre de choses. Attention à ne pas trop survendre qand même
(…)
Pour le paragraphe sur le typage, c'est un peu comme sur la sûreté : c'est globalement inexact mais il n'y a pas d'erreur flagrante corrigeable rapidement.
(…)
Pour un langage d'un tel niveau d'abstraction, Haskell a plutôt de bonnes performances. Il est à peu près au niveau de la JVM niveau rapidité mais utilise quatre fois moins de mémoire.
On pourra me répondre que tout est dans le "à peu près", certes, mais avec ce genre d'à peu près, tous les langages sont à peu près aussi rapides que le C 
Surtout que :
Il est tout à fait envisageable de faire un petit jeu 3D en Haskell.
Pouvoir éventuellement faire "un petit jeu 3D", c'est pas si flatteur pour les performances, et cette phrase laisse croire que tu ranges haskell dans la catégorie des langage rigolos, avec lesquels on peut faire des jolies choses, mais qu'on laisse au placard une fois qu'on a fini de jouer avec pour retourner aux langages qui permettent d'écrire des vrais programmes. Crois-moi sur parole : tes lecteurs, qui viendront tous du monde C++/Java/"langage de la vraie vie et pas de chercheur", se jetteront sur la première occasion pour conforter leur idée que les langages fonctionnels ne sont pas adaptés au "monde réel", même si tout le reste de ton article insiste sur le contraire. Ne leur donne pas ce plaisir !
(…)
Sur la partie "domaines de prédilection", j'ai une approche complémentaire de celle de dominus carnufex : lui trouve qu'ils ne sont pas assez excitants pour le lecteur lambda (ce que je lui concède bien volontiers), mais moi qui suis un peu plus excité par ce genre de choses, je trouve un peu dommage de balancer comme ça "haskell c'est cool pour écrire un compilateur/la concurrence" sans expliquer un peu pourquoi (respectivement et pour faire bref, parce que les types algébriques et l'expressivité du langage permettent de manipuler facilement le genre de données structurées qu'on rencontre dans le traitement d'un programmes, et parce que l'idéal du "sans effet de bord" rend de facto obsolète le besoin de verrous et tous les problèmes qui vont avec).
Apprendre Haskell vous permettra d'ouvrir votre esprit et d'élargir vos connaissances
Oui ! Comme quoi, je ne fais pas que critiquer : ce paragraphe est très bien. Si tu veux pousser les gens à apprendre haskell, c'est finalement la seule raison valable : tu ne convaincras pas grand monde d'apprendre haskell dans le but de l'utiliser réellement, mais les gens intelligents doivent pouvoir comprendre qu'apprendre un langage qui propose une vision différente de la programmation les rendra meilleurs même s'ils reviennent à d'autres langages plus répandus (et comme il y en a quelques uns qui se perdent en route, c'est comme ça que la communauté s'agrandit 
).
Par contre, je suis beaucoup moins d'accord avec la partie "pourquoi ne pas apprendre haskell". D'abord, la partie sur les salaires est probablement fausse (mais elle n'est pas vraiment pertinente, parce que c'est surtout une question de domaine dans lequel on travaille), et ensuite, la partie sur "si vous aimez pas les maths, vous aimerez pas haskell" ne fait que contribuer à répandre des préjugés qui ont déjà la vie assez dure comme ça. Ce n'est pas parce qu'on n'a aucune chance de s'intéresser par les modèles catégoriques du lambda calcul qu'on est incapable d'apprécier la sûreté du typage statique !
Il ne faut pas mal prendre ce message : globalement, je trouve qu'on parle bien trop peu de haskell sur zds, et beaucoup trop des langages mainstream dont on entend déjà parler partout. C'est une très bonne chose d'avoir ce genre d'article, mais écrire sur haskell n'est pas suffisant, il faut écrire bien, et j'espère que ces remarques t'aideront à améliorer tes connaissances du langage et les écrits qui viendront avec.
