Discussion :

[el_slapper]

Pour moi, ça confirme que c'est une question d'habitude. La base du fonctionnel, c'est juste les fonctions et la récursivité, et ça existe aussi dans les autres langages. Evidemment les choses se compliquent un peu quand on veut développer un vrai logiciel mais l'objet aussi ça se complique quand on aborde le polymorphisme, la composition, les design patterns... sans même parler des prototypes et des classes génériques...

Le polymorphisme, ça peut parfaitement se faire en procédural, et honnêtement, ça se pige vite en objet. Les designs patterns...ben, c'est des structures de code standard, la culture objet en fait la promotion, mais sur le principe, ça n'a rien d'objet. C'est juste un catalogue de pratiques standard. 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. En fonctionnel, une fois passé le mur du récursif, je me suis immédiatement cogné à d'autres murs, puis encore d'autres. Si j'avais eu le temps, je serais sans doute passé au travers(mais cette mission ou je ne foutais rien s'est interrompue, et je n'ai plus eu le temps de continuer), mais l'effort m'a honnêtement paru bien plus grand que pour l'objet.

LISP existe depuis les années 50 et est toujours utilisé. Et d'autres langages fonctionnels sont aussi couramment utilisés. C'est juste qu'on en entend moins parler.

Et? Ils sont utilisés par des gens au profil spécifique, avec une formation spécifique, sur des sujets spécifiques. Si la banque machin ou l'assurance truc ne veulent pas de ses langages, ce n'est pas(enfin pas uniquement) par étroitesse d'esprit. C'est aussi parce-qu'ils savent qu'en cas de pénurie, ils peuvent toujours ramasser de jeunes diplômés scientifiques, les former sur le tas, et garder les 20/25% qui arrivent à se dépatouiller(superbonus : c'est les SSII qui payent la formation, en général). Essaye de faire ça en LISP. Le taux de retention va chuter à 2/3%.

Je sais pertinemment tous les avantages du fonctionnel. J'ai lu tout Paul Graham, c'est dire. Et je reste non impressionné malgré tout. La technique ne fait pas tout. Un choix de langage pour l'entreprise est une décision complexe, faisant appel à des critères variés, que l'on trouve à différents niveaux. Dire "mon langage c'est le meilleur", c'est très insuffisant. Déjà, est-ce le meilleur pour mon application? A-t-on besoin de la puissance algorithmique du fonctionnel pour traiter la trésorerie des agences bancaires? Ou est-il préférable d'avoir un langage plus plan-plan, moins élégant, mais sur lequel on peut mettre des gens qui n'ont pas un bac+8 en physique nucléaire? La question se pose évidemment en d'autres termes dans d'autres domaines, ou l’algorithmique est beaucoup plus poussée. Et ce sera ma conclusion : les différents paradigmes, comme les différents langage, ont chacun des domaine sou il sont plus ou moins forts. "mon langage(ou mon paradigme), c'est le meilleur", ça n'a aucun sens. "Dans tel contexte, tel langage est plus adapté"; c'est déjà beaucoup plus pertinent(et malgré tout debatable, mais au moins on parle d'un débat basé sur une réalité, pas sur des fantasmes).

[Pyramidev]

Je sais pertinemment tous les avantages du fonctionnel. J'ai lu tout Paul Graham, c'est dire.

Du coup, à tes yeux, quelle est la liste des avantages du fonctionnel ?

[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"

[Invité]

Je sais pertinemment tous les avantages du fonctionnel. J'ai lu tout Paul Graham, c'est dire.

Désolé mais pour moi c'est juste un argument d'autorité qui ne veut rien dire. De plus Graham parle essentiellement de lisp, qui n'est qu'une partie du "fonctionnel moderne".

Dire "mon langage c'est le meilleur", c'est très insuffisant. Déjà, est-ce le meilleur pour mon application? A-t-on besoin de la puissance algorithmique du fonctionnel pour traiter la trésorerie des agences bancaires? Ou est-il préférable d'avoir un langage plus plan-plan, moins élégant, mais sur lequel on peut mettre des gens qui n'ont pas un bac+8 en physique nucléaire? La question se pose évidemment en d'autres termes dans d'autres domaines, ou l’algorithmique est beaucoup plus poussée. Et ce sera ma conclusion : les différents paradigmes, comme les différents langage, ont chacun des domaine sou il sont plus ou moins forts. "mon langage(ou mon paradigme), c'est le meilleur", ça n'a aucun sens. "Dans tel contexte, tel langage est plus adapté"; c'est déjà beaucoup plus pertinent(et malgré tout debatable, mais au moins on parle d'un débat basé sur une réalité, pas sur des fantasmes).

Je ne vois pas le rapport. Personne n'a dit que le fonctionnel est le meilleur et doit être utilisé partout. De ce que j'ai compris de la news, c'est justement que l'objet est majoritaire mais intègre de plus en plus de features issues du fonctionnel et qu'on peut donc se demander pourquoi on n'utilise pas du fonctionnel dès le départ.

[GuAme]

Je ne vois pas le rapport. Personne n'a dit que le fonctionnel est le meilleur et doit être utilisé partout. De ce que j'ai compris de la news, c'est justement que l'objet est majoritaire mais intègre de plus en plus de features issues du fonctionnel et qu'on peut donc se demander pourquoi on n'utilise pas du fonctionnel dès le départ.

Peut-être par ce que c'est cet alliage objet-fonctionnel qui marche bien pour l'industrie, pas juste le fonctionnel.


Chacun a des capacité différentes d'appréhender ces différents paradigmes et j'ai l'impression (en bientôt 20 ans d'XP) que l'orienté objet, dans sa forme bâtarde majoritairement adoptée dans l'industrie, semble être le bon compromis pour organiser le code tout en restant (plus ou moins) maintenable par des devs de tout niveau.

Perso j'ai tout de suite compris les grandes lignes de l'objet quand j'étais à la fac, alors que les TP de LISP était un cauchemar pour moi. Par contre j'ai rapidement mis du "fonctionnel" dans mon Java avec des classe internes à la place des lambda.
Intellij était même capable de montrer une lambda à la place du code moche avant l'arrivée de Java 8. De même l'arrivée des 'stream' c'est faite en douceur et semble avoir été accepté par l'ensemble des dév.
Peu de non-universitaire ont vraiment envie de se coltiner les notions fonctionnelles les plus obscures, et souvent non pertinentes dans leur quotidien.

[el_slapper]

Désolé mais pour moi c'est juste un argument d'autorité qui ne veut rien dire. De plus Graham parle essentiellement de lisp, qui n'est qu'une partie du "fonctionnel moderne".

Certes, c'est une source de 2001, il ne risque pas de parler des progrès récents.

Je ne vois pas le rapport. Personne n'a dit que le fonctionnel est le meilleur et doit être utilisé partout. De ce que j'ai compris de la news, c'est justement que l'objet est majoritaire mais intègre de plus en plus de features issues du fonctionnel et qu'on peut donc se demander pourquoi on n'utilise pas du fonctionnel dès le départ.

Le troisième article de Paul Graham que j'ai lié répond en partie : la popularité appelle la popularité. Mais ce n'est qu'une partie de la réponse. GuAme, pour moi, cible juste pour tout le reste : le fonctionnel répond à certains besoins, mais pas à d'autres. J'en farcis moi-même parfois mon code(UFT, c'est-à-dire vbscript avec classes, je suis un dinosaure, ces temps-ci). Avoir aussi du fonctionnel dans un langage objet(ou procédural, ou mixte), c'est un plus fortement appréciable. Avoir un langage purement fonctionnel avec seulement de l'immutable, sur des applis de gestion, c'est vite le cauchemar. Surtout si ton recrutement n'est pas impeccable(et les besoins en personnel sont trop grands pour se contenter de la creme de la creme).

