Discussion :

[Sebajuste]

Comme toujours, il s'agit de trouver le bon outil pour le bon problème...

Je me suis rendu compte que le fonctionnel était utile à mon projet au moment où j'ai commencé à multiplier les CompletableFuture dans un contexte fortement asynchrone.
Mais dire que j'ai remplacé l'objet par le fonctionnel n'a pas de sens...
Il ne devrait pas s'agir de mode, mais de réel besoins !

Quand à l'écriture lisible, c'est surtout de l'expérience et des bonnes pratiques. Qui n'a jamais écris un objet / classe pourrie à ses début dans la POO ^^
L'enfer des callback dans des callback est une réalité ! Mais il y a là aussi des bonne pratiques pour les éviter. Et devinez quoi ? C'est grâce à la POO qu'on peut écrire quelque chose comme :

do( (...) -> ... )
.then( (...) -> .... )
.then( (...) -> .... )
.end( (...) -> .... )

[Zefling]

C'est grâce à la POO qu'on peut écrire quelque chose comme :

do( (...) -> ... )
.then( (...) -> .... )
.then( (...) -> .... )
.end( (...) -> .... )

Sauf qu'il me semble que ce n'est pas de l'objet ça.

[Sebajuste]

Sauf qu'il me semble que ce n'est pas de l'objet ça.

Et pourtant si. Il s'agit d'un objet de contrôle, dont la signature d'une méthode ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Observable {
...
   public Observable do(LambdaFunction f);
...
}

Suivant les paradigmes, l'objet retourné peut être this, on une autre instance de la classe Observable (ce qui est le cas de ReactiveX : http://reactivex.io/ ) .

[Invité]

Et pourtant si. Il s'agit d'un objet de contrôle, dont la signature d'une méthode ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Observable {
...
   public Observable do(LambdaFunction f);
...
}

Suivant les paradigmes, l'objet retourné peut être this, on une autre instance de la classe Observable (ce qui est le cas de ReactiveX : http://reactivex.io/ ) .

Pourtant Zefling a raison : le pattern do/then vient du fonctionnel. C'est une façon classique de simuler les side effects avec des immutables. Après on peut coder ça dans un langage objet mais ça vient bien du fonctionnel. D'ailleurs reactivx dit clairement s'inpirer du fonctionnel : "ReactiveX is a combination of the best ideas from the Observer pattern, the Iterator pattern, and functional programming"

[pocky6]

C'est marrant car je n'ai pas eu ce ressenti du tout depuis le début. A la fac, dans ma jeunesse, on avait la même année un cours qui utilisait Ada, et un qui utilisait Scheme.

- Avec Ada, lors du premier TP (après un an de C et 2 ans de turbo pascal), si on arrivait à compiler un Hello World on avait de la chance.
- Avec Scheme (un dialecte de Lisp), chacun des énoncés, avec manipulation de données, de fonctions etc, réussissait du premier coup.

Alors certes ce n'est qu'une expérience personnelle, et, si j'ai kiffé Haskell, je n'ai pas été explorer les arcanes les plus obscurs du langage, mais j'y ai trouvé une simplicité et une fluidité qui contrastent avec ce que je lis dans ces commentaires, et ce dès le premier instant.

~

Sinon j'aime bien l'expression utilisée par @iclo, et le côté paradoxal de dire que la programmation n'est pas faite pour un développeur lambda .

[sacdebille]

on essaie de mettre nos enfants à la programmation
déjà que les profs qui sont des truffes en programmation ont du mal avec le procédural et l'objet …. j'imagine avec le fonctionnel

[23JFK]

Encore un qui a trouvé un filon pour se faire rémunérer lors de conférences au titre de gourou du lambda calcul.

[floyer]

« Les classes génériques, c'est un peu plus touchy, mais on peut faire plein de trucs sympas en objet sans en avoir besoin. »

La programmation générique permet de coder des structures « génériques » comme des dictionnaires, listes doublement chaînées, puis les réutiliser avec n’importe quelle structure (pas forcément des classes).

