Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Programmer en pensant fonctionnel (F#)

[new:30/08/2014]Après s’être posé la question de savoir s’il fallait ou non utiliser F# j’aimerais vous présenter comment penser fonctionnel. Car il n’y a qu’en changeant radicalement sa façon de penser le code qu’on accède aux avantages du fonctionnel.

Penser fonctionnel

De l’impératif à l’objet

Je me souviens de l’époque glorieuse de Turbo Pascal dont la mise à jour 5.5 introduisit le support “des objets”. Quelle curiosité ! Nous qui étions habitués à la programmation impérative depuis l’assembleur du Z80 ou du 65C02 de l’Apple IIC… tout allait bien ! Nos programmes fonctionnaient ! C’était nous faire insulte que de nous parler d’une “nouvelle façon de penser” comme si la nôtre était mauvaise !

Ah les bougres de raseurs à lunettes ! Ah les fourbes “chercheurs” ! “Planqués” dans leurs universités que connaissaient-ils de nos vrais besoins, hein ? nous les durs, les vrais, les tatoués de la programmation en entreprise !

Quelles fadaises que ces discours sur un “changement de paradigme” mot dont personne ne connaissait le sens d’ailleurs (ce qui reste vrai de façon hilarante)… Que venaient-ils nous perturber avec leurs idées subversives que sont les “objets” ? Qui en avait besoin ? Personne ! Je vous le dis, PER-SON-NE ! Nous affichions alors une belle assurance riches et fiers de cette certitude.

Les langages totalement objets restèrent certes des curiosités de labo pendant longtemps. Moi qui était un Pascalien pur et dur le choc vint avec la fameuse mise à jour 5.5 de Turbo Pascal. Ce fameux 2 mai 1989 Borland avait décidé de faire une mise à jour intermédiaire, pas une nouvelle version. Uniquement pour ajouter le support des objets. Notre ami Anders Hejlsberg était déjà aux commandes d’ailleurs…

Apple avait déjà fait de même avec son Pascal Objet ‘le Clascal livré avec Lisa notamment) et C++ devrait attendre encore dix ans avant d’avoir sa première normalisation (1998, ISO/CEI 14882).

Combien de batailles a-t-il fallu mener pour convaincre un monde incrédule que le paradigme avait changé… Que les objets étaient non seulement utiles mais qu’ils devenaient nécessaires !

On ne compte pas les débats enflammés sur les forums de discussions, les flopées d’invectives frôlant ou dépassant le point Godwin dès lors que le sujet des objets y était abordé. Peu glorieusement j’avoue en toute honnêteté m’être fait piégé plus d’une fois à cette époque lointaine ou la fougue de ma jeunesse m’entrainait facilement sur la voie glissante qui mène au troll.

La franchise que je dois à mes lecteurs m’oblige à admettre ici qu’au tout début moi aussi j’ai eu une réaction de rejet vis à vis des langages objet (comme Smalltalk) et de ces monstres mi-langages mi-démons que furent ceux appelés “orientés objet”. Plus insidieux ils se sont infiltrés bien plus facilement car ils permettaient de conserver les bonnes vieilles habitudes tout en introduisant par le biais de librairies externes, d’exemples, d’articles, etc, des doses de plus en plus grandes d’objets. Ce fut le cas de Turbo Pascal 5.5 qui devint plus tard Delphi, puis sous la marque Microsoft par le même père en le bâtardant de Java et de C++, C#.

Après un rejet de principe j’ai bien du accepter que le progrès était immense. Je n’ai certainement pas été le premier à le comprendre, cela serait prétentieux et très vraisemblablement mensonger, mais j’ai pu m’apercevoir dans les années qui allaient suivre que j’étais bien loin de faire partie des derniers à accepter ce progrès. J’ai ainsi longtemps bataillé pour convaincre autour de moi par des livres, des articles, des conférences (notamment les fameuses BorCon au début des années 2000) ou de simples discussions. Les réticences étaient nombreuses, les raisons invoquées étaient parfois logiques et les discours bien huilés. Ils n’empêchent que ces gens se trompaient… L’impératif simple était déjà mort, il courait encore, certes, mais comme un canard décapité.