On utilise pas le fonctionnel dès le départ parce-que dans la plupart des cas, si on fait ça, on ne s'en sortira pas. On en rajoute avec parcimonie là ou on a absolument besoin de puissance algorithmique, et donc qu'on accepte de sacrifier en maintenabilité. C'est ça, le sous-jacent. La pureté du paradigme(peu importe le paradigme, d'ailleurs) est contre-productive, dans la plupart des cas.

[Invité]

On utilise pas le fonctionnel dès le départ parce-que dans la plupart des cas, si on fait ça, on ne s'en sortira pas. On en rajoute avec parcimonie là ou on a absolument besoin de puissance algorithmique, et donc qu'on accepte de sacrifier en maintenabilité. C'est ça, le sous-jacent. La pureté du paradigme(peu importe le paradigme, d'ailleurs) est contre-productive, dans la plupart des cas.

Tu as vraiment essayé sur des vrais projets ? L'article de la news cite un projet Erlang qui a réussi là où le projet C++ précédent avait échoué. L'article parle aussi de Elm, qui est réputé simplifier le dev d'appli web correcte (sans runtime exception). Et perso, à chaque fois que j'ai bossé avec de l'immutable, ça m'a semblé plus facile à maintenir et au final plus productif.

[VBurel]

Et la récursivité n'est ni fondamentale (on peut toujours s'en passer) ni fonctionnelle (il faut connaitre la taille de la stack et mettre en place des limitations qui s'impose pour éviter le stack overflow).

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

[Invité]

Et la récursivité n'est ni fondamentale (on peut toujours s'en passer)

