Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

F# et le "paradoxe de la secte"

F#, fils (ou frère ?) de OCaml, langage intégré à la prochaine version de Visual Studio, fait son buzz ...

Comme toute nouveauté, ne pas connaître c'est risquer de passer pour un idiot à la machine à café (voire à la cantine ou au chinois du coin le midi, l'effet est le même, juste qu'il est plus facile de quitter la machine à café en prétextant un truc urgent à faire que de se lever de table sans avoir fini son rouleau printemps).

De fait ne pas s'informer est en réalité un double crime : d'abord professionnel (rester au courant est un minimum syndical quand on est payé pour faire un job), ensuite social (passer pour un hasbeen est lourd à porter).

Heureusement je veille au grain et grâce à DotBlog vous ne commettrez pas ce double impair !

F# est un langage issu des labos de Microsoft. S'il est très proche de OCaml (au départ totalement compatible) il s'en éloigne par plusieurs points, ne serait-ce qu'en raison de sa parfaite intégration à l'édifice .NET.

Tout le problème avec un nouveau langage c'est qu'il place l'informaticien dans une situation embarassante. Car on attend d'un informaticien qu'il parle d'informatique et qu'il connaisse les outils propres à son métier. Jusqu'à là rien d'anormal. Mais concernant un langage on se retrouve vite devant ce que j'appelle le "paradoxe de la secte" : Soit vous n'y appartenez pas et toutes vos critiques et réserves seront balayées par ses partisans au principe que n'y appartenant pas vous n'en connaissez rien et que votre avis est totalement subjectif, soit vous y appartenez et le bien que vous en direz, tout comme le mal éventuellement, sera considéré comme sujet à caution par tous ceux qui n'appartiennent pas à la dite secte ...

Mais cela pose tout de même un sacré problème : peut-on dire du bien ou du mal d'un nouveau langage de programmation sans avoir écrit un vrai logiciel avec, ou doit-on forcément être capable de réécrire Excel en un week end avec un langage pour pouvoir prétendre donner son avis sur ce dernier ?

J'aime les paradoxes pour le jeu. Mais je n'aime pas l'inconfort intellectuel du "paradoxe de la secte" surtout appliqué à mon métier qui est en quelque sorte une apologie à la Logique et où le monde se règle à coups de If Then Else. Des If avec un Then mais sans Else c'est de la programmation risquée. Et d'ailleurs pour revenir au sujet, F# oblige l'utilisation de Else. Pour cette même raison (c'est risqué). Logique, mais peut-être casse pied à l'usage, il faut voir...

Souhaitant échapper au paradoxe de la secte, je ne vous donnerai pas un avis technique profond sur F#, mais je vous invite à lire une série de billets introduisant la syntaxe de F# pour vous faire vous-même une idée de la chose et je vous propose de venir laisser vos impressions en commentaires afin qu'on puisse en discuter. "Présentation de F#" par Laurent Le Brun

L'article est fait de petits billets, donc c'est facile à lire. En retour c'est un peu sommaire et pas forcément très expliqué, mais on ne peut pas tout avoir. En tout cas ça vous en dira suffisamment pour vous faire une idée, et surtout pour tester la syntaxe si vous téléchargez le langage (ce qui n'est pas nécessaire avec la bêta de VS2010, téléchargeable ici : http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx).

Je vous demandais plus haut de venir ajouter en commentaire votre avis sur F#, autant commencer par donner le mien penserez-vous. C'est oublier le "paradoxe de la secte" dans lequel cela me plongerait malheureux ! Mais comme c'est pour vous, j'ai testé un peu F#, échappant de justesse au paradoxe : ni je n'en connais rien, ni je n'en connais tout, en toute logique le paradoxe ne s'applique plus à mon cas :-) (c'est discutable, je sais, mais tout ce qui est discutable laisse chacun dans la possibilité de croire qu'il a raison !).

Bref, F# c'est jeune, c'est sympa, c'est de la "programmation fonctionnelle" (super classe et dans le vent), donc c'est bien. Peut-être. Ou peut-être pas. A petites doses, sous le couvert de LINQ, au d'extensions de C#, je ne dis pas. Exclusivement et en plat unique et principal, est-ce digeste ? J'ai un doute.

