Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Je m'en faisais justement la réflexion.Envoyé par fredoche
En fait à vous lire, on comprend pourquoi la programmation fonctionnelle n'est pas la norme
À lire le code Haskell, cela me rebute, c'est plein de symboles bizarre dans tous les sens.
Après, peut-être qu'en apprenant un peu, ça me paraîtra logique et facile, mais la première impression est très importante dans le choix d'un langage à apprendre.
Ce n'est pas un choix de langage, quitte à se répéter c'est un style applicable pourvu qu'on ait quelques trucs comme les fonctions d'ordres supérieures ou les fermetures. Le reste c'est juste une façon d'écrire du code, et certains langages autorisent toutes les façons. Il me semble que Python a largement cette faculté, comme JS
D'autres langages contraignent beaucoup, comme Java, Clojure ou Haskell
C'est de la pratique, comme pour tous langages, il faut un rapport au concret.
Haskell est assez particulier, puisqu’il ne supporte pas directement la programmation procédurale, ni le moindre effet de bord (modification de variable), du coup, il est nécessaire d’introduire des notions particulières (monades) et les constructions correspondantes (>>=, do ...) pour l’émuler.
Ces constructions ne sont pas nécessaires avec des langages supportant plusieurs paradigmes (Ocaml, Java...).
Cependant, il y a des différences assez révélatrices du style privilégié entre Java (programmation objet auquel on a ajouté le lambda calcul pour le rendre plus «*fonctionnel*») et Ocaml (langage fonctionnel dérivé de Caml pour y ajouter la programmation objet).
En Java, les variables sont mutables par défaut, (il faut les déclarer final pour les rendre constantes), en Ocaml, c’est l’inverse : on a par défaut des constantes (let x=42 in ... définit une constante) : il faut saisir let x = ref 42 in ... pour avoir une référence sur une variable. Ainsi Ocaml permet assez facilement (plus qu’Haskell) de programmer de façon procédurale, mais incite plus que Java à la programmation fonctionnelle.
On a d’autres différences typiques. En Java, le if (...) {...} else {...} exécute un des blocs selon un critère, et on en attend un effet de bord (sinon, il ne serait pas utile de l’exécuter). En Ocaml, on aura plutôt un if ... then ... else ... dont la valeur est l’une des deux dernières expressions. Comme un ... ? ... : ..., mais l’écriture est plus verbeuse et plus lisible avec des expressions un peu importantes.
Au contraire, si quand même un peu.
Pour coder, quelque soit le paradigme, il te faudra un langage.
Et pour coder en fonctionnel, il te faudra un langage adapté qui t'offre toutes les features, mais pas que, il te faut aussi toutes les contraintes/vérifications.
Sinon, tu risques de ne pas faire du "vrai" fonctionnel, ou au mieux du "90% fonctionnel".
Si le fonctionnel interdit les effets de bords, il te faut un moyen de les interdire, à moins de le déclarer explicitement, sinon ce n'est pas vraiment un bon outil adapté au fonctionnel. Suffit qu'un de tes collègues ou un stagiaire fasse un peu n'importe quoi, et tu te retrouveras avec du code non-fonctionnel dans ton programme. Or, si tu pars du principe que ton programme est à la base fonctionnel, et que tu ne fais que des tests unitaires, certains effets de bords pourraient passer à côté des tests.
Il n'y a pas que cela aussi. Si quand tu cherche "programmation fonctionnelle", tu tombes sur du Haskel qui te rebutes, tu risques d'abandonner ta rechercher et de te cantonner e.g. à l'impératif. De même si quand tu cherches "programmation python", tu ne tombes quasiment que sur de e.g. l'impératif, il y a peu de chances que faire du fonctionnel te viennes à l'esprit. Pas sûr ensuite que tu sois prêt à changer tes habitudes par la suite (ce qui est un coût, au minimum intellectuel).
Les représentants de chaques paradigmes sont importants pour leurs adoptions. Si le représentant du fonctionnel est Haskell, peut importe que d'autres langages soient adaptés au fonctionnel, on pensera Haskell quand on parlera du fonctionnel. Les deux, langage et paradigmes sont très liés.
Effectivement la discussion est partie un peu en vrille avec haskell. En même temps, si on parlait de programmation objet en comparant java et javascript, ça serait tout aussi indigeste.En fait à vous lire, on comprend pourquoi la programmation fonctionnelle n'est pas la norme
C'est objectivement simple, en aucun cas quelque chose d'obligatoire pour produire du code, mais quand on se met à couper les cheveux en 4...
Dans la pratique, on peut appliquer le fonctionnel dans plein de langages et ce n'est pas forcément plus compliqué. Même si c'est effectivement plus facile si le langage a été conçu pour ça...
La principale raison pour laquelle Haskell est compliqué est que l'on est confronté très vite au concept de monade qui est assez abstrait et compliqué puis, peu de temps après, au concept de monad transformer qui est encore plus abstrait. C'est parce que Haskell utilise les monades pour construire, dans un paradigme impératif, tout un tas de fonctionnalités. Par exemple, la monade IO sert à typer fortement les opérations non pures. La monade State fait de la composition de fonctions pour simuler des variables muables. D'autres monades servent à gérer de la propagation d'erreurs. D'autres monades cumulent plusieurs de ces rôles à la fois, etc.
Cependant, pour qu'un langage soit capable de faire tout ça, le concept de monade n'est pas obligatoire.
Par exemple, pour distinguer les fonctions pures des fonctions non pures, le langage D utilise l'attribut pure. Et si on veut créer une fonction avec une callback et dire que cette fonction n'est pure que si la callback est pure aussi, alors il faut définir un template de fonction et faire de la propagation d'attribut.
Certes, si le langage D était plus orienté fonctionnel, les fonctions auraient été pures par défaut et on aurait un attribut impure. Mais, en tout cas, pour qu'un langage permette de distinguer par le typage les fonctions pures et non pures, il n'est pas obligatoire d'obliger l'utilisateur de passer par des monades.
Non faire à 90% n'est pas grave. Il faut pas en faire un but ultime. Le but ultime, c'est une production qui fonctionne, te faciliter la vie en terme de maintenance, améliorer ta fiabilité, ton efficacité, etc. Le "vrai fonctionnel" on s'en fout quelque part d’autant qu'il peut bien coexister avec du OO et de l'impératif sans aucun problème particulier.
Tu rentres sinon dans une logique puriste qui devient fastidieuse et contraignante, et donc contre-productive, peu propice à une adoption souple et progressive.
Faut se confronter à la réalité, les projets from scratch sont rares, c'est souvent un travail sur le long terme, et tu peux décider à un moment donné de faire ces choix pour des raisons x ou y, et il sera préférable de muter vers un nouveau style soit les nouveaux modules, soit quelques parties, et surtout par étapes,de manière progressive.
Aucun style n'exclut un autre dans un langage souple. Le risque que tu évoques c'est relativement peanuts, et c'est aussi du management humain, de la communication, du partage de l'échange, ou bien de la formation dans le cas d'un stagiaire, que tu es censé accompagner.
Un bon pro, une bonne équipe ne re -designe pas tout parce que d'un coup le fonctionnel (ou OO, ou Haskell, OU RUST, OU GO)est devenu séduisant. Surtout quand tu as un bon codebase qui fonctionne. C'est aller droit au devant des problèmes.
Et juste pour rajouter que ce n'est pas nécessairement contraint par un outil, mais c'est dans ta façon d'écrire des fonctions que tu évites les effets de bord. Tu peux bien en générer dans le cadre de ta fonction, dans sa closure, mais pas en dehors de cette fonction. Et certains effets de bord sont nécessaires, comme les I/O.
L'idée de base sur ce sujet, c'est de prendre des paramètres, variables ou autres et de retourner un seul résultat, sans rien modifier ni de ces paramètres, ni du reste du monde extérieur à cette fonction.
Rien d’extraordinaire
Oui, mais des contraintes vérifiées par un outil sont utiles, surtout quand on reprend du code écrit par d'autres personnes.
Pour faire une analogie, en langage C, on n'a pas de mot-clef private pour les champs d'une structure, mais on est bien content de l'avoir en C++. On pourrait dire aussi que c'est dans la façon d'écrire du code C que l'on choisit de faire de l'encapsulation en faisant attention à ce que les champs d'une structure ne soit directement accédés que via les fonctions définies dans le couple de fichiers ".h"/".c" correspondant à cette structure. Mais, quand on récupère un code sur lequel sont passées plusieurs générations de développeurs, il y en a toujours qui font des bêtises.
Remarque : en langage C, il existe bien un moyen de faire de l'encapsulation imposée par le compilateur via les pointeurs opaques, mais cette technique tend à entraver les performances.
Les contraintes sur les effets de bord, j'aurais aimé les avoir aussi, surtout que, aujourd'hui, seule une minorité de développeurs trouve utile de rendre explicites toutes les entrées et les sorties de la majorité des fonctions. Par exemple, pour rendre le code testable, dans l'univers Java et C#, de ce que je vois sur internet, on dirait que la mode n'est pas de passer de paramètre en paramètre des stratégies ou callbacks, mais de passer par des sortes de variables globales configurables, dont la syntaxe est facilitée par des frameworks d'injection de dépendance.
Mais si tu ne fais pas de "vrai fonctionnel" alors tu perds une grande partie des avantages que tu t'attendais après avoir adopté l'approche fonctionnel.
Cela ne sert à rien de faire du fonctionnel pour éviter les effets de bords et ainsi faciliter les tests unitaires, si derrière, tu as des effets de bords qui se cachent un peu partout. Cela devient même pire au niveau de la sécurité du code car tu assumes par défaut que ton code ne fait pas d'effets de bords.
Je n'ai pas dit qu'il fallait empêcher tout effets de bords, mais de les empêcher s'ils ne sont pas explicites (i.e. déclaré avec un mot clé).
S'il suffisait de cela pour éviter les erreurs de programmations, on n'aurait jamais de bug dans les programmes.
Comme le fait remarquer Pyramidev, avoir des contraintes vérifiables, c'est très utile.
Après, je ne dis pas que toute ton application doit êtes écrites en fonctionnel, mais si tu décides de faire du fonctionnel sur une portion de ton code, tu dois avoir un moyen de vérifier et de t'assurer que ces portions sont en fonctionnel.
Et aussi, tout dépend du sens qu'on donne au mot "contrainte". Par exemple, les langages à garbage collector ne permettent pas au programmeur de faire des double free, et donc les segfaults qui vont avec. C'est une contrainte mais je pense que tout le monde est d'accord pour dire que c'est aussi un avantage.
Je pense qu'il reste pertinent de faire du fonctionnel, même dans un langage qui ne fait pas de contrôles statiques sur les impuretés des fonctions. Les entrées et sorties des fonctions seront plus visibles, même si le langage ne garantira pas qu'elles apparaissent exhaustivement dans la signature de la fonction.
Oui, enfin quelque soit le paradigme, il est toujours de bonne pratique d'éviter les effets de bords, ce n'est pas exclusif au fonctionnel.
Le fonctionnel en revanche, les interdits (ou demande à ce qu'ils soient au minimum explicitement indiqués).
De même que tu as d'autres bonnes pratiques comme le KISS, l'encapsulation, etc.
C'est comme si tu disais que l'impératif, c'est le fait d'appeler des fonctions et que donc tout code utilisant des fonctions est alors impératif.
Dans ce cas tout est tout.
La vérification c'est tes yeux. Quand tu écris ou réécris une fonction, les principes sont suffisamment simples à appliquer pour pas chercher de midi à 14h, d'autant que ce style de programmation tend à réduire la taille des fonctions vers des choses simples et utilitaires.
Et pas la peine de balancer la patate chaude au voisin d'à coté, vous êtes ce voisin d'à coté, potentiellement aussi mauvais sinon largement plus que lui.
Désolé Pyramidev, tu ne passes pas comme ça du C au C++ sur une base de code parce que tu vas bénéficier du mot-clef private. Ou alors le C n'a plus de raisons d'être.
Neckara, j'ai justifié mon raisonnement, et je le maintiens. Moi je fais un rapport à la vraie vie, et à celle des projets informatiques.
Je peux ensuite te sortir des foultitudes de liens sur les projets de refonte qui se cassent la gueule parce que on décide de tout dropper pour passer à un autre langage, un autre paradigme, à des supers théoriciens de la ligne de code, au nouveau framework qui poutre, etc. Les coûts sont de tous ordres, financiers en terme d'heures de travail, en terme de downtime de production, en terme d'image de marque, en terme de tas de problèmes quand avec de la chance on arrive à produire un résultat fonctionnel et conforme au cahier des charges.
Juste pour que chacun s'impregne bien ce que c'est que de discuter dans le vide sur des petits trucs de code qui concernent des détails à la con :
https://www.joelonsoftware.com/2000/...ver-do-part-i/
El_slapper ne serait-ce qu'ici a évoqué l’excellente idée d'une refonte COBOL vers java et les résultats obtenus.
Et je crois qu'il aime bien citer le sieur Spolsky lui aussi
Je peux vous raconter le souvenir d'un projet d'interface web sur Documentum gagné par les cadors de Cap Gemini pour les besoins d'HP, 3 mois de dev pour sortir un truc pourri et lent en Java là où moi je faisais le même genre d'interface en une semaine en Docbasic, avec l'avantage de bien connaitre la plateforme, et de l'avoir fait des comptes de fois auparavant. Après ça c'est la logique SSII. Le client le plus tu peux lui en faire avaler, y compris ton incompétence...le mieux c'est
Moi j'ai passé 16 ans à éditer le code que nous mettions en production, c'est pas la même logique non plus.
Pour la petite histoire, mais je n'y connais pas grand chose, visiblement les langages sans garbage collector sont des langages très problématiques du point de vue sécurité (et stabilité ) :
https://en.wikipedia.org/wiki/Memory_safety
Oui, enfin la vérification "par les yeux", c'est quand même assez souvent merdique.
Et bonjour pour faire de la vérification "par les yeux" sur un code de quelques millions de lignes.
Tu as déjà eu des gros bugs pour des erreurs toutes simples. C'est pas pour rien que justement on a des mots clés comme "private", "const", "final", pour justement vérifier qu'on ne fasse pas n'importe quoi. Ce n'est pas pour rien non plus qu'un certain nombre de compilateurs intègrent des warnings, qui sont assez souvent très utiles. Ainsi que toute une ribambelle d'outils pour vérifier ton code, que ce soit pour correspondre à la politique de ta boîte (e.g. indentation), ou pour repérer certains anti-patterns.
De même, les tests unitaires, c'est bien là parce que la vérification "par les yeux", c'est pas tip top et très faillible.
C'est surtout pour dire que si toi, tu n'as pas de difficultés à produire du "bon" code, c'est loin d'être le cas de tout le monde.
Hey, je n'ai pas dit qu'on était obligé de changer de paradigme en court de route.
Non tu t'inquiètes de ne pas faire du 100% fonctionnel.
Et je t'ai expliqué en quoi ce n'était pas un problème quand tu situes bien où est l'intérêt de ce style de programmation, et comment cette évolution peut être progressive, et non binaire (tout ou rien).
Quand aux millions de lignes de code, arrêtons de parler dans le vide, ou plutôt arrête... Pas de raisonnement par l'absurde STP
Personne ne te demande de revérifier ces millions de lignes, et c'est pas demain la veille que tu vas prendre une codebase de quelques milliions de lignes pour la passer au TDD.
Comme évoqué précédemment ça se fait progressivement.
Ben oui, si tu as des parties du code censées être écrites en fonctionnel, elles doivent être identifiée, et surtout vérifiées, i.e. les portions écrites en fonctionnel doivent être en fonctionnel, sinon cela n'a juste aucun intérêt.
C'est comme si tu disais, il faut utiliser du GC pour la sécurité, et que derrière dans le code que tu écris par la suite, tu le fais en C, et 50% de tes collègues continuent d'utiliser des malloc/free au lieu d'utiliser les fonctions que tu leurs aura donné.
Ou c'est comme quand tu dis "il faut porter son badge autours du coup dans les locaux de l'entreprise", mais que les 3/4 des employés ne le font pas par flemme, et parce qu'il n'y a aucune vérifications.
Pourtant c'est bien ce que fait ton compilateur quand tu lui demande de compiler, ou quand tu run des outils de vérifications syntaxique et autres.
C'est sûr que si tu fais tout à la main, ben c'est pas gagné...
Quand même vous n'avez pas cela dans votre entreprise ?
Vous n'avez pas des "hooks" sur git qui vous font quelques vérifications avant d'accepter les commits ?
Je ne vis pas dans la théorie Neckara, toi si
Et en plus tu as tendance à appeler ça de la Science, avec une majuscule. Mais pour ce qui concerne l'informatique, ce sont des techniques et elles sont appliquées. Dans le monde réel, partout désormais, absolument partout.
Quand même, il y a des "bests practices", si vous faites n'importe quoi, c'est votre droit. Mais cela ne retire rien au fait que vous fassiez n'importe quoi.
Tu as tout à fait le droit en entreprise de synchroniser ton code sur dropbox au lieu d'utiliser git, puis de renommer tes fichiers pour gérer le versionning, "main.tmp.old.old2.cpp", mais c'est faire de la merde.
Si vous ne vérifiez pas les contraintes requises par le fonctionnel dans les portions de votre code fonctionnel, alors vous ne faites pas de fonctionnel, au mieux vous faites de l'impératif qui ressemble à du fonctionnel. De même, ce n'est pas parce que vous avez 1 fonction sans effets de bords que tout de suite vous développez en fonctionnel.
C'est comme lorsque les entreprises prétendent faire de l'agile parce que c'est à la mode, mais derrière font du cycle en V.
Et ce n'est pas parce que j'utilise map/filter en C++ que je développe dans le paradigme fonctionnel.
Maintenant je comprends mieux pourquoi dans la vidéo il affirmait que le fonctionnel était de plus en plus intégré dans les langages et utilisés... c'est sûr que si dès qu'une personne respecte le "best practice" "éviter les effets de bords", on appelle cela du fonctionnel... tout code bien écrit devient du fonctionnel. C'est bien d'aimer le fonctionnel, c'est votre droit, mais de là à en voir partout...
Oui, c'est à peu près ce que Richard Feldman entend par le style fonctionnel, mis à part qu'il évoque aussi l'immuabilité.
Il n'y a pas de définition universelle qui délimite le fonctionnel du non fonctionnel, donc il faut dire sur quelle définition on se base si on veut débattre sur des détails.
Or, dans la vidéo, de 35m50 à 36m30, Richard Feldman explique ce qu'il entend par le style fonctionnel. Et il définit le style fonctionnel par Avoid mutation and side effects en précisant bien qu'on peut le faire dans les langages qui autorisent la muabilité et les effets de bord, même s'il est vrai que certains langages supportent mieux le fonctionnel que d'autres.
Répondre avec citation