Dans le domaine du jeu vidéo, on voit apparaître depuis 10-15 ans un retour vers la programmation fonctionnelle (qui est très vieille), notamment avec le concept de Data-Oriented Design et les Entity Component System.
La programmation orienté objet s'est faite malmenée en entreprise. J'entends par la que les paradigmes initiaux ont été détourné de telle sorte qu'elle ne tient plus ses promesses (réutilisation du code).
J'en profite pour citer sans connaître l'auteur original :
En POO, si tu veux une banane, tu dois ajouter le gorille qui tient la banane et toute la forêt.
Sauf que POO et Programmation Fonctionnelle ne sont pas incompatible. Prenons l'exemple de Go (ugh, qu'est-ce que je déteste ce langage trop pratique...). Il y a des interfaces, des structures, des méthodes. Pas d'héritage, que de la composition. C'est suffisant pour implémenter de l'injection de dépendance, pattern très utilisé en programmation fonctionnelle pour découpler le business code de l'implémentation.
Les ECS en gamedev sont aussi une forme d'injection de dépendance, ajouter un composant (uniquement des data) à une entité (uniquement un id) lui ajoute de la fonctionnalité via les systèmes (uniquement de l'implémentation).
Cette découpe est non seulement pratique d'un point de vue maintenance du code, mais en plus, elle scale bien.
Et si on reprend l'exemple de la POO dans le monde des entreprises, avec les dizaines de couche d'abstraction pour faire un print, les librairies qui font plus que leur scope initiale (coucou log4shell), ça ne scale pas. On se retrouve 10 ans plus tard avec un monolithe qui mets 45min a build un simple commit.
J'ai même envie de faire le parallèle avec l'infrastructure. Aujourd'hui, les microservices sont au centre d'une grosse hype. L'idée étant d'avoir des briques élémentaires (fonctions, microservices, ...) que tu assembles comme des Lego pour construire un système complexe.
Alors oui, les microservices ne répondent que a un problème organisationnel de l'entreprise (comment plusieurs teams peuvent bosser sur le même projet sans se marcher dessus ?), j'ai envie de dire que la programmation fonctionnelle répond à un problème organisationnel du code source (comment plusieurs systèmes peuvent fonctionner en parallèle sans fuite de l'API et avec une bonne "Separation of Concerns").
L'autre raison que je vois à la popularité de la programmation fonctionnelle, c'est :
React/Redux et ses successeurs, dont l'architecture est purement fonctionnelle (l'UI est une fonction qui prend en paramètre le state)
Le plus marrant je trouve la dedans, c'est que la montée en popularité de la programmation fonctionnelle a lieu surtout dans des langages qui ne sont pas fonctionnels :
# J'ai pas écouté le podcast, mais mon grain de sel
Posté par David Delassus (site web personnel) . En réponse au lien Is functional programming the hipster programming paradigm?. Évalué à 8.
Dans le domaine du jeu vidéo, on voit apparaître depuis 10-15 ans un retour vers la programmation fonctionnelle (qui est très vieille), notamment avec le concept de Data-Oriented Design et les Entity Component System.
La programmation orienté objet s'est faite malmenée en entreprise. J'entends par la que les paradigmes initiaux ont été détourné de telle sorte qu'elle ne tient plus ses promesses (réutilisation du code).
J'en profite pour citer sans connaître l'auteur original :
Sauf que POO et Programmation Fonctionnelle ne sont pas incompatible. Prenons l'exemple de Go (ugh, qu'est-ce que je déteste ce langage trop pratique...). Il y a des interfaces, des structures, des méthodes. Pas d'héritage, que de la composition. C'est suffisant pour implémenter de l'injection de dépendance, pattern très utilisé en programmation fonctionnelle pour découpler le business code de l'implémentation.
Les ECS en gamedev sont aussi une forme d'injection de dépendance, ajouter un composant (uniquement des data) à une entité (uniquement un id) lui ajoute de la fonctionnalité via les systèmes (uniquement de l'implémentation).
Cette découpe est non seulement pratique d'un point de vue maintenance du code, mais en plus, elle scale bien.
Et si on reprend l'exemple de la POO dans le monde des entreprises, avec les dizaines de couche d'abstraction pour faire un print, les librairies qui font plus que leur scope initiale (coucou log4shell), ça ne scale pas. On se retrouve 10 ans plus tard avec un monolithe qui mets 45min a build un simple commit.
J'ai même envie de faire le parallèle avec l'infrastructure. Aujourd'hui, les microservices sont au centre d'une grosse hype. L'idée étant d'avoir des briques élémentaires (fonctions, microservices, ...) que tu assembles comme des Lego pour construire un système complexe.
Alors oui, les microservices ne répondent que a un problème organisationnel de l'entreprise (comment plusieurs teams peuvent bosser sur le même projet sans se marcher dessus ?), j'ai envie de dire que la programmation fonctionnelle répond à un problème organisationnel du code source (comment plusieurs systèmes peuvent fonctionner en parallèle sans fuite de l'API et avec une bonne "Separation of Concerns").
L'autre raison que je vois à la popularité de la programmation fonctionnelle, c'est :
Le plus marrant je trouve la dedans, c'est que la montée en popularité de la programmation fonctionnelle a lieu surtout dans des langages qui ne sont pas fonctionnels :
Alors qu'il y a OCaml, Elixir, Haskell, Purescript (si tu veux compiler en du Haskell en JS), etc...
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg