Image par Mogmi.
Mon dernier article laissait penser que je reprenais goût pour la programmation fonctionnelle, ayant apprécié mes études à bases d’OCaml. Depuis, j’ai effectivement eu l’occasion de jouer avec Scala, avec Haskell. Je ne suis pas spécialement un pro-FP ou un anti-POO, ni même l’inverse. Ce qui m’intéresse, ce sont les enjeux derrière chaque paradigme. Que vais-je pouvoir tirer de telle ou telle techno ? Au fond, qu’est-ce que je veux vraiment faire ?
Why learning Haskell/Python makes you a worse programmer ?
L’auteur évoque ses difficultés de revenir à la réalité, à la réalité du Python, du C#, du Java ou du C++ (pour les plus chanceux). Je vais dans ce billet donner mon point de vue. De la philosophie de la programmation fonctionnelle, je retiens notamment la gestion des listes et structures récursives, le pattern matching, l’immutabilité, les monades, la lazy-evaluation. J’en oublie, mais ce sont là les éléments que j’estime utiliser régulièrement, au naturel.
Sans prétention, la manipulation de ces concepts fait que le programmeur acquière une certaine gymnastique qui n’est — à mon sens — que bénéfique. Gestion de la concurrence ? Modularité ? Travail en équipe avec d’autres adeptes de la FP ? Du bonheur. Je ne parle pas spécialement de performances, mais seulement d’architecture logicielle.
Seulement voilà, dans la vraie vie, difficile de débarquer, imposer une industrialisation de Haskell ou d’OCaml. Difficile de dire à des développeurs ayant l’habitude d’imbriquer trois niveaux de boucles for ou while de réfléchir par récursion. Difficile de remettre en question les modélisations objets de projets industrialisés recoupant plusieurs dizaines ou centaines de développeurs, sous prétexte que de nombreux bugs pourraient être évités en appliquant des mécanismes d’immutabilité.
C’est bien là le problème. Renouer avec les fonctions impures à outrance (se dit des fonctions à effet de bord), les API approximatives de Java ou PHP n’est pas synonyme de plaisir. L’argument de la « démotivation » lancé par Luke sur son blog est réel. On écrit du code bizarre, rien n’est séduisant.
En revanche, j’estime que ça me force à comprendre comment le langage fonctionne, et à ne jamais faire confiance à son fonctionnement. En 2 mois de temps, j’ai appris un nombre impressionnant de choses sur Java, notamment sur sa gestion de la concurrence (faut-il que je me sente honteux de tout juste découvrir que le langage propose des CountdownLatch ?) En tout état de cause, c’est mon arme contre la démotivation.
Un compromis intéressant me semble émaner de Scala. Son interopérabilité parfaite (?) avec Java lui donne l’avantage instantané de participer à toutes les logiques d’industrialisation. Scala, pour rappel, est un langage multi-paradigme, qui aime la POO autant que la FP ou l’AOP. Un méli-mélo, vous dîtes ? C’est sans doute vrai. Et je n’aime pas les mélanges incohérents, vraiment pas. Mais en pratique, force est de constater que, pour le moment, c’est un moyen assez élégant de faire en sorte que chacun puisse y trouver son compte. Il m’est arrivé, par exemple, de parcourir un graphe en Scala et d’appliquer un traitement en une ligne de code, via le paradigme map/reduce (mais pas distribué, cette fois-ci). Scala peut également obliger les développeurs à formaliser leurs types de retours en Option[Integer] si la fonction peut retourner l’équivalent de null ; tout en conservant la possibilité d’écrire des boucles itératives aux moments opportuns, ou de modéliser ses concepts sous formes de classes, sans rien changer — ou presque — des habitudes prises en Java.
Oh, et tant qu’on en parle, je vous invite à lire le billet de Marwan sur la FP. C’est aussi un élément déclencheur de cet article.
Abonnement Fil RSS