Java ne les avait pas au début, si bien que les bibliothèques proposaient des dictionnaires, listes, etc d’objets sans restriction sur le type d’object, ce qui restreint le contrôle de type (on ne pouvait pas avoir un dictionnaire qui n’accepte que des entiers, sauf à recoder un type spécifique).

L’usage de type générique est donc très utile (bibliothèque Java, bibliothèque STL C++...), mais il est vrai que l’on peut très bien être un simple utilisateur sans créer soit même un type générique.

[Neckara]

Moi, je suis fier de n'écrire exclusivement que des codes non-fonctionnels.

2. Par extension. Qui est conçu de manière à être parfaitement adapté à sa fonction. Un mobilier fonctionnel, un équipement fonctionnel.

https://www.dictionnaire-academie.fr/article/A9F1177

[defZero]

Partagez-vous l’avis selon lequel l’approche fonctionnelle finira par s’imposer comme norme ?

Oh, mais je pense que c'est déjà le cas, comme le dit déjà très bien M. Feldman dans son speech.
Surtout que les approches Procédural, Objet & Fonctionnel, ne sont pas fondamentalement exclusive.
Il suffit de choisir en fonction des circonstances, quel est le meilleur paradigme.

Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?

Personnellement, j’adhère, maintenant le seul problème que j'y voix, ce sont les autres .
A chaque fois que j'ai commencé à utiliser des constructions fonctionnel, il y avait toujours quelqu'un pour me sortir "Mais pourquoi t'as pas utilisé une boucle for ?" ou un truc du genre.
A la longue, ça dissuade pas mal de l'utiliser dans un projet en équipe.
Ce qui ne m’empêche pas de l'utiliser dans des projets perso, quand ça si prête.