Oui. Et les boucles non plus ne sont pas fondamentales car on peut les remplacer par... de la récursivité.

ni fonctionnelle (il faut connaitre la taille de la stack et mettre en place des limitations qui s'impose pour éviter le stack overflow).

Non. Généralement, on écrit la récursivité sous forme terminale et c'est aussi efficace qu'une boucle. https://fr.wikipedia.org/wiki/R%C3%A9cursion_terminale

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

[Gunny]

Ça va probablement faire mal à beaucoup mais le fonctionnel a connu un regain d'intérêt avec la montée en puissance de JavaScript, et le fait qu'il autorise du fonctionnel assez simplement et depuis sa naissance. Ça fait un moment que ça fait le buzz dans ce domaine. Douglas Crockford lors de ses conférences passionnantes sur ce langage en parlait déjà en 2010 : https://yuiblog.com/blog/2010/02/24/video-crockonjs-3/
Des bibliothèques JS comme underscore ou Lodash ont désormais 10 ans ou 7 ans d'ancienneté et étaient déjà tournées vers ce paradigme.

On crache souvent sur le javascript surtout ici mais peu ont conscience de cette capacité à porter certains progrès. Et vu que c'est probablement le langage le plus utilisé au monde...

Perso j'ai appris la récursivité en faisant du PERL il y a plus de 20 ans sur des systèmes unix (AIX en l’occurrence), et j'ai trouvé ça assez génial. Je n'avais absolument pas idée que c'était assez fondamental du fonctionnel.
J'ai depuis ce moment toujours utilisé ce type d'algo quand je le pouvais, et je me foutais bien du fonctionnel ou non. Le problème majeur est que le résultat est craché à la dernière itération, à la sortie de la récursion, et il y a 20 ans c'était drôlement sensible, surtout sur des systèmes partagés. C'est juste simple et évident à écrire

Quand à cette époque j'ai appris (ou abordé plutôt) les 3 paradigmes évoqués, via 3 ou 4 langages (VB pour le procédural, PERL et javascript autorisant le fonctionnel, java pour l'objet) l'objet m'a semblé le moins naturel tel qu'il se présente en java. Le fonctionnel a un coté naturel, comme l'impératif ou le procédural.
La programmation objet pure pose des problèmes d'organisation mentale basique que ne pose pas les autres paradigmes : Où je mets mes méthodes ? A quel objet ou classe quand ces méthodes peuvent justement s'appliquer à plusieurs. Parfois ça peut paraitre évident, parfois absolument pas

