IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pourquoi la programmation fonctionnelle n'est-elle pas la norme de l'industrie du code ? L'auteur de « Elm in action » s'exprime
« c'est une question de temps avant que la POO soit détrônée »

Le , par Patrick Ruiz

382PARTAGES

9  0 
Il existe une panoplie de manières d’aborder la programmation informatique. Dans le jargon du milieu, on parle de paradigme de programmation. En incluant celui dit impératif, on répertorie à minima trois grandes familles et leurs dérivés. Certaines de ces approches font quasiment office de norme dans l’actuelle industrie de la programmation informatique. C’est par exemple le cas de la programmation orientée objet dont on a appris qu’elle permet d’améliorer l’organisation des bases de code procédurales.

Toutefois, Richard Feldman est d’avis que « l’on est quelque part au milieu d’une transition du style programmation orientée objet vers celui dit fonctionnel. » « Des langages de programmation comme Kotlin prennent à la fois la programmation orientée objet et celle dite fonctionnelle en charge. C’est quelque chose que vous n’auriez pas vu dans une FAQ du langage Java dans les années ‘90. En fait, de plus en plus de langages mettent en avant le support du style fonctionnel en avant comme argument de vente. Les développements en cours laissent penser que de plus en plus d’acteurs de la filière sont d’accord que l’approche fonctionnelle est bonne », ajoute-t-il.

Il y a quelques mois, l’étude « Emploi développeur 2018 » est parue sur cette plateforme. En tête de liste des langages les plus demandés et les mieux payés, on retrouve Java. Sa première présentation officielle s’est faite le 23 mai 1995 au SunWorld comme langage de programmation structuré, impératif et orientée objet. C’est Java 8 (sorti en 2014) qui est venu mettre les développeurs qui font usage de ce langage de programmation sur les rails du style fonctionnel au travers des expressions lambdas. En fait, la remarque de Feldman vaut pour bon nombre de langages de cette enquête dvp pour lesquels on note que de plus en plus de livres orientés programmation fonctionnelle paraissent.


« C’est le signe que quelque chose a changé des années ‘90 à nos jours. L’approche fonctionnelle attire de plus en plus d’acteurs de la filière. Ce n’est plus qu’une question de temps pour la voir s’imposer », conclut Feldman.

La montée en puissance de langages de programmation pour le web comme Elm au travers de bibliothèques comme Elm-ui pourrait accélérer la transition entrevue. Cela permettrait de lister la programmation d’interfaces utilisateur comme domaine « phare » d’un langage à paradigme fonctionnel. En sus, des facteurs additionnels comme le fait pour certaines plateformes de réserver l’exclusivité à des langages de programmation à paradigme fonctionnel pourraient contribuer à poser le tableau tel que vu par Feldman. Ceci c’est sans prise en compte d’ingrédients comme le marketing autour des solutions proposées. Il s’agit là d’une liste non exhaustive d’atouts que l’approche fonctionnelle ne réunit pas à date, mais qui a contribué à propulser l’approche orientée objet. Sur l’axe de l’exclusivité de la plateforme, il n’y a qu’a voir avec C# dont on peut penser que son lancement était destiné à attirer des développeurs Java. Enfin, comment oublier la campagne à 500 millions de dollars que Sun a mise sur pied en 2003 pour la promotion de Java.


La sortie de Richard Feldman n’est pas sans faire penser à des développements antérieurs qui suggèrent de passer à l’approche fonctionnelle.

En effet, à mi-parcours de l’année qui tire à son terme, Ilya Suzdalnitski de l’entreprise Replicon affirmait que « considérer la programmation orientée objet comme standard de l’industrie pour l’organisation des bases de code est, pour lui, une grosse erreur. » Son développement laissait filtrer que l’usage de la programmation orientée objet dévie l’attention des développeurs de ce qui doit la retenir : la résolution des problèmes. « L’approche orientée objet introduit plus de complexité que l’inverse surtout pour des bases de code importantes », avait-il souligné avant d’ajouter qu’ « il est difficile d’écrire du code orienté objet aisé à maintenir, les tests unitaires sont difficiles à appliquer à une base de code montée suivant l’approche orientée objet, le refactoring de code est une vraie galère sans des outils comme Resharper. »

L’ingénieur de Replicon avait insisté sur ceci que la racine des maux avec la POO telle que pratiquée via des langages comme Java ou C# est qu’elle n’est pas implémentée telle qu’Alan Kay l’a conçue. « On n’aurait jamais dû parler de concepts comme l’héritage, le polymorphisme ou avoir à traiter avec une myriade de patrons de conception », avait-il souligné. Ilya Suzdalnitski accusait les langages phares du moment de mettre en avant une POO qui ne s’aligne pas sur la définition originelle de l’encapsulation et sur la communication par messages entre programmes indépendants.