Après côté complexité, c'est un faut problème parce que les gens ont dans la grande majorité été formés sur de la POO, donc tous les autres paradigmes vont forcement entrainer une complexités supplémentaire pour eux.
Disons que pour quelqu'un qui n'as jamais toucher à du code, le fonctionnel peut éventuellement paraitre plus logique et plus simple que du code objet qui nécessite quand même plus de connaissances pour être abordé (j'ai pas dit maîtrisé ).

Et puis, comme le dit très bien M. Feldman, les langage OO d'aujourd'hui, ne correspondent même pas à la définition qu'en avait fait M. Kay (créateur de Smalltalk).
Si on compare les modèles Objet de CLOS et Smalltalk qui ont tous deux servie de mètre étalons pour définir ce qu'était la POO, alors aucun langage actuel ne l'est vraiment (sauf Smalltalk, Erlang, CLOS & variantes).

Votre expérience des tests unitaires et du refactoring de code a-t-elle souvent été pénible sur des bases de code montées en s’appuyant sur l’approche orientée objet ? Si oui, pourquoi ?

Oui, c'est forcement pénible à partir du moment ou tu finit par toucher à une arborescence, toutes modifications ne fait qu'augmenter en complexité avec la profondeur de celle-ci.
En théorie, il suffit d’aplanir ça hiérarchie des classes / objets , mais ce n'est pas toujours possibles / faisable et ça réduis de toute façon mécaniquement le niveau d'abstraction de son code.
En parallèle, avec un langage fonctionnel, on est déjà bien abstrait en ce qui concerne la machine et il est beaucoup plus simple de raisonner au niveau d'une fonction pure que dans un contexte d'objets et de classes hiérarchisés ou il faudrait être un sur-homme pour pouvoir être sur à 100% de ce que l'on fait réellement.
Du coup, concernant les tests, c'est évidemment plus simple de tester une fonction (pure) que de devoir se palucher des Mocks et autres pour simuler tout un contexte d’exécution pour tester une méthode.
Les testes fait sur une base fonctionnel, sont largement plus maintenables, sures et faciles à mettre en place.

[JackIsJack]

Je m'attendais à en savoir plus sur l'efficacité des languages fonctionnels dans la vidéo... mais pas une seule ligne de code en exemple, ni de comparaison d'une même programme développé en fonctionnel versus autre technique. Donc bof.

[CaptainDangeax]

Je m'attendais à en savoir plus sur l'efficacité des languages fonctionnels dans la vidéo... mais pas une seule ligne de code en exemple, ni de comparaison d'une même programme développé en fonctionnel versus autre technique. Donc bof.

Hello
Regarde le tutoriel Haskell, qui te montre une implémentation du quicksort en 3 lignes... C'est sûr c'est efficace et assez facile à comprendre. Par contre, ce que le tutoriel ne montre pas, ce sont les préliminaires et le postérieur. Les préliminaires, c'est la séquence qui a créé la liste à trier, les postérieurs, c'est l'utilisation de la liste une fois triée. Et j'ai bien écrit séquence, ce qui est peut-être le plus dur à comprendre en programmation fonctionnelle : fonctionnaliser une séquence.

[Pyramidev]

En Haskell, c'est vrai qu'on peut condenser beaucoup le code. Pour reprendre deux exemples sur Wikipédia :

• Une suite de Fibonacci mémoïsée :
  

  Code Haskell :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  fibs = 0 : 1 : (zipWith (+) fibs (tail fibs))
  fib n = fibs !! n

• Un pseudo quick sort beaucoup plus lent que le vrai quick sort, mais concis :
  

  Code Haskell :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  qsort []     = []
  qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Mais, dans la vidéo, quand Richard Feldman explique ce qu'il entend par le style fonctionnel, à 35m50, il ne parle pas d'écritures condensées, mais d'éviter la muabilité et les effets de bord. D'ailleurs, les langages fonctionnels ne sont pas tous aussi concis que Haskell.

Le style objet ne dit rien sur la muabilité et sur les effets de bord : on peut facilement écrire des fonctions avec plein d'effets de bord et modifier silencieusement des variables qui seront lues à des endroits insoupçonnés du programme. En bref, le style objet autorise à écrire des pâtés de code dont on ne connaît pas les entrées et les sorties sans plonger dans l'implémentation. On peut coder quand même correctement en objet, mais ce n'est pas le style objet qui l'incite.

Le style fonctionnel, par contre, impose des contraintes strictes avec lesquelles on a moins de liberté de mal architecturer le code.

Remarque : appliquer le style fonctionnel à l'extrême n'est pas forcément une bonne idée. Par exemple, pour implémenter un algorithme de tri vraiment rapide, il faut de la muabilité. Mais, en règle générale, dans les fonctions de haut niveau, le style fonctionnel tend à améliorer la maintenance.

[Goliver]

Un truc qui, selon moi, freine également l'adoption du fonctionnel par beaucoup (malgré sa puissance et son regain d'intéret depuis quelques temps) c'est que dans le millieu du développement industriel on demande à produire beaucoup dans un laps de temps court. Dans la mesure où le fonctionnel peut demander beaucoup plus de réflection, cela peut s'avérer difficile dans un contexte où les tâches sont à rendre pour hier et que rien que les TU prennent la poussière. Par contre dans un domaine ou la puissance, la sureté, et la rapidité de traitement est la première recommandation, je veux bien croire que la PF fasse bien le taff.

[pschiit]

Intellectuellement, c'est sympa de faire du fonctionnel.
Mais à maintenir, c'est une plaie.
Même pour la personne qui a créé le code, retrouver comment une récursion a été pensé un an après devient très compliqué .
Pour qq1 d'autre ça devient très chaud

[Invité]

Intellectuellement, c'est sympa de faire du fonctionnel.
Mais à maintenir, c'est une plaie.
Même pour la personne qui a créé le code, retrouver comment une récursion a été pensé un an après devient très compliqué .
Pour qq1 d'autre ça devient très chaud

Je pense exactement le contraire : le fonctionnel est plus facile à maintenir, notamment parce qu'il y a moins de side effects. Les langages fonctionnels sont souvent haut-niveau et on a rarement besoin d'écrire des recursions. Le dernier projet "fonctionnel" sur lequel j'ai bossé a une centaine de fonctions et aucune n'est récursive. Par contre, il y a beaucoup de map/reduce, et c'est bien plus lisible que des boucles.

