Blog

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 »

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.