Pourquoi la programmation fonctionnelle n’est-elle pas la norme de l’industrie du code ?

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.

Envoyé par fredoche

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...

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.

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.

Envoyé par Neckara

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.

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.

Envoyé par Neckara

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.

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

Envoyé par fredoche

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.

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.

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.

Envoyé par Neckara

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.

Envoyé par Neckara

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.

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.

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

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.

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.

Envoyé par Neckara

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.

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.