OCaml plutôt que Haskell ?

[amarandon]

J’ai un peu essayé Haskell mais je suis découragé par la lenteur et le manque de robustesse de l’installation de packages avec cabal. Il existe d’ailleurs l’expression Cabal Hell au sein de la communauté Haskell pour décrire la situation dans laquelle on n’arrive pas à installer un package. La lenteur est notamment due au fait que la moindre fonctionalité est scindée en une multitude de bibliothèques très spécialisées. Il est étonnant par exemple de constater le nombre de dépendances d’un simple parseur JSON comme Aeson. Installer un framework web comme Yesod prends beaucoup de temps.

Un autre aspect que je n’aime pas beaucoup dans la culture Haskell est la tendance à utiliser des variables d’une seule lettre et des opérateurs à base de caractères spéciaux, y compris dans les bibliothèque tierces, plutôt que des noms de variable et de fonction explicites. Cela donne parfois au code Haskell un petit air de Perl codé sans considération pour la maitenance.

Enfin j’ai été déçu de constater que malgré la réclame faite pour la robustesse du langage rendue possible par son système de type et son compilateur intelligent, je suis tombé en fait assez rapidemment sur des plantages à l’exécution à cause de pattern matching imcomplets.

Au final je suis déçu car j’ai passé du temps à apprendre Haskell et je ne vois pas venir le fruit de mes efforts. Pourtant j’étais intéressé par les notions de pureté fonctionnelle et d’évaluation paresseuse.

Est-ce que des personnes connaissant à la fois Haskell et OCaml peuvent indiquer si OCaml s’en sort mieux sur les points que j’ai évoqués ?

[Nuki]

Je n’ai pas beaucoup d’expérience avec Cabal, même si pour le peu de fois que j’ai du m’en servir (installation de Elm, de Ysedod), ça a planté :D
Donc je vais éviter de me prononcer à ce propos.

Concernant les autres points que tu évoques :

Un autre aspect que je n’aime pas beaucoup dans la culture Haskell est la tendance à utiliser des variables d’une seule lettre et des opérateurs à base de caractères spéciaux, y compris dans les bibliothèque tierces, plutôt que des noms de variable et de fonction explicites. Cela donne parfois au code Haskell un petit air de Perl codé sans considération pour la maitenance.

Je t’avoue que je n’ai pas décortiqué les bibliothèques Haskell, mais que généralement, le type me donne une information assez explicite sur ce qu’est une variable nommé d’une seule lettre. Même si pour ma propre convention, j’évite de n’utiliser des noms de variables qu’a une seule lettre, sauf exception (f, g pour les fonctions, x, y, ou encore i). Mais comme je l’ai dit un peu plus haut, le typage donne souvent assez d’informations.

Enfin j’ai été déçu de constater que malgré la réclame faite pour la robustesse du langage rendue possible par son système de type et son compilateur intelligent, je suis tombé en fait assez rapidemment sur des plantages à l’exécution à cause de pattern matching imcomplets.

En OCaml, un pattern non exhaustif renvoi un “warning”. Car il existe des cas où l’on sait que la correspondance des motifs n’a pas a être exhaustive (même si ça ne coute pas grand chose d’ajouter une clause générale avec un assert), et on peut aussi s’en tirer avec un GADT (mais bon). C’est donc pour cette raison que la compilation avec du pattern matching non exhaustive est permise. Cependant, le soucis que tu évoques, est dûe à l’évaluation d’une clause qui n’est pas prise en compte, je pense donc, sans te jeter une pierre, que c’est en partie de ta faute.

Concernant la comparaison avec OCaml, je ne sais pas trop les conventions de nommage des bibliothèques (mémoire de poisson de rouge), d’autant que l’on trouve plusieurs style, comme celui d’utiliser des arguments nommés (comme dans OCaml Core par exemple). Pour l’installation de paquet, je me servait exclusivement de OPAM, qui ne m’avait jamais fait défaut (sauf depuis peu, en tentant d’installer Ocsigen). Mais au moins, tu as des informations à la compilation, de correspondance de motif non exhaustive.

[dinosaure]

Personnellement, je déteste Haskell ! En réalité, je critique surtout son évaluation paresseuse qui laisse des comportements difficiles à déterminer surtout quand on vient d’un monde impératif ou objet (où l’évaluation se fait séquentiellement - ce qui n’est pas souvent le cas en Haskell). Autre point reste l’optimisation. Je ne jette pas la pierre aux développeurs de GHC particulièrement qui font un travail remarquable mais cette histoire d’évaluation paresseuse reste un frein considérable au niveau des performances ce qui implique souvent des optimisations sauvages sur le code ce qui rend l’équivalence avec un code impératif encore plus difficile à inférer.

Ce que je veux dire, c’est que l’intérêt qu’apporte l’évaluation paresseuse sur le développement reste selon moi assez limité surtout pour des développeurs normaux - il y a tout de même un intérêt parfois à l’évaluation paresseuse et c’est bien pour cette raison qu’OCaml intègre le mot-clé lazy.

Concernant la pureté d’un programme en programmation fonctionnelle, c’est tout aussi possible en OCaml. La programmation monadique n’est qu’une technique propre à la programmation fonctionnelle (que tu peux même simuler en C++ mais just for fun) qu’on peut retrouver avec la librairie Lwt. Cela reste une façon de programmer qui a des avantages et des inconvénients - dans le cas de Lwt par exemple, une programmation purement monadique demanderait à ce que le développeur ait en tête tout le chaînage des possibles processus ce qui peut être très difficile !

Enfin, comme il a été dit, il y a OPAM qui n’a pas du tout à rougir des autres packages managers qu’on retrouve chez Python ou JavaScript. Le seul point qu’on pourrait critiquer c’est le fait qu’on soit obliger de compiler toutes nos librairies si findlib fait une mise à jour par exemple. L’explication rationnel à cela reste le système de type, si l’interface de findlib change, tout les programmes dépendants de findlib doivent recompiler pour reprendre en compte l’interface pour le type safety. Mais les développeurs d’OcamlPro travaillent sur la question.

Enfin la communauté OCaml et très réactive et francophone en partie (puisque OCaml a été développé par l’INRIA) ce qui facilite pas mal l’entraide. On utilise souvent des vieux canaux tel que la mailing-list ou IRC mais débuter avec OCaml devient de plus en plus facile. Voici la porte d’entré :) !

PS: Pour Ocsigen, on attends encore la release d’Eliom en réalité et je pense qu’elle a pris du retard depuis la release d’OCaml 4.02. Un peu de patience donc ;) !