Informatique‎ > ‎

Haskell, pour quoi faire ?

Profitant du récent engouement pour la programmation fonctionnelle, Haskell commence à faire parler de lui en dehors du seul cercle de ses initiés. A l'heure où les langages dynamiques et tout objet dominent la scène, qu'est-ce qu'un langage au typage fort et statique et sans notion d'objet peut bien avoir à apporter ?

Des origines académiques

Les années 70 et 80 ont vu fleurir un grand nombre de langages fonctionnels, tels que Scheme, ML, Miranda, SASL, KRC, Clean, Lazy ML et Lisp. Parmi ceux-ci, seuls les deux premiers ont su, au milieu des années 80, réunir autour d'eux une communauté suffisante pour susciter des développements substantiels. C'est cette dispersion des efforts qui a motivé Simon Peyton Jones et Paul Hudak pour organiser un groupe de travail au cours d'une conférence sur les langages fonctionnels, en Septembre 19871. L'objectif est alors simple : il s'agit de mettre au point, via un comité de décision, un langage commun qui reprenne les caractéristiques communes à tous ces langages, à savoir une évaluation non-stricte et un design fonctionnel. Rapidement, il est décidé de nommer le langage en hommage au mathématicien Haskell Curry. Haskell évolue alors presque exclusivement dans le monde académique, de même que Simon Peyton Jones, lequel enseigne à l'University College de Londres puis à l'Université de Glasgow jusqu'à son embauche par Microsoft en 1998. Libéré de ses obligations d'enseignant, il peut consacrer le plus clair de son temps au développement de Haskell, au sein du département de Recherche et Développement de l'éditeur.2

Pour quoi faire ?

Aujourd'hui, Haskell ne s'est pas écarté de la feuille de route déterminée en 1987 et assume pleinement son rôle de langage fonctionnel modèle, c'est-à-dire celui d'un langage qui ne transige pas avec l'impératif. Les fonctions se définissent ainsi au sens mathématique du terme : pourvu qu'on fournisse à une fonction les mêmes arguments, elle produit le même résultat, indépendemment de toute autre chose. Haskell n'a pas non plus d'opérateur d'assignation comme on en trouve communément dans le monde impératif, où l'on peut légitimement écrire la chose suivante :

a = 5
a = 6

Où a n'agit que comme un label permettant au programmeur d'identifier le contenant d'une variable. Haskell voit plutôt a comme un symbole. Si on écrit a = 5, alors cela signifie que a représente l'expression 5. Tout ceci implique qu'une fonction en Haskell se montre imperméable aux changements extérieurs et n'occasionne pas non plus d'effet de bord, c'est-à-dire que l'on peut être certain de n'obtenir rien d'autre que le résultat. Il est important de noter que cette garantie est visible dès la signature de la fonction : seules celles marquées comme impures sont susceptibles d'interagir avec le monde extérieure (accès à des resources diverses, comme le réseau ou un disque). Toutes les autres offrent la certitude d'un comportement identique d'une exécution à l'autre. Les ramifications de ces garanties font d'Haskell un langage particulièrement facile à tester et véritablement sûr. l'une des plus vicieuses problématiques de la programmation multi-threads ne se posant tout simplement plus, par exemple.

Il est important de comprendre que puisqu'il ne s'agit pas d'assignation, Haskell peut se permettre de n'évaluer les expressions qu'au moment de leur utilisation effective. Cette paresse ("lazyness") est un élément-clef du langage.

Ensuite, comme la plupart des langages fonctionnels, Haskell est un langage minuscule. Il comporte bien peu d'éléments qui ne soient pas simplement définis comme des fonctions quelconques, ce qui signifie également qu'il est particulièrement aisé d'étendre le langage. Le programmeur a accès, en permanence, à tous les outils pour modeler le langage comme il l'entend, indiquant la manière dont telle fonction peut être utilisée en notation préfixée ou infixée, ou en en précisant l'ordre de précédence, par exemple.

Les quelques exemples ci-dessus permettent de comprendre l'un des principaux intérêts d'Haskell pour le programmeur professionnel : tous les outils sont fournis pour penser autrement. Les problématiques habituelles sont mises hors-circuit et la réflexion vient naturellement se poser en termes de structures de données et d'algorithmes3.

Avoir tous ces outils à sa disposition et donc jouir d'un accès direct aux concepts qu'ils permettent de manipuler présente un grand intérêt intellectuel : partir à la découverte d'Haskell, c'est explorer un aspect de la programmation que le quotidien du programmeur met généralement hors de sa portée.

Le système de type d'Haskell participe également à rendre ce langage intéressant : il réussit le prodige d'offrir à la fois la sécurité d'un typage fort et statique tout en encourageant la programmation la plus générique qui soit. C'est bien entendu une aubaine pour les outils de test et l'utilitaire QuickCheck4 en profite largement : les fonctions étant pures, les types étant sûrs, il est possible de générer les cas de test automatiquement et sans omettre les cas particuliers qu'un programmeur a tôt fait d'oublier inconsciemment.

De tout ceci résulte une élégance à la fois conceptuelle et visuelle, car à travers la syntaxe du langage, c'est bien le raffinement de sa conception qui transparaît.

Des problèmes d'écosystème