Si La syntaxe F# est "amusante" elle me semble peu lisible, peut-être par manque d'habitude. Toutefois quand on passe de C ou Java à C# on n'a pas cette impression, ni même de Delphi à Java ou réciproquement. Alors première "mauvaise impression" ou bien réalité ? Le problème c'est qu'il faudrait devenir bon en F# pour le comparer et savoir si on l'aime ou pas.. L'horrible et incontournable paradoxe de la secte qui revient ! Donc je suis obligé de rester au niveau subjectif et mon avis n'a rien de technique. De prime abord, je n'aime pas trop la syntaxe donc.

Par exemple il existe un mode "light" (devenant visiblement la "norme"). Dans ce mode la syntaxe devient plus "light" mais au prix que je trouve insensé de donner une valeur réelle à l'espace (le caractère espace, pas starwars hein..). C'est à dire que les blocs ne se déclarent plus avec des mots clés de début et de fin (ou les {} de C#), mais sont uniquement basés sur l'indentation du texte à l'espace près, les tabulations étant interdites.
Utiliser les espaces pour indenter c'est bien, ne pas pouvoir utiliser les tabulations c'est un peu embêtant, mais lorsque qu'on sait que ces espaces ont aussi un impact sur le code ça me dérange un peu. Que le nombre d'espaces devant une instruction puisse modifier son sens ou sa portée m'apparait un dangereux défaut. Mais ce n'est peut-être que par manque de pratique.

Quant à l'esprit du langage, dans la foulée des langages ML comme LISP, ce dernier m'a toujours paru trop abscons pour devenir populaire et jusqu'à lors, en 25 ans de métier aucun de ces langages n'a démenti cette impression et n'est devenu un blockbuster. F# sera-t-il celui qui me fera mentir ? Saura-t-il séduire les foules de développeurs en soif de nouveautés ? Ou bien restera-t-il juste un bel essai boudé par les mêmes informaticiens déjà gavés "jusqu'à là" de trucs nouveaux à apprendre sous .NET (et super géniaux comme Entity Framework, Silverlight, ASP.NET MVC, etc) ?

Wait and see dirais-je sagement pour ne pas trop me mouiller :-)

F# est plein de bonnes idées, mais sa syntaxe et son esprit me semblent difficilement compatible avec l'industrialisation du développement. Caml, OCaml, LISP et consors ne sont jamais sortis de leur cercle d'initiés. L'industrie du logiciel n'en a pas voulu. F# possède-t-il le petit "plus" qui lui permettra d'étendre son influence plus largement que ces prédécesseurs ? Nous verrons bien !

Alors j'attends vos avis et impressions !

Faites des heureux, PARTAGEZ l'article !

