Re: Moi == pas doué, je suppose....

Juste une chose, je ne défend pas Haskell bec et ongles, je gagne ma vie en faisant du C++, j'ai contribué et je contribue encore a Python où à des projets en Python et j'apprécie Haskell.

Je précise aussi que je suis loin de détester Haskell, c'est un des premiers langages que j'ai appris parce que le côté mathématique m'attirait (je suis mathématicien à la base), et il y a bien des choses que j'apprécie dans ce langage (en fait, je suis capable sans problème d'aimer des langages aux philosophies totalement opposées :) ).

me fait peur avec ses deux ;;

Les ;; c'est que pour la REPL uniquement, normalement on n'en écrit jamais. Ceci dit, pour Hello World j'exagère un peu en ce qui concerne Haskell, mais pour des choses un poil plus compliquées, si on comprend pas ce qu'est la monade IO dont on ne peut pas sortir, il y a de quoi s'étonner, quand même (quelqu'un qui veut débugger une fonction avec un print aura une mauvaise surprise, par exemple).

Blague à part, je n'ai jamais fais de OCaml car en voyant que tous les étudiants de prépas "prestigieuses" en faisait, j'ai eu l'impression que c'était un langage théorique pour matheux, surtout sachant que c'était poussé par l'INRIA.

Je crois que tu te fais des idées : OCaml c'est à peu près le même public que Haskell, j'ai l'impression, avec un bon pourcentage de public académique qui aime les systèmes de types dans les deux cas. Ceci dit, Haskell a un système de types plus compliqué qu'OCaml, et a un modèle pour l'IO moins simple. Par exemple, utiliser des tableaux mutables (parfois c'est nécessaire) est une plaie en Haskell (soit IO soit ST, dans les deux cas ça ne s'intègre pas très naturellement avec le reste), alors que c'est simple en OCaml et dans la plupart des langages. Tout est question de compromis, et là où Haskell perd il gagne ailleurs, mais comme c'est sur des choses assez atypiques, ça surprend.

J'étais initialement d'accord avec toi. Finalement, je trouve agréable le fait qu'un fold représente vraiment une opération de plus haut niveau. Puis une boucle, c'est ENORMEMENT de concepts d'un coup. Aux heures sombres de ma vie, j'ai enseigné à l'IUT, la fac et en école d'ingénieur à des groupes de débutant et je peux t'assurer que les boucles ce n'est pas une mince affaire, les étudiants oublient de l'initialiser, d’incrémenter l'iterateur, ne comprennent pas ce que cela fait vraiment.

Par boucle je pensais à des boucles de plus haut niveau permettant d'itérer sur une liste, par exemple, pas une boucle for C. Et je dis pas que le fold c'est mal, je dis juste que dans ces cas là, par rapport à une boucle de haut niveau, c'est à peu près pareil à l'usage, avec des chances similaires de faire des erreurs, juste qu'au lieu d'avoir une syntaxe spécifique on doit se rappeler de la signature de fold (fold_left, bien sûr). Après, personnellement, mon problème avec le fold, c'est que je ne me souviens jamais de l'ordre des arguments entre l'élément initial et la liste (je me souviens juste qu'en Coq c'est l'inverse d'OCaml, et comme j'utilise les deux assez souvent ça n'aide pas :) ).

Ça c'est deux bonnes heures d'explication à des étudiants en stress énorme... Même après plus de 12 ans de python, je me plante encore des fois sur ce genre de bêtise...

J'aime pas spécialement la sémantique de copie de référence non plus (je suis plus habitué au Perl qui passe par valeur et fait des vraies copies à moins de créer explicitement des références).

Bref, là où je veux en venir c'est que je suis d'accord Haskell est un language complexe, comme beaucoup, mais pas forcement plus compliqué à comprendre que d'autre, c'est juste que les problèmes sont autre part.

Je suis bien d'accord. D'ailleurs, du C++ je n'en ai fait qu'une seule fois, et ça m'a semblé le genre de langage que si on n'en fait pas pendant un an, il faut réapprendre (comme Haskell). Ceci dit, comme tu dis, les points difficiles ne sont pas au mêmes endroits.

Oui... Et non... Si l'abstraction est bien faite, tu peux comprendre ce que le code représente sans pour autant comprendre comment cela fonctionne.

Oui, mais des fois c'est pas évident de comprendre une abstraction : de temps en temps si l'abstraction ou la doc ne sont pas suffisamment claires et qu'il te faut regarder le code (ou l'abstraction n'est pas totale et te fait manipuler des Lens explicitement ou autre, ou t'expose une API pour faire du xml avec des Arrows), là tu dois vraiment potasser un peu avant de comprendre de quoi il retourne.

Parce que les projets non documentés en python avec des API qui acceptent des chaînes de caractères à la place d'un Enum et pour lesquelles tu dois chercher dans le code source pour savoir quels sont les valeurs possibles et qui ne pètent pas le jour où la valeur choisie disparaît de la lib.

Peut-être, je n'ai jamais utilisé beaucoup plus que la librairie standard en Python. Peut-être que je suis trop habitué au Perl, où l'habitude de mettre un Synopsis avec des exemples est très encrée dans la culture. Il faut dire que contrairement à Haskell ou OCaml, ou un langage avec au moins des signatures plus formelles, il n'y a pas trop le choix, car pas de documentation automatique des signatures et pas moyen du coup d'imaginer comment agencer quoi que ce soit, du coup ça incite peut-être à mettre des exemples et écrire une documentation moins automatique et plus pragmatique.