Car tous ces avantages sont aussi des inconvénients.
Programmes apatrides ; pas d'effets secondaires
Les programmes du monde réel ne connaissent que des effets secondaires et des mutations. Lorsque l'utilisateur appuie sur un bouton, c'est parce qu'il veut que quelque chose se produise. Lorsqu'il tape quelque chose, il veut que cet état remplace celui qui existait auparavant. Lorsque Jane Smith, comptable, se marie et change son nom en Jane Jones, la base de données qui soutient le processus métier qui imprime son chèque de paie a intérêt à pouvoir gérer ce type de mutation. Lorsque vous tirez avec la mitrailleuse sur l'extraterrestre, la plupart des gens ne modélisent pas mentalement cela comme la construction d'un nouvel extraterrestre avec moins de points de vie ; ils modélisent cela comme une mutation des propriétés d'un extraterrestre existant.
Lorsque les concepts du langage de programmation vont fondamentalement à l'encontre du domaine à modéliser, il est difficile de justifier l'utilisation de ce langage.
Concurrence ; joue très bien avec la technologie multi-core en plein essor.
Le problème est simplement repoussé. Avec des structures de données immuables, vous avez une sécurité de thread bon marché au prix d'un travail possible avec des données périmées. Avec des structures de données mutables, vous avez l'avantage de toujours travailler sur des données fraîches au prix de devoir écrire une logique compliquée pour garder les données cohérentes. Ce n'est pas comme si l'une d'entre elles était manifestement meilleure que l'autre.
Les programmes sont généralement plus courts et, dans certains cas, plus faciles à lire.
Sauf dans les cas où ils sont plus longs et plus difficiles à lire. Apprendre à lire des programmes écrits dans un style fonctionnel est une compétence difficile ; les gens semblent bien plus aptes à concevoir les programmes comme une série d'étapes à suivre, comme une recette, plutôt que comme une série de calculs à effectuer.
La productivité augmente (exemple : Erlang)
La productivité doit augmenter considérablement pour justifier les dépenses massives liées à l'embauche de programmeurs qui savent programmer dans un style fonctionnel.
Et n'oubliez pas que vous ne voulez pas jeter un système qui fonctionne ; la plupart des programmeurs ne construisent pas de nouveaux systèmes à partir de zéro, mais assurent plutôt la maintenance de systèmes existants, dont la plupart ont été construits dans des langages non fonctionnels. Imaginez que vous deviez justifier cela auprès des actionnaires. Pourquoi avez-vous mis au rebut votre système de paie existant et fonctionnel pour en construire un nouveau, au prix de millions de dollars ? "Parce que la programmation fonctionnelle est géniale" a peu de chances de ravir les actionnaires.
La programmation impérative est un paradigme très ancien (pour autant que je sache) et peut-être pas adapté au 21ème siècle.
La programmation fonctionnelle est également très ancienne. Je ne vois pas en quoi l'ancienneté du concept est pertinente.
Ne vous méprenez pas. J'aime la programmation fonctionnelle, j'ai rejoint cette équipe parce que je voulais aider à introduire les concepts de la programmation fonctionnelle dans C#, et je pense que la programmation dans un style immuable est la voie de l'avenir. Mais il y a coûts énormes à la programmation dans un style fonctionnel qu'on ne peut pas simplement souhaiter. L'évolution vers un style plus fonctionnel va se faire lentement et progressivement sur plusieurs décennies. Et c'est ce qu'il sera : une évolution vers un style plus fonctionnel, et non pas une adoption en bloc de la pureté et de la beauté de Haskell et l'abandon de C++.
Je construis des compilateurs pour gagner ma vie et nous adoptons définitivement un style fonctionnel pour la prochaine génération d'outils de compilation. La raison en est que la programmation fonctionnelle est fondamentalement adaptée au type de problèmes auxquels nous sommes confrontés. Nos problèmes consistent à prendre des informations brutes - chaînes de caractères et métadonnées - et à les transformer en chaînes de caractères et métadonnées différentes. Dans les situations où des mutations se produisent, comme lorsque quelqu'un tape dans l'IDE, l'espace du problème se prête intrinsèquement à des techniques fonctionnelles telles que la reconstruction incrémentale des seules parties de l'arbre qui ont changé. De nombreux domaines ne possèdent pas ces belles propriétés qui les rendent manifestement accessibles à un style fonctionnel. .