« En Erlang, on pratique la programmation orientée objet sous sa forme la plus pure. À l’inverse des langages de programmation phares, Erlang s’appuie sur l’idée centrale de la POO – les messages. Dans ce langage, les objets communiquent via des messages immuables », avait-il indiqué.

Au travers de cet exemple, l’ingénieur de Replicon suggérait que programmation fonctionnelle et programmation orientée objet « pure » sont une seule et même chose. En droite ligne avec ce détail, il avait surtout mis en avant la supériorité de la programmation fonctionnelle vis-à-vis de la POO telle que pratiquée avec Java, C#, C++ et autres.

« Le but ultime de tout développeur de logiciel devrait être d'écrire du code fiable. Rien d'autre n'a d'importance si le code est bogué et peu fiable. Et quelle est la meilleure façon d'écrire un code fiable ? Simplicité. La simplicité est le contraire de la complexité. Erlang est probablement le langage le plus fiable au monde. La majeure partie de l'infrastructure mondiale des télécommunications (et donc de l'Internet) s'appuie sur ce dernier. Certains des systèmes écrits en Erlang ont une fiabilité de 99.999999999 % », avait-il insisté.


Dans sa présentation, Feldman rappelle qu’il a travaillé sur plusieurs projets en s’appuyant sur l’approche orientée objet avant de passer à l’approche fonctionnelle. Depuis des années qu’il pratique cette dernière, il l’a trouvée intéressante, ce qui l’a amené à se poser la question de savoir pourquoi l’industrie continue de faire usage de l’approche orientée objet.

Source : video

Et vous ?

Partagez-vous l’avis selon lequel l’approche fonctionnelle finira par s’imposer comme norme ?
Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
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 ?

Voir aussi :

La programmation orientée-objet est-elle dépassée ? Une école en sciences informatiques l'élimine de son programme d'introduction
Faut-il éviter de distraire les débutants avec l'orientée objet ?
Comment pourriez-vous expliquer l'orienté objet ? Steve Jobs a essayé d'expliquer ce concept

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 05/12/2019 à 14:20
Citation Envoyé par Neckara Voir le message
Rhôoo, mais vous avez un jour d'avance.

Tout ce perd ma p'tite dame, les traditions, c'est plus c'que c'était.
Pour faire presque aussi trollesque : la programmation fonctionnelle ne s'est jamais imposée parce-que c'est une bouse illisible par quiconque n'est pas son auteur.

C'est triste parce-que c'est quand même carrément puissant, comme paradigme de programmation. Mais il faut une agilité intellectuelle exceptionnelle(ainsi qu'un entrainement spécifique) pour arriver à en tirer la substance. C'est bien plus exigeant que l'objet ou le procédural. Le programmeur moyen n'est pas armé pour faire face à un code en fonctionnel - alors qu'il peut être productif dans les autres paradigmes. C'est pourquoi la programmation fonctionnelle est vouée à rester une niche. Une niche surpuissante, mais une niche quand même. C'est bien d'avoir du fonctionnel en natif dans un langage - mais ça ne servira pas à la majorité.
20  1 
Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 11/12/2019 à 17:13
(Note: je vais rester totalement neutre dans ce post pour éviter d'enflammer inutilement le conflit)

@Neckara, @SimonDecoline
Franchement, votre discussion commence à tourner en dialogue de sourd. Je sais que chacun à le droit de défendre sa position mais je pense que vu à quel point la discussion a divergé, il serait plus préférable de la continuer dans un autre fil de discussion ou en privé.

Comme dans n'importe quel débat, vous pouvez ne pas être d'accord avec votre interlocuteur mais si vous voulez le convaincre, essayez d'être bienveillant avec lui. Évitez ce qui peut s'apparenter à des attaques personnelles, ça va juste le braquer. Personnellement quand j'ai une critique à formuler, j'essaye d'insister aussi sur les points ou je suis d'accord, en général ça permet de garder un débat apaisé et enrichissant pour tout le monde.

Bref, nous sommes sur internet et nous n'avons rien à vendre donc rien à gagner à imposer notre point de vue à des "inconnus". La seule chose à gagner ici c'est d'apprendre des choses. Donc à nous de tout faire pour améliorer les niveaux de la conversation. Ne répondons pas aux provocations.

(Note: je suis désolé si ce message peut paraître "Bisounours", mais j'espère qu'il peut recentrer le débat sur le sujet originel )

Je ne veux pas lancer un nouveau /hs, merci de ne pas répondre à ce message mais plutôt au sujet originel de ce thread!
11  0 
Avatar de Neckara
Inactif https://www.developpez.com
Le 05/12/2019 à 11:26
Rhôoo, mais vous avez un jour d'avance.

Tout ce perd ma p'tite dame, les traditions, c'est plus c'que c'était.
10  1 
Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 05/12/2019 à 14:29
Citation Envoyé par Patrick Ruiz
Certains des systèmes écrits en Erlang ont une fiabilité de 99.999999999 %

J'ai ri.

C'est quoi le 0.000000001%? Qu'on se trompe en disant c'est sur à 100%? Que le stagiaire renverse du café sur le serveur? Que Windows Update force un démarrage?

Voici un code sur à 99.999999999 %. Enfin, comme l'auteur, je donne ce chiffre à la louche, hein?
Code c : Sélectionner tout
1
2
3
4
5
  
int main() { 
    printf("Wow, ce programme est vraiment fiable.\n"); 
    return 0; 
}

Tout ça pour dire, une fiabilité "tout court" ça n'a aucun sens.
9  1 
Avatar de
https://www.developpez.com
Le 10/12/2019 à 18:05
Citation Envoyé par Neckara Voir le message
J'ai envie de dire oui, mais non. C'est mon côté enculeur de mouche.
....
Désolé mais tout ça c'est de la rhétorique. Les performances de pytorch/tensorflow viennent de la partie C++, point. Citer ces libs pour justifier que "python peut être performant", c'est juste malhonnête. Sinon autant dire que C++ est facile d'utilisation parce c'est facile d'écrire un script python qui utilise pytorch/tensorflow...
9  1 
Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 10/12/2019 à 17:13
Citation Envoyé par neckara
C'est ce que j'aurais pensé il y a encore quelques jours, mais Python peut faire des calculs sur GPU avec PyTorch/TensorFlow de manière très très intelligente.
Sans aller jusqu'à du calcul sur GPU, numpy peut aussi être très intelligent si bien installé. Pour obtenir des performances similaires en C/C++ tout en gardant un code portable... il faut utiliser des bibliothèques dédiées.
Pour les Pytorch/Tensorflow toutes les opérations nécessitant de la performance sont écrites en C++, le python est juste là sous forme de surcouche (binding) pour que ces frameworks soient utilisables facilement. Du coup certes tu utilises du Python, mais une bonne partie des calculs sont faits dans un langage "rapide" en interne.

Ceci dit, je te rejoins complétement quand tu dis que l'algo peut être plus important que le langage: un bon code python peut être plus rapide qu'un mauvais code c++.
7  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 06/12/2019 à 10:03
Citation Envoyé par Sebajuste Voir le message
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.
6  0 
Avatar de
https://www.developpez.com
Le 06/12/2019 à 12:02
Citation Envoyé par sacdebille Voir le message
Oui il y a 30 ans les universitaires nous ont déjà fait le coup avec un CAML puis 10 ans plus tard avec OCAML. Et ce langage est resté prospérer dans le monde des universitaires qui n'ont jamais développé d'appli.
Pas du tout.
Ocaml a directement inspiré F# (https://en.wikipedia.org/wiki/F_Shar...ming_language)).
Ocaml a directement inspiré Reasonml (https://reasonml.github.io/).
Ocaml est utilisé de façon non-négligeable dans la finance (https://www.janestreet.com/technology/).
Ocaml est utilisé de façon non-négligeable chez facebook (https://github.com/facebook?utf8=%E2...language=ocaml).
etc
7  1 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 10/12/2019 à 9:52
Citation Envoyé par Gunny Voir le message
+(.../...)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.
7  1 
Avatar de iclo
Membre régulier https://www.developpez.com
Le 05/12/2019 à 16:49
Le gros problème de la programmation massivement fonctionnelle c'est en effet qu'elle est difficilement lisible si on essaie de généraliser son emploi : on arrive quand même assez vite à des trucs qui sont en effet écris sur une seule ligne de code au lieu de 3 mais qui vont demander 5 fois plus de temps au développeur lamba pour comprendre ce qu'on fait.

Certains de mes profs de Master se voulaient grands gourou du fonctionnel, avec des langages de programmation comme Oz : merveilleux selon eux mais utilisés par personne ou presque en dehors de la sphère universitaire où la notion de coûts de maintenabilité est une notion abstraite et très très lointaine.

Au final, les "chercheurs" peuvent inventer tout ce qu'ils veulent, c'est quand même l'industrie qui fera de leurs idée des succès ou des flops retentissants.
5  0