Bon le fait d'avoir écrit JS va surement m'attirer beaucoup de critiques, mais que je crois que la réalité est là, et que cela part de la popularité de ce langage, dans le monde anglo-saxon évidemment.

+1 pour JS. Il n'y a même pas besoin de creuser bien profond pour exploiter ses capacités de programmation fonctionnelle, mais elles sont souvent complètement passées sous silence. C'est à mon sens une très grosse erreur car il est impossible de bien comprendre JS sans comprendre ces principes, ce qui vaut souvent à JS une sale réputation. De plus, contrairement à beaucoup de langages fonctionnels "niches", un code fonctionnel écrit en Javascript n'est pas plus difficile à lire qu'un code OO dans un autre langage.

D'ailleurs, c'est assez rigolo de voir que tous les langages populaires se tournent vers un mélange de fonctionnel et OO : là où par exemple C# ajoute des capacités fonctionnelles, JS ajoute des capacités OO. Cela me semble une évolution logique car cela apporte le meilleur des 2 mondes : un code et une architecture globalement OO traditionnels et facilement compréhensibles, avec la puissance du fonctionnel pour certaines opérations. On en arrive à mon sens à un code qui est supérieur au pur OO ou pur fonctionnel.

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

[el_slapper]

+(.../...)D'ailleurs, c'est assez rigolo de voir que tous les langages populaires se tournent vers un mélange de fonctionnel et OO : là où par exemple C# ajoute des capacités fonctionnelles, JS ajoute des capacités OO. Cela me semble une évolution logique car cela apporte le meilleur des 2 mondes : un code et une architecture globalement OO traditionnels et facilement compréhensibles, avec la puissance du fonctionnel pour certaines opérations. On en arrive à mon sens à un code qui est supérieur au pur OO ou pur fonctionnel.

Ou que du pur procédural. 95% des codes que j'ai écrits en COBOL n'auraient pas été "mieux" en objet ou en fonctionnel. Et puis il y a eu les cygnes noirs, ces 3/4 algorithmes très compliqués, pas nombreux, mais clefs du projet à chaque fois. Bon, ben en procédural(qui plus est sans collections, donc tout stocké sous forme de tableaux de taille fixe), j''ai du me résoudre à pondre des horreurs. Avec des boucles imbriquées dans des boucles elles mêmes....... D'ailleurs, pour l'un d'entre eux, j'ai fait après coup une doc technique complète, détaillant l'algo dans ces moindres détails(ce que je ne fais jamais, d'habitude, normalement mes codes sont assez clairs), et j'ai dit à mes successeurs : "si par malheur vous avez une maintenance à faire, vous mettes mon code à la poubelle, et vous recommencez en partant de cette spec que vous adaptez au nouveau besoin". Faire de la logique ensembliste en procédural pur, c'est, euh, contre-nature, pour rester poli.

Tout ça pour dire qu'on a besoin de tous les paradigmes(il y a presque toujours un peu de procédural qui se loge en objet - c'est plus rare en fonctionnel, mais ça arrive, cf la référence à des variables mutables pour le vrai quicksort ci-dessus). Suivant le besoin, plus de l'un ou plus de l'autre. Le mélange objet-procédural qu'on trouve en Java(qui est assez loin de l'idéal tout objet des puristes, malgré ses prétentions) fait souvent le boulot pour des applis pas très futées, qui sont le lot général en informatique de gestion. Et le fonctionnel peut poser des problèmes de performances, si il n'est pas parfaitement maîtrisé. enfin, l'objet aussi.

