Lambda et fonctionnelle

Après la POO, on se disait : “C’est bon, on a tout ce qu’il faut pour coder propre.”
Mais en vrai ? Pas tout à fait.

À force de manipuler des objets et d’empiler des classes, on s’est retrouvés avec des tonnes de boilerplate
pour des trucs qui auraient pu être simples.
Genre, t’écris trois pages de code juste pour trier une liste ? Sérieux ?

C’est là que la programmation fonctionnelle a commencé à revenir sur le devant de la scène.
Ouais, revenir, parce qu’elle existait déjà dans les années 50 avec Lisp.
Mais c’est vraiment avec des langages comme Haskell et plus tard Scala que ça a pris son envol.
Puis les autres ont suivi : JavaScript, Python, Java 8…
tout le monde a ajouté des lambdas et des fonctions comme map(), filter(), reduce().

Les fonctions lambda ?
Ce sont des fonctions anonymes, super concises, que tu peux balancer direct en paramètre d’une autre fonction.

Résultat ?

• Moins de code (adieu les fonctions inutiles déclarées à rallonge).
• Plus de lisibilité (oui, c’est plus clean une ligne de map() qu’une boucle for de 10 lignes).
• Une approche déclarative : tu dis ce que tu veux faire, pas comment le faire.

Aujourd’hui, c’est devenu un réflexe.
T’écris en JavaScript ? Impossible de ne pas utiliser des lambdas.
Même en Python ou en Java, c’est devenu indispensable pour manipuler des collections, des flux de données, ou pour du traitement parallèle.

Et au-delà des lambdas, la programmation fonctionnelle a amené des concepts comme :

• Les fonctions pures.
• L’immutabilité (bye bye les effets de bord).
• Les higher-order functions qui rendent ton code plus prévisible et plus facile à tester.

Mais attention, trop de fonctionnel peut vite rendre ton code illisible si c’est mal utilisé.
Un reduce() mal branlé et ton collègue passe la journée à comprendre ce que t’as fait.

➡️ T’en penses quoi, toi ?
Les lambdas, c’est la liberté ou c’est juste un moyen de rendre le code incompréhensible ?
Balance ton avis !