Commentaires (4) -

  • Yann Schwartz

    26/05/2009 15:43:56 | Répondre

    Bonjour,

    Il est vrai qu'il faut faire le tri dans l'avalanche de nouveautés plus ou moins (in)dispensables provenant de MS.

    Il est également vrai qu'une hype chasse l'autre, qu'en ce moment c'est la mode du fonctionnel, des DSL, d'Erlang, et que dans six mois la chambre d'écho des blogs techniques se sera jeté sur une autre mode.

    Néanmoins...

    Je ne partage pas votre avis concernant l'intérêt du fonctionnel. L'introduction de Linq dans C# 3.0 montre à quel point le déclaratif est plus lisible et plus puissant que l'impératif, et c'est là la marque des langages fonctionnels. On arrive dans certains cas à faire que le code EST la spécification du besoin.

    Vous remarquez que le saut de C# à Java ou Delphi n'est pas aussi important que celui vers un langage fonctionnel. En effet, C#, Java et Delphi sont à peu de chose près les mêmes langages : impératif et objet. Mêmes concepts mais légères différences de syntaxe. Passer au fonctionnel (ou jongler entre les deux, comme on le fait quand on utilise Linq en .Net) demande de reconsidérer la façon dont on traduit un besoin en code.

    Sur la lisibilité du code, tout est affaire de goût et il est vrai que la syntaxe d'Ocaml est pleine de bruit, mais F# et sa syntaxe light arrangent grandement les choses. Votre remarque sur les espaces significatifs est amusante, sachant que c'est le reproche le plus courant adressé à Python et que je ne connais guère de langages plus lisibles que Python. Je ne vois pas en quoi une suite d'une dizaine d'accolades fermantes serait plus agréable à l'oeil, sinon pour des raisons d'habitude.

    Maintenant, il est vrai que F# ne brille pas forcément dans tous les domaines. L'écriture d'interfaces utilisateur (WinForms ou ASP.Net) en F# objet n'apporte pas grand chose par rapport à un langage objet bien classique (VB.Net, C#, etc.). Là où F# a tout son intérêt est dans les formulations d'algorithme à la LINQ, le traitement de langages, les traitements asynchrones et les parties où l'algorithmique est importante.

  • Olivier

    26/05/2009 17:28:31 | Répondre

    @Yann:
    Merci de votre retour. On voit que sur le rôle des espaces les points de vue divergent Smile En réalité ce que je pense n'est pas que des parenthèses de tout type soient plus lisibles que des espaces. Après tout se débarasser des marqueurs de bloc rend le code plus "light" justement et plus lisible, au moins dans l'esprit. En revanche, quand je place une ouverture de bloc en C# ou un Begin en Delphi, toute erreur de mise en page (suppression d'un espace, ajout d'une tab..) si elle rendra mon compte moins lisible ne changera pas un iota dans sa traduction machine.
    Ce que je reproche à F# c'est bien cela : que la mise en page puisse changer le sens de la chose programmée. Tout n'est plus dans les mots clé, une partie de l'algorithme se cache dans quelque chose qui n'a rien de logique : la mise en page.
    Mais encore une fois ce reproche n'est peut-être, comme je le soulignais, qu'une première mauvaise impression qui s'estomperait avec la pratique. Mais j'ai un doute.

    Quant au fonctionnel, sans me répéter, je n'ai rien à lui reprocher, sauf qu'aucun langage de cette mouvance n'a su s'imposer ce qui me fait penser que je ne suis pas le seul à les trouver inutilisables en production. En labo, en fac, oui, dans le cadre d'une entreprise non.
    Mais jamais je ne remet en question l'intérêt de l'approche fonctionnelle. Comme je le souligne dans le billet, quand on introduit un peu de fonctionnel cela peut largement aider à faire évoluer les langages actuels.
    Je suis un fan de LINQ, j'en ai parlé très souvent ici et j'en reparlerai c'est certain. Toutefois quand on me présente LINQ comme une "extension fonctionnelle" utilisant un "paradigme nouveau", en tant que vieux de la vieille cela me fait doucement rire, je vous l'avoue. LINQ, dans sa version avec sucre syntaxique (la plus utilisée), c'est une intégration (intelligente) de SQL à C#. Faisait-on tant de "foin" sur l'approche fonctionnelle quand depuis plus de 20 ans nous programmons des SGBD en SQL ? Il y a dans tout cela beaucoup du jargonage propre à notre beau métier où souvent on habille de grandes théories pleines de mots nouveaux des choses que nous savions faire depuis très longtemps.

    Donc oui au fonctionnel pour renforcer C# par exemple, bien entendu (et même si certains aspects de ce 'fonctionnel' ne sont qu'un relookage de vieilles techniques comme SQL). C'est le tout fonctionnel qui me pose question.
    Et comme vous le soulignez vous-même, F# pour faire de l'interface c'est peut-être pas ça... Du coup qu'est ce qui peut bien motiver des informaticiens à utiliser un langage qui les oblige à en conserver un autre pour faire "le reste" ? Alors même que des langages .NET comme C# ou VB permettent de tout faire. C'est sur ce mur là que F# va se cogner.

    Reste néanmoins un beau langage proposant une approche différente, c'est bien, et ouvrant vers un nouveau style de programmation.
    Quand l'objet est apparu il y déjà très longtemps aucun informaticien n'en comprenait l'intérêt et les avantages. Face à cette situation les langages procéduraux se sont vu ajouter de "l'orienté objet" et la mayonnaise à mieux pris... Jusqu'à ce qu'une vingtaine d'années passent pour 'oser' vendre, enfin, des langages tout objet.
    Il est fort probable que nous vivions en ce moment la même histoire avec le fonctionnelle. Je me garderai donc bien de prévoir son succès immédiat autant que son abandon !

  • Laurent Le Brun

    06/06/2009 01:23:20 | Répondre

    Ah, Olivier Dahan ; ah, Merlin ! Je me souviens de ces noms, de l'époque où j'utilisais uniquement Delphi - il y a des années - et j'appréciais tes contributions. Depuis, de l'eau a coulé sous les ponts, j'ai abandonné Delphi au profit d'OCaml et j'admire beaucoup F# (depuis 2007). Je suis ravi de lire ce genre de billet et de discussion sur un site français. C'est encore assez rare, mais ça le sera de moins en moins.

    Quelques remarques en passant : le "else" n'est pas tout à fait obligatoire. On peut se passer du "else" si le then n'est renvoie rien (c'est-à-dire "unit", qui correspond au "void"). C'est une question de typage et c'est finalement logique (pensez à l'opérateur ternaire ?: de beaucoup de langages).

    En pratique, on se rend compte que la plupart des gens apprécient l'utilisation de l'indentation. Les développeurs Python et Haskell en sont souvent ravis, les développeurs F# l'utilisent presque tous, alors que ce n'était même pas par défaut il y a encore 10 jours. Contrairement à Python, il est toujours possible de marquer explicitement les blocs avec des parenthèses ou une paire de begin/end. Cela peut rassurer les sceptiques. Qui plus est, le typage fort et les avertissements du compilateur si l'indentation est étrange offrent des filets de protection (que n'a pas Python).

    C'est vrai que les autres langages n'ont connu qu'un succès très relatif. F# a tout de même certains avantages qui le rendent plus crédible dans l'industrie : le large choix de bibliothèques, l'interopérabilité avec le reste du monde et l'environnement de développement (offert avec Visual Studio), tout cela provenant de .NET. Bien sûr, F# ne révalisera probablement jamais avec C#, C++ et Java, mais c'est une passerelle avec le milieu plus académique des langages fonctionnels classiques.

    F# apporte beaucoup de fonctionnalités intéressantes, mais surtout : il aide à faire évoluer C# et .NET (oui, regardez les fonctionnalités ajoutées ces dernières années - plus d'une vient d'F#) et c'est une porte ouverte aux développeurs fonctionnels vers le monde de l'industrie.

  • Olivier

    06/06/2009 06:11:21 | Répondre

    @Laurent: Bonjour ! Un ancien combattant delphiste... on en croise beaucoup dans le monde .NET Smile
    Pour les utilisateurs de OCaml, il est sûr que l'arrivée de F# doit être émoustillante. Le portage de OCaml sous .NET est une sorte de reconnaissance et le fait d'entrer dans un EDI aussi populaire que VS n'est pas rien Smile
    C'est forcément un signe des temps, et comme je le disais, le paradigme du fonctionnel est au moins un bon aiguillon pour pousser aux améliorations dans des langages comme C#.
    Je reste toutefois encore très réservé sur l'adoption de F# pour le daily business. Cela ne me semble pas très adapté. Mais peut-être n'est ce qu'une sensation passagère.
    Dans tous les cas, le fait que F# existe et soit intégré à VS2010 (la console F# est très sympa par exemple) donne un sacré coup d'accélérateur à OCaml qui restait très confidentiel jusqu'à maintenant.
    Des vocations vont peut-être naître ? !

    L'avenir nous le dira, mais je reparlerai certainement de F# et du fonctionnel d'ici là!

    Bon développement et au plaisir de te croiser à nouveau!

Ajouter un commentaire