.
Une guise de petite entrée en matière, laissez moi vous faire compiler une ligne :
factorielle n = product[1..n]
Un tel snippet semblera peut-être quelque peu ambitieux pour ceux qui ne jurent que par la programmation impérative. PHP, Java, C++ et consort. C’est pourtant une ligne parfaitement valide en Haskell. Bienvenue dans l’univers de la programmation fonctionnelle. On ne gère plus des changements d’états, mais des évaluations de fonctions.
Des bouquins
C’est un univers que j’avais découvert avec OCaml durant mes classes prépa, et voilà que je replonge dedans. La « faute » à un excellent bouquin, « Hasard et complexité en mathématiques », écrit par Grégory-J Chaitin, le découvreur du nombre oméga « Ω » – mon nombre préféré, mais ce n’est pas le sujet ici.
Dans son ouvrage, Grégory Chaitin avoue son amour sans nom à Lisp, un des plus anciens langages apportant le paradigme de programmation fonctionnelle. Un amour qu’il a ma foi su fort bien communiquer puisqu’il ma donné envie de remettre en questions mes développements actuels.
J’étais assez rebuté par la lisibilité du code en Lisp et après pas mal de lectures auxiliaires, je découvre à quel point Haskell est séduisant autant dans ses concepts que dans sa syntaxe. Gérer des ensembles infinis, ou des nombres à précision potentiellement infinie n’est sans doute pas une situation que tous les développeurs rencontrent tous les jours, mais c’est toujours source de nombreux problèmes dès que le cas fait surface. Ceux qui aiment les problématiques de typage seront ravis d’apprendre que Haskell est, parait-il, muni d’un système de typage à toute épreuve. J’aurai sans doute l’occasion de vous en dire un peu plus une fois mon apprentissage approfondi. Toujours est-il que j’ai commandé au monsieur tout-en-rouge le livre de la collection d’O'Reilly :
Un autre langage, qui fait sans doute plus parler de lui : Scala. Comme OCaml, il est multi-paradigme. Utilisé notamment chez Twitter, LinkedIn, Foursquare ou d’autres grands noms de la toile, on peut sûrement expliquer cette nouvelle popularité par son interopérabilité avec Java. Le langage fonctionne en effet tout aussi bien sous forme de scripts que de bytecode compilé à destination de la JVM, et il est en ce sens possible – et aisé – d’exécuter du code Java depuis Scala. Sans avoir encore trop farfouillé, j’ai tout de même l’impression que l’approche est assez différente de ce qu’on retrouve en Haskell ; j’ai ainsi constaté que beaucoup de codes ne pouvait s’offrir le luxe de faire l’impasse sur le cas des valeurs null. Peut-être du travail à faire du côté des monades ? J’en saurai sûrement davantage après une vraie découverte du langage et une lecture approfondie de cette autre idée cadeau :
Pourquoi quitter le monde impératif ?
Pourquoi un attrait si soudain pour la programmation fonctionnelle ? Pourquoi devriez-vous essayer, à votre tour, de voir autrement vos suites de 0 et de 1 ? En ce qui me concerne, le livre de Grégory Chaitin fut le véritable élément déclencheur, mais c’est aussi le désir de remettre plein de choses en question, de continuer à se maintenir éveillé sur ce qui se fait de nouveau (Scala), et peut-être de reprendre davantage de plaisir à développer en utilisant de nouvelles approches lorsque cela est nécessaire.
Je suis par exemple régulièrement amené à développer de nouveaux outils statistiques (des simples moyennes arithmétiques ou harmoniques aux matrices de covariance) et il n’est pas rare d’observer que le langage fait parfois partie integrante du problème que de la solution, pour reprendre l’expression de certains auteurs : dépassement de capacité des types integer et assimilés ; jonglage fréquent entre types signés, non signés, flottants ; impossibilité de redéfinir l’opérateur « + » dans certains langages, etc.
Je ne sais pas vraiment ce que j’attends de la programmation fonctionnelle dans mon usage quotidien, ou si Haskell sera strictement supérieur à Scala dans mon cas ou s’il sera juste un complément pertinent. Des concepts tels que les flèches me laissent penser que mes systèmes hautement concurrents pourraient s’en retrouver un peu plus concis et formels qu’avec les actuels langages impératifs. Alors, je vous donne rendez-vous pour de prochains billets pour de nouvelles critiques !
Abonnement Fil RSS