Je suis un programmeur orienté objet et j'ai hâte d'apprendre un langage fonctionnel. Mes questions sont les suivantes :
Quand choisir la programmation fonctionnelle plutôt que la programmation orientée objet ?
Lorsque vous anticipez un autre type d'évolution du logiciel :
Les langages orientés objet sont bons lorsque vous avez un ensemble fixe de opérations sur choses et au fur et à mesure que votre code évolue, vous ajoutez principalement de nouvelles choses. Cela peut se faire en ajoutant de nouvelles classes qui implémentent des méthodes existantes, et les classes existantes sont laissées tranquilles.
Les langages fonctionnels sont bons quand vous avez un ensemble fixe de choses et, au fur et à mesure de l'évolution de votre code, vous ajoutez principalement de nouvelles opérations sur les choses existantes. Cela peut être accompli en ajoutant de nouvelles fonctions qui calculent avec les types de données existants, et les fonctions existantes sont laissées tranquilles.
Quand l'évolution va dans le mauvais sens, vous avez des problèmes :
L'ajout d'une nouvelle opération à un programme orienté objet peut nécessiter la modification de nombreuses définitions de classes pour ajouter une nouvelle méthode.
L'ajout d'un nouveau type de chose dans un programme fonctionnel peut nécessiter la modification de nombreuses définitions de fonctions pour ajouter un nouveau cas.
Ce problème est bien connu depuis de nombreuses années ; en 1998, Phil Wadler l'a surnommé le "problème d'expression". . Bien que certains chercheurs pensent que le problème de l'expression peut être résolu grâce à des fonctionnalités du langage telles que les mixins, une solution largement acceptée n'a pas encore fait son chemin.
Quelles sont les définitions de problèmes typiques pour lesquels la programmation fonctionnelle est un meilleur choix ?
Les langages fonctionnels excellent dans la manipulation de données symboliques sous forme d'arbre. Un exemple favori est celui des compilateurs, où les langages source et intermédiaire changent rarement (la plupart du temps, ce sont les mêmes choses ), mais les auteurs de compilateurs ajoutent toujours de nouvelles traductions et des améliorations ou optimisations du code (nouvelles opérations sur les choses). La compilation et la traduction plus généralement sont des "killer apps" pour les langages fonctionnels.
Vous n'avez pas nécessairement à choisir entre les deux paradigmes. Vous pouvez écrire des logiciels avec une architecture OO en utilisant de nombreux concepts fonctionnels. La PF et la POO sont de nature orthogonale .
Prenez par exemple le C#. On pourrait dire qu'il s'agit principalement de POO, mais il existe de nombreux concepts et constructions de PF. Si vous considérez Linq Les constructions les plus importantes qui permettent à Linq d'exister sont de nature fonctionnelle : expressions lambda .
Un autre exemple, F#. On pourrait dire qu'il s'agit principalement de FP, mais il y a de nombreux concepts et constructions de POO disponibles. Vous pouvez définir des classes, des classes abstraites, des interfaces, gérer l'héritage. Vous pouvez même utiliser la mutabilité lorsque cela rend votre code plus clair ou lorsque cela augmente considérablement les performances.
De nombreuses langues modernes sont multi-paradigmes.
Comme je suis dans le même bateau (formation OOP, apprentissage de la FP), je vous suggère quelques lectures que j'ai vraiment appréciées :
Programmation fonctionnelle pour le développement .NET au quotidien par Jeremy Miller. Un excellent article (bien que mal formaté) montrant de nombreuses techniques et des exemples pratiques et concrets de la PF sur C#.
La programmation fonctionnelle dans le monde réel par Tomas Petricek. Un excellent livre qui traite principalement des concepts de la PF, en essayant d'expliquer ce qu'ils sont, quand ils doivent être utilisés. Il y a de nombreux exemples en F# et en C#. Également, Le blog de Petricek est une excellente source d'information.
Les offres de programmation orientée objet :
La programmation fonctionnelle, en Haskell ou même en Scala, peut permettre la substitution grâce à un mécanisme plus général de classes de types. L'état interne mutable est soit découragé, soit interdit. L'encapsulation de la représentation interne peut également être réalisée. Voir Haskell et la POO pour une bonne comparaison.
L'affirmation de Norman selon laquelle "l'ajout d'un nouveau type de chose dans un programme fonctionnel peut nécessiter la modification de nombreuses définitions de fonctions pour ajouter un nouveau cas" dépend de la manière dont le code fonctionnel a utilisé les classes de types. Si le filtrage sur un type de données abstrait particulier est répandu dans toute la base de code, vous souffrirez effectivement de ce problème, mais il s'agit peut-être d'une mauvaise conception au départ.
EDITED Suppression de la référence aux conversions implicites lors de la discussion sur les classes de types. En Scala, les classes de types sont codées avec des paramètres implicites, et non avec des conversions, bien que les conversions implicites soient un autre moyen de réaliser la substitution de types compatibles.
Si vous êtes dans un environnement fortement concurrent, la programmation fonctionnelle pure est utile. L'absence d'état mutable rend la concurrence presque triviale. Voir Erlang.
Dans un langage multiparadigme, vous pouvez vouloir modéliser certaines choses fonctionnellement si l'existence d'un état mutable doit être un détail d'implémentation, et donc si FP est un bon modèle pour le domaine du problème. Par exemple, voir les compréhensions de liste en Python ou std.range dans le langage de programmation D. Elles s'inspirent de la programmation fonctionnelle.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
