Haskell est un langage de programmation fonctionnelle. Un style de programmation où l’on utilise des fonctions plutôt que des objets, contrairement au paradigme de la programmation orientée objet.

Je ne vais pas refaire ici la liste des caractéristiques de la programmation fonctionnelle et de Haskell en particulier. Le souhaite juste indiquer rapidement quels sont les enjeux et quelles sont les ressources que l’on peut utiliser pour s’y initier.

Pourquoi Haskell ? Parmi les nombreux langages de programmation fonctionnelle de grande valeur (Scheme, OCaml,F#, Erlang, etc), Haskell a un statut particulier car c’est le plus “pur” (il y a aussi Clean, mais plus confidentiel), c’est à dire celui qui vous contraindra le plus à embrasser le paradigme de la programmation fonctionnelle.

Les vertus de la programmation fonctionnelle sont, notamment, de pouvoir appréhender dans de bonnes conditions les problématiques de parallélisation et de concurrence induites par la crise des multicoeurs et les architectures hautement distribuées, ce pour quoi les paradigmes impératifs et objets sont dans une impasse.

L’évaluation paresseuse (lazy evaluation) permet d’optimiser les performances du code car les calculs ne sont faits par le programme que s’ils sont vraiment nécessaires.

Ensuite, le système de typage des données est statique, c’est à dire qu’il faut bien préciser la nature des données manipulées par les fonction quand on les défini. Cela peut paraître plus contraignant que le typage dynamique, mais cela garanti la sureté des programmes.

On peut dire aujourd’hui que tous les langages objets et impératifs tendent, dans leur évolution, à intégrer ce qui fait la force de la programmation fonctionnelle, alors pourquoi ne pas partir directement du modèle de référence plutôt que d’avoir des langages hybrides (scala, clojure, etc.) ?

Pour résumer la situation en matière d’évolution des langages, Simon Peyton-Jones présente le petit schéma que je reproduis ci-après, et dans lequel il montre bien que le Nirvana du programmeur serait d’avoir un langage utile et sain. Pour l’atteindre, soit l’on part du situation dangereuse mais utile (Java, C++, Python, C#, etc.) pour introduire progressivement des approches fonctionnelles dans ces langages, soit l’on part d’une situation saine (Haskell) mais peu utile (“peu utile” car dans l’idéal, un programme fonctionnel n’a aucun effet de bord, c’est à dire qu’il ne modifie pas le monde, il ne sert donc à rien) mais qui va implémenter des possibilités de modification de son environnement.

(on peut trouver sur le web plusieurs enregistrements vidéos de conférences données par Simon Peyton-Jones, toutes relèvent du gai savoir çà vaut le détour.)

On voit que la philosophie Haskell est très cartésienne : on fait une tabula rasa pour partir d’une situation saine à partir de laquelle on va accepter d’implémenter des effets de bords maîtrisés (les fameuses monades) et non arbitraires.

Là où le programmeur Java va passer son temps à gérer les effets de bords dus à son style de programmation (il ne cesse de dire au programme ce qu’il doit faire de manière procédurale puis doit ensuite faire des batteries de tests unitaires pour revérifier son travail) le développeur Haskell va laisser le programme faire son boulot. Par nature, le programmeur Haskell à confiance dans son code alors que le développeur Java est dans une relation de méfiance.

*

En matière de ressources bibliographiques, on commencera par indiquer le livre Introduction to functionnal programming using Haskell de Richard Bird. C’est un livre théorique, donc si vous êtes un développeur sans appétence pour les aspects les plus abstraits et conceptuels, il faut passer votre chemin. Toutefois, il y a fort à parier que c’est un livre que l’on sera amené à consulter régulièrement quand on se retrouvera face à des questions de fond quant à la meilleur manière de faire,  et également pour améliorer son “esprit Haskell”.

Ensuite, une mention spéciale pour l’ouvrage de Graham Hutton, Programming in Haskell, qui est un livre magique. Tout y est : qualité du papier, typographie, excellence pédagogique, le tout en moins de 200 pages. De quoi donner des leçons à tous ces livres informatiques qui ressemblent à des catalogues de la redoute de plus de 500 pages pour ne rien dire d’intelligent. Pour moi, c’est le meilleur ouvrage de programmation qu’il m’ait été donné de lire, à recommander même à ceux qui ne veulent pas apprendre Haskell, c’est dire.

C’est sur la base de ce livre qu’Erik Meijer (une des têtes pensantes de Microsoft, passionné par les langages fonctionnels) propose, sur le Channel 9 de Microsoft, 13 cours vidéos pour s’initier au langage, un vrai régal :

  1. Introduction
  2. First steps
  3. Types and classes
  4. Defining functions
  5. List comprehensions
  6. Recursive functions
  7. Higher-order functions
  8. Functional parsers
  9. Interactive programs
  10. Declaring types and classes
  11. The countdown problem
  12. Lazy evaluation
  13. Reasoning about programs

Je signale également le livre Haskell school of Expression, de Paul Hudak, pour ceux qui veulent utiliser la programmation fonctionnelle dans un contexte multimédia et artistique :

 

Paul Hudak que l’on peut voir dans cette vidéo, donnant une conférence sur “Haskell and the arts : How functionnal programmers can help, inspire or even be artists”, enregistrée à Qcon San Fransisco en novembre 2008.

Enfin, la consécration, un ouvrage de référence chez O’reilly, le fameux Real World Haskell, que je déconseille toutefois avant d’avoir lu “Programming in Haskell” de Graham Hutton. On a ici un ouvrage mainstream, comme tant d’autres, mais fort utile pour faire du Haskell “dans la vraie vie”.

Sur les autres ressources, on ira sur Haksell.org, le portail qui rassemble toutes les infos utiles. À noter que depuis quelques mois un effort a été fait sur les packages d’installation avec The Haskell Platorm.

Pour les librairies on utilisera le génial Hoogle.

Côté des frameworks web, il y a Happstack, le plus ancien, mais aussi Snap qui, bien qu’en phase beta, semble jouir d’une bonne dynamique et donne des premières perspectives de performances intéressantes (ici les performances d’accès à des fichiers, plus est mieux):

Enfin, et pour terminer,  la petite blague sur Haskell qui a circulé sur Twitter, relativement à “l’évaluation paresseuse” (Lazy evaluation) dans Haskell, où les calculs ne sont effectués par le programme que s’ils sont nécessaires:

Put #Haskell on your resume even if you don’t know it. When asked, say your resume is lazy and you’ll learn it when results are needed.

Bonne initiation !