Malheureusement, tout n'est pas rose dans le monde d'Haskell. Le principal problème reste peut-être celui de son écosystème. Comme beaucoup de plateformes de développement, il dispose d'une collection de packages open source, Hackage, laquelle est gérée par un outil dédié, Cabal, assurant les classiques opérations d'installation et de mise à jour. Si le fonctionnement de ces outils se montre satisfaisant dans les situations relativement simples, ils deviennent vite insuffisants dès lors que l'on se lance dans des développements sérieux, nécessitant plusieurs versions concurrentes des mêmes librairies. La relève viendra peut-être de cabal-dev mais le tout manque encore de maturité.

Il en va de même pour les librairies elles-mêmes à disposition sur Hackage. Si certaines présentent une qualité professionnelle, trop nombreuses sont celles relevant de ces petits projets expérimentaux que les programmeurs se donnent comme des exercices. Elles présentent des problèmes de dépendances, de péremption ou encore de performance qui font de leur adoption une gageure.

En outre, la visibilité récente d'Haskell a conduit à une situation assez particulière, où deux communautés cohabitent autour du même ensemble de technologies. La communauté académique, historique d'Haskell reste très présente et active et elle s'est vue rejoindre par un nombre toujours croissant de développeurs venus du monde de l'entreprise. Les préoccupations des uns ne correspondent pas nécessairement à celles des autres, de même que le vocabulaire mathématique, prisé par les utilisateurs académiques et qui rend parfois la communication difficile avec ceux qui apparaissent alors comme des béotiens. Enfin, il faut noter que ces deux communautés n'utilisent pas nécessairement Haskell pour la même chose : comme l'a fait remarquer Darrin Thompson5, par ailleurs co-créateur du logo du langage, tous les programmes écrits en Haskell ne sont pas des programmes. Certaines sont plutôt des preuves formelles rédigées en Haskell, ce qui est une activité totalement différente de celle consistant à écrire un programme interactif. Il est tout à fait passionnant de découvrir qu'un même outil peut se montrer pertinent pour deux activités aussi différentes, mais cela crée une regrettable confusion privant les nouveaux venus de repères clairs.

Haskell veut-il devenir populaire ?

Des efforts sont menés pour venir à bout de ces problèmes, tels que cabal-dev, mentionné plus haut. La question de fond reste cependant de savoir si Haskell cherche réellement à devenir populaire. Lors d'une interview donnée à l'édition australienne de Computer World, Simon Peyton Jones a livré sa vision des choses sur ce sujet, sans ambiguité :

I think a good point is that Haskell is a laboratory: it’s a lab to explore ideas in.6

[...] I don’t know if you know this, but Haskell has a sort of unofficial slogan: avoid success at all costs. I think I mentioned this at a talk I gave about Haskell a few years back and it’s become sort of a little saying. When you become too well known, or too widely used and too successful (and certainly being adopted by Microsoft means such a thing), suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things.

[...]Now, however, they’re starting to complain if their libraries don’t work, which means that we’re beginning to get caught in the trap of being too successful.7

Si le retour en grâce de la programmation fonctionnelle est indéniable, cela ne signifie pas nécessairement que les prochains langages les plus pratiqués auront pour nom Clojure, Scala, Common Lisp et Haskell. En observant attentivement ce qui se passe, on remarque plutôt un mouvement transférant les différentes trouvailles de ces langages dans d'autres langages, plus établis dans l'industrie et disposant d'un écosystème mûr et sain. Ainsi, à en croire l'un de ses designers principal, Eric Lippert, le sous-système LINQ pour C# a beaucoup emprunté à des concepts venus d'Haskell8. De même pour F#9, le langage fonctionnel mis en avant par Microsoft pour sa plateforme .NET. Bref, plutôt qu'un changement radical, il est probable que l'on doive plutôt s'attendre à une transition en douceur, où les langages impératifs se dotent petit à petit de notions fonctionnels et évolue vers un statut de langages multi-paradigmes.

Dans ce contexte émerge une nouvelle motivation pour apprendre Haskell : celle de découvrir, en avant-première, les directions que l'industrie va suivre dans le futur.

kafka - Août 2012

Réagir par mail


  1. La conférence en question est la Functional Programming and Computer Architecture, qui s'est déroulée à l'automne 1987 à Portland. L'article "Haskell : Being lazy with Class" consacre sa première partie à l'histoire du langage. 

  2. A ce sujet, peut avant l'embauche de Simon Peyton Jones par Microsoft, et sans rien en savoir, Paul Johnson a publié un canular sous la forme d'un communiqué de presse indiquant que Microsoft et l'université de Yale signait un accord visant à faire d'Haskell l'arme de l'éditeur contre le rival Sun et son tout récent Java. Le communiqué est à lire sur le wiki dédié à Haskell

  3. Ceci rejoint la vision de Niklaus Wirth telle que présentée dans son ouvrage "Algorithms + Data Structures = Programs". Niklaus Wirth est entre autres l'inventeur de Pascal. 

  4. On trouve sur le wiki d'Haskell une introduction à QuickCheck

  5. Darrin Thompson décrit en détail son expérience dans un billet sur son blog

  6. Citation tirée de l'interview que l'on peut lire sur le site du journal

  7. Citation extraite de la même interview

  8. Voir sa réponse à une question posée sur Stack Overflow

  9. "I think you will hear [Don Syme] say that he’s got a lot of inspiration from Haskell. Some ideas have come from Haskell into F#, and ideas can migrate much more easily than concrete syntax and implementation and nitty gritty design choices.". Citation tirée de la même interview