Puis vint un jour où tout langage qui n’était pas “orienté objet” ou même “purement objet” fut considéré comme une injure aux bonnes pratiques, une faute professionnelle grave disqualifiant le langage et ceux qui le pratiquaient. Ce temps là est arrivé avec le succès grandissant de C++, de Delphi, de Java, C#. Beaucoup de temps à été perdu mais qu’importe. L’essentiel est d’avoir réussi à faire comprendre que l’Orienté Objet était supérieur à la programmation impérative classique. Mais le vrai travail n’a débuté qu’ensuite. Se rendre compte que les objets étaient un progrès ouvrait devant nous l’obligation d’apprendre à penser notre code en objets. Et je le vois encore aujourd’hui près de 25 ans plus tard, cette vision “objet” du code n’est pas encore totalement maitrisée par tous les développeurs.

Car pour dépasser mon premier rejet J’ai bien sûr du accepter que cela obligeait à penser son code autrement. De le voir autrement. La différence tenait bien plus dans le conceptuel que dans la syntaxe ou la stylistique. C’est là que j’ai vraiment compris le sens de l’expression “changement de paradigme”, oui, il fallait changer sa représentation du monde pour programmer objet.

De l’objet au fonctionnel

Vous qui lisez Dot.Blog, surtout si vous en êtes un fidèle lecteur, vous êtes prêt à ce changement peut-être plus que n’importe qui. Votre curiosité, votre attachement à la qualité de votre code, tout cela vous prépare à ouvrir votre esprit à F#. Alors mon souhait serait qu’on ne perde pas autant de temps pour mener la même bataille, le même chemin de croix mais cette fois-ci menant de l’Orienté Objet au Fonctionnel.

Effectivement les choses se font plus calmement en apparence. Moins d’invectives et de noms d’oiseaux fleurissent sur les forums ou à la machine à café quand le sujet est abordé. Mais il l’est très rarement… Et ce n’est pas forcément rassurant !

D’une part parce que je crois que la fougue qui animait au moins une partie des informaticiens il y a 20 ou 30 ans n’existe plus. Elle a été remplacée par un conditionnement de midinette hurlant “awesome” à toute nouveauté juste pour la nouveauté (pensons juste à HTML5), à des retweete bidons du matin que tout le monde oublie l’après-midi, de “like” qu’on clique pour faire plaisir, de “+1” sans conséquence… D’exaltés et passionnés les informaticiens en devenant plus nombreux sont devenus plus transparents, plus “normaux” agissant comme n’importe qui. Être informaticien à une époque où aucune école n’existait était une vocation de pionnier, l’être aujourd’hui quand les ingénieurs sont diplômés par wagons années après années a forcément fait perdre en “intensité” et beaucoup gagner en banalisation.

D’autre part les batailles rangées sur l’opposition à l’objet démontraient clairement un intérêt majeur à ce changement qui pouvait effrayer mais qui ne laissaient pas de glace. J’ai bien l’impression que depuis plusieurs années que F# a été ajouté aux environnements de développement Microsoft ce n’est pas un excès de sagesse qui modère les discussions sur le sujet mais bien plus le désintérêt le plus total qui fait qu’il n’y a pas de discussion du tout, rendant improbable en toute logique des incendies spontanés dans ces non-échanges…

Il est aussi vrai que les querelles de langages les fesses calées dans un fauteuil qu’on croyait éternel ne peuvent forcément plus avoir le même gout quand on a les doigts crispés sur ce même fauteuil de peur de se le faire piquer par plus glouton que soi, à moins que ce ne soit la trouille de faire partie de la prochaine “charrette”…

Les débats se sont ainsi ramollis. Les passions ont été domptées sous le jouc de la pression sociale. Les masses ont été dressées à se rebeller uniquement sur des sujets futiles et à se déchirer uniquement sur le nom de la lessive qui lave plus blanc. La mode a remplacé le débat d’idée.

La lassitude a aussi envahi nos esprits. Notre métier génère tant de nouveautés “incontournables” pourtant oubliées après leur annonce que tel le petit berger qui crie au loup ceux qui annoncent de vraies nouveautés ne sont plus entendus…