[CaptainDangeax]

Intellectuellement, c'est sympa de faire du fonctionnel.
Mais à maintenir, c'est une plaie.
Même pour la personne qui a créé le code, retrouver comment une récursion a été pensé un an après devient très compliqué .
Pour qq1 d'autre ça devient très chaud

Oui, et non.
Une récursion un peu chiadée où le développeur n'a pas commenté ce qu'il a voulu faire, OK, mieux vaut ré-écrire en partant des specs.
Pour une requête SQL ou l'exemple haskell quicksort, ça va...

[Invité]

Oui, et non.
Une récursion un peu chiadée où le développeur n'a pas commenté ce qu'il a voulu faire, OK, mieux vaut ré-écrire en partant des specs.
Pour une requête SQL ou l'exemple haskell quicksort, ça va...

Quand on utilise un langage fonctionnel au quotidien, on fait assez peu de récursivité en fait. On utilise généralement des fonctions de plus haut niveau, qui masque complètement leur fonctionnement interne récursif.
Pour une requète SQL, il n'y a pas besoin de récursivité, il suffit juste d'appeler une fonction du driver du SGBD, comme dans les autres paradigmes.
Quant au quicksort, la récursivité vient de l'algo lui-même et non du langage. D'ailleurs même dans la libc, qsort est implémenté de façon récursive.

[Neckara]

D'ailleurs même dans la libc, qsort est implémenté de façon récursive.

L'implémentation semble être itérative, en simulant la récursivité via une stack (ce qui est assez commun) :

1. Non-recursive, using an explicit stack of pointer that store the next array partition to sort.

https://github.com/lattera/glibc/blo...stdlib/qsort.c


D'ailleurs question stupide, pour un langage fonctionnel, comment les récursions sont gérées en interne ?
Il passent comme des appels de fonctions avec tout ce que cela implique au niveau des registres CPU/la pile, ou c'est transformé dans une version itérative via une stack ?

Moi, ce qui me choque c'est que ça fait 7 langages en 2 ans, mais aucun langage fonctionnel. Et après on va dire que le fonctionnel n'est pas naturel. Bah c'est un peu logique si on ne l'aborde pas dans les formations...

Ben prend n'importe quel classement des langages TIOBE, popularité, utilisation github, t'as pas beaucoup de langages fonctionnels dans le top.
Le but de l'éducation supérieur c'est aussi de former à ce que les étudiants seront le plus probablement amené à utiliser.

Ce n'est pas le rôle de l'éducation supérieur de prendre parti et de décider qu'il faut faire du fonctionnel parce que c'est le paradigme que j'aime.
Déjà qu'on a pas le temps de creuser en détails tous les bon principes de développement (e.g. ssémantique d'entité/de valeur).

https://emploi.developpez.com/actu/2...lent-vraiment/
https://www.tiobe.com/tiobe-index/
https://githut.info/

[floyer]

Quant au langage dans lesquels les bibliothèques sont codées, on en a franchement rien à faire.
Quand je fais un "import" en Python, je n'ai aucune idée du langage qu'il y a derrière, et en même temps, j'en ai rien à faire, c'est aussi le principe d'encapsulation.

Indirectement, c’est important, puisque cela conditionne les performances. Ainsi, lorsque je trace une figure, autant que les fonctions de tracé (driver graphique), ne vérifient pas le type des paramètres à chaque pixel ce qui ferait tout ralentir. Mais effectivement c’est le résultat qui compte.

Pour le programme appelant, cela dépend si ses performances sont importantes (une IHM qui répond en 0,01s ou 0,02s ne fera pas la différence), et sont conditionnées par les bibliothèques (90% du temps dans BLAS ou FFTW rendrait peu pertinent une optimisation au niveau des procédures appelantes. Un 10% dans les bibliothèques et on peut s’intéresser à optimiser le code ou prendre un meilleur langage).