- « La programmation fonctionnelle (FP) est difficile à apprendre, mais elle fera en sorte que votre code provoque moins de mauvaises surprises »
- En FP, « less is more »
- Résoudre le problème des références nulles (avec
Maybe/Option)
- La FP a une courbe d’apprentissage raide
- L’avenir de la FP
- Pour développer davantage avec moins de développeurs, il faut utiliser tous les outils possibles, et la FP est un ticket pour y parvenir
- Les entreprises peu glamour comme la nôtre ont du mal à recruter des développeurs. Mais il devient possible d’attirer des développeurs de tout premier plan qui veulent travailler sur une codebase FP
- Adopter la FP améliore la qualité et la robustesse, et réduit le temps consacré à des bugs qui n’existent pas en FP
- Le fait que les fonctionnalités de la FP commencent à apparaître de plus en plus dans les langages grand public montre que l’industrie logicielle se prépare à un changement de paradigme
- Il reste beaucoup de travail avant que le secteur ne bascule complètement, mais les avantages de cette approche sont si clairs qu’il n’y a guère de doute sur la direction à prendre
13 commentaires
Il me semble que la courbe d’apprentissage est effectivement élevée, et même dans les commentaires il y a des propos qui montrent qu’on ne comprend pas vraiment la programmation fonctionnelle dans son ensemble. Bien sûr, il y a aussi des commentaires écrits par des personnes qui la maîtrisent bien. La programmation fonctionnelle est difficile. Moi aussi, je l’étudie encore, ouin ouin.
Nous ne pourrons vraiment reparler de la nécessité de la programmation fonctionnelle que lorsque le choix d’un langage de programmation ne relèvera plus des préférences de l’équipe de développement, mais de la survie même de l’entreprise.
Je vais résumer. La programmation orientée objet n’a pas encore été dépassée, notamment en gestion de la mémoire et pour certains algorithmes. Il faut donc l’utiliser de manière appropriée selon le contexte et le coût.
Euh… je ne peux pas dire que je sois d’accord avec l’idée que la courbe d’apprentissage soit raide.
Déjà, c’est simplement facile, il y a moins de place pour les erreurs et, par conséquent, la productivité augmente.
Ça suffit, non ?
Il est difficile de formaliser parfaitement la pensée et le travail humains comme le font les langages de programmation purement fonctionnels. Quand on voit des choses comme les free monads, on a l’impression que
rxjsreprésente à peu près la limite maximale acceptable.Le FP aussi finit par atteindre un moment où le coût dépasse le bénéfice.
Même les effets FP existants ne vont guère plus loin qu’une séparation entre données et méthodes,
et le simple fait que les optionals soient moins utilisés qu’on pourrait le penser montre bien que l’abstraction par les types est une abstraction inutile (la productivité se fait trop rogner à force d’essayer de faire coller les types).
À moins d’aller dans une direction qui abstrait encore davantage les données et les opérations, à la manière des closures, il y a des limites à ce qu’on peut faire avec les langages existants.
L’immutabilité n’est qu’un outil fréquemment utilisé dans le paradigme de la programmation fonctionnelle.
À ma connaissance, le paradigme de la programmation fonctionnelle est un paradigme de programmation qui cherche à contrôler autant que possible les « effets de bord » (side effects).
En cherchant à contrôler les effets de bord, on en vient naturellement à accorder de l’importance à des notions comme la transparence référentielle, l’immutabilité ou les fonctions pures.
Dans cette optique, je pense que, même sans utiliser un langage de programmation fonctionnel, il est souhaitable d’avoir une conscience claire des effets de bord des fonctions ou méthodes que l’on écrit et de pouvoir les maîtriser de manière appropriée. Cela présente de nombreux avantages, comme la réduction des code smells dans le code et la facilitation de l’écriture de tests unitaires.
Il existe aussi un article traduit qui explique cela plus en détail.
Dans cette même perspective, il existe le livre Le codage fonctionnel qui s’assimile facilement : dompter des logiciels complexes avec un code simple, qui se concentre sur le refactoring visant à minimiser les effets de bord. Comme il adopte une approche pratique et orientée métier plutôt que théorique, il mérite largement d’être lu et assimilé par toute personne souhaitant écrire du bon code. À mon avis, si sa lecture vous amène simplement à faire bien plus attention qu’avant aux effets de bord lorsque vous écrivez du code, alors le livre vaut déjà largement son prix.
Merci, je vais aller le chercher et le lire.
Ah ! Je ne savais pas qu'une traduction était sortie ! Il faut que je la lise !
Merci pour la recommandation de livre !! Je vais l’acheter tout de suite et le lire !
J’ai vraiment beaucoup aimé ce livre !
Le regarder sous l’angle du refactoring le rend aussi très pratique à utiliser.
Bien sûr, je pense aussi que la programmation fonctionnelle est une bonne approche, mais il me semble qu’il y a peu de personnes qui en expliquent les avantages de manière vraiment convaincante. Si on se contente de dire que c’est bien, ce n’est pas très parlant, n’est-ce pas ?
Ce qui suit est un avis personnel : comme tous les programmes modernes reposent en pratique sur le modèle de la machine de Turing, on peut les diviser de façon très abstraite en fonctions et en données ; c’est pourquoi je pense que, fondamentalement, la programmation procédurale est elle aussi de nature fonctionnelle. Dès lors, quel est le véritable avantage du paradigme fonctionnel par rapport au procédural ? À mon sens, c’est tout simplement le fait de « ne pas utiliser de variables globales ou assimilées ». Cet avantage rend plus efficaces à la fois « l’isolation entre fonctions » et le « calcul multithread ».
Mais cela ne signifie pas que ces bénéfices ne peuvent être obtenus que par la programmation fonctionnelle. Même dans les langages procéduraux, l’isolation au niveau des classes et des fonctions est recommandée via le concept de dependency injection (et tous les frameworks modernes l’ont déjà adopté par défaut), tandis qu’avec le langage Rust, des restrictions au niveau du langage ont été mises en place pour favoriser une informatique concurrente pratique.
En résumé, les langages fonctionnels sont de bons langages et une bonne méthodologie, mais plutôt que d’être « supérieurs au sens évolutif », je les considère simplement comme des langages « difficiles à utiliser, qui s’efforcent d’éliminer au niveau du langage les possibilités d’échec », à l’image de Go ou de Rust.
Voulez-vous dire que des choses comme la composition de fonctions sont aussi possibles dans les langages procéduraux ?
Si l’on prend une définition étroite de la « composition de fonctions », on peut penser que cela n’est possible que dans les langages fonctionnels. Mais en y réfléchissant, leur exécution repose de toute façon sur du langage machine ou de l’assembleur, qui sont des langages procéduraux. Autrement dit, ce n’est pas une question de « possible ou impossible », mais de « centres d’intérêt, préférences et philosophie du langage ». Si l’on élargit la définition de la « composition de fonctions », non pas comme « une fonctionnalité spécifique d’un langage particulier », mais comme « une composition entre fonctions logiques », alors c’est tout à fait possible. Et comme les langages fonctionnels ont clairement des avantages, des outils comme rxjs ou spark les ont activement repris.
Comme tout le monde l’a appris en informatique à l’université, ce qui suit produit le même résultat ; seule la forme d’expression diffère. Et la notation préfixe est souvent qualifiée de fonctionnelle.
Notation préfixe : + 1 1
Notation infixe : 1 + 1
Notation postfixe : 1 1 +