Anecdote sur la performance(qui a pas loin de dix ans). Une grosse boite d'assurances vie(3000 personnes, un million de clients) décide de passer son vieux référentiel contrats - en COBOL - sur JAVA pour être modernes. 5 ans et 100 M€ plus tard, 5% des contrats sont passés sur JAVA. Décision est prise de s'arrêter là malgré la modernisation évidente de l'interface des agents. La raison? Les traitements comptables de fin d'année. Il fallait 6 heures au COBOL pour passer l'un d'entre eux, il fallait 6 jours au JAVA pour faire pareil. Sur 5% de la volumétrie. Faites le calcul.

Alors je sais ce qu'on va me dire "ils n'ont pas fait leur boulot - ils ont été nuls", ce qui est certainement vrai. Mais l'objet est plus difficile que le procédural(tant qu'on ne fait pas d'algo compliqué, et là, il n'y en avait pas, juste des traitements massifs de chez massifs), et le fonctionnel encore plus difficile. Et ces gens-là ont recruté qui ils ont trouvé sur le marché parisien. Et les gens recrutés jadis pour faire du COBOL avaient réussi à faire un truc à peu près performant. Les gens recrutés pour faire du JAVA - dont je n'ai aucune raison de penser qu'ils étaient par essence moins bons - n'ont pas réussi à faire un truc qui marche et qui soit d'une performance acceptable. Sur des machines de compèt'(pour l'époque). Je n'ose imaginer ce que ça aurait donné en fonctionnel avec le même niveau de base. Et, en même temps, il y a eu des situations ou j'ai regretté de ne pas avoir d'objet - voire de fonctionnel - sous la main. Ce n'est pas un sujet simple.

[fredoche]

je vois pas en quoi le fonctionnel pèserait sur la performance ?

Franchement tant pour le sujet que tu évoques que d'une façon générale, il est souvent question d'architecture logicielle, et dans le monde qui est le notre, on bosse avec des systèmes hétérogènes et les solutions sont multiples. Et un langage n'est bien souvent qu'un outil d'exécution au milieu de beaucoup d'autres.

Tous ces débats me paraissent surannés. Ça fait 20 ans que je fais de l'appli web, j'ai toujours eu des SGBD(R), des serveurs web, du réseau, des navigateurs, de la programmation front et backend. Le langage là-dedans intervient à quelques endroits, mais bon... La réelle valeur ajoutée d'un bon développeur c'est de faire faire le job au bon stack (on disait tiers avant) pour lequel celui-ci est bien adapté.

Et dans ce que tu évoques, faire de l'opération ensembliste, c'est juste évident que je le ferais dans mon SGBD, et que si je dois de toute façon en faire, il me faut un SGBD. Je ne pourrais jamais être aussi performant de manière programmatique que d'utiliser ce service qui est optimisé pour ça. Pour des outils que je connais comme SQL server, c'est 25 ans d'optimisation par des dizaines voir des centaines d'ingénieurs.

C'est comme ces gens que je vois faire du serveur web avec Node parce qu'il peut le faire, juste pour servir du ficher statique, au milieu de tout ce que tu peux avoir à router. Utiliser un NGINX en parallèle, qui est développé depuis 15 ans pour ça, qui est tout aussi asynchrone, c'est vraiment se faciliter la vie.

Bien faire son métier ce n'est pas coder comme un forcené, mais être astucieux autant que possible, et avoir une vision d'ensemble, une vision architecturale.

Peut-être que l'architecture est contrainte pour ce que tu évoques en COBOL... Mais je crois que je connais assez bien la problématique des (grands) projets informatiques à la française, et vu la publicité des réussites de ces dernières années, plus moi ce que j'ai pu voir dans mon propre parcours pro, je finis par avoir quelques intuitions sur le pourquoi du comment de beaucoup d'échecs.

Après quel que soit le langage, et la mise en forme adoptée (fonctionnel, objet, procédural), on arrive toujours à exprimer des idées, ou des traitements. C'est comme pour les langages humains, il existe des milliers de langues sur Terre, des centaines sous forme écrite, et ça n'empêche pas Tintin et Astérix d'être publié dans plusieurs dizaines d'entre elles, et de faire passer les mêmes messages.