F# ? J’ai bien dit changement de paradigme. Or on ne change pas de paradigme en un claquement de doigts. On doit s’y préparer. C’est ce à quoi sert mon introduction. La Communion au cours d’une messe se situe à la fin de celle-ci, juste avant la bénédiction finale et le célèbre “ite missa est” adoré des cruciverbistes. Toute accession à un état de conscience supérieur – réel ou supposé tel – oblige à un rituel qui aide à quitter le monde profane pour ouvrir son esprit à la révélation. Cet exercice peut être religieux ou parfaitement laïc ! Même si cette technique de préparation mentale a été largement utilisée par les religions, elle peut et doit l’être aussi dans d’autres domaines dont l’informatique. Changer de paradigme, même en programmation, réclame cette même volonté d’entrer en communion avec une Lumière, une étincelle, le fameux “moment Aha”, un savoir, et plus encore, une vision du monde renouvelée pour le découvrir sous un angle différent et mieux le comprendre.

Changer sa façon de penser le code

Préparez que vous êtes maintenant votre esprit doit se trouver dans un état lui permettant de comprendre, et non simplement admettre que la programmation fonctionnelle n’est pas uniquement affaire de syntaxe ou de style comme entre C++ et Java par exemple mais qu’il s’agit d’une façon totalement différente de penser le code. L’intensité de ce changement est de même ordre que celui du passage des langages impératifs comme l’assembleur à l’objet pur.

Tout comme il existe des langages “orientés objet” autorisant toujours de programmer impérativement, F# n’est pas un langage purement fonctionnel en ce qu’il autorise aussi de programmer “à l’ancienne”, en impératif et en objet. Celui qui utiliserait F# de cette façon unique pourrait très bien le dire et s’en vanter tout en passant à côté de l’essentiel de ce qu’est la programmation fonctionnelle ! Ecrire une classe statique exposant des méthodes statiques de service n’est pas faire de la programmation objet, c’est uniquement utiliser le formalisme objet pour faire de l’impératif. On peut de la même façon utiliser F# dans un mode “dégradé” où le code suit une logique impérative tout en étant exprimé selon le formalisme fonctionnel.

Ce n’est bien entendu pas ce que nous voulons faire. Quitte à apprendre F# ou simplement à apprendre de F#, c’est avant tout son essence fonctionnelle que nous voulons atteindre.

Il n’est pas question ici de dire que F# va remplacer C# dans l’année. Ni même plus tard d’ailleurs. Il est question de parler de programmation fonctionnelle et des progrès qu’elle implique. Comme cela resterait trop abstrait sans code à se mettre sous la dent, j’ai naturellement choisi F# pour vous en parler. Mais je vois ce langage comme un moyen d’accéder à la compréhension du fonctionnel, pas forcément comme une fin en soi même si certains sont tellement convaincus déjà qu’ils l’utilisent déjà comme seul et unique langage au quotidien.

Comme il est facile de remplacer les couples Begin/End de Pascal par les accolades { } de C# ! Comme il est difficile de penser un vrai code objet sans “if” où le jeu des héritages et le polymorphisme permettent d’obtenir la solution autrement que par une liste fermée de choix gérés par des aiguillages absolus…

Apprendre à penser fonctionnel dépasse de loin l’effort d’apprendre une nouvelle syntaxe. Cela ne peut se faire que dans une certaine durée et non en trois lignes.

Tout d’abord je vous enjoins à vous doter d’un outil interactif. Visual Studio propose une fenêtre F# interactive, dans un billet récent je vous ai aussi proposé un petit outil gratuit moins lourd à manipuler que VS qui permet de tester rapidement des bouts de code. Choisissez ce qui vous convient le mieux, mais ne restez pas passifs devant le texte. Il arrive un moment où la compréhension passe par le geste, l’essai, l’erreur.

Maintenant que vous êtes prêt psychologiquement au changement et prêt pratiquement à utiliser les bons outils, nous allons pouvoir avancer un peu plus dans la connaissance de F# et du fonctionnel !

Cela sera l’objet du prochain billet. J’en ai assez dit dans celui-ci !

Pour découvrir le fonctionnel, il vous reste une chose à faire …

… Stay Tuned !

blog comments powered by Disqus