Pourquoi l'enthousiasme actuel pour la programmation fonctionnelle? [fermé]

J'ai récemment entendu beaucoup d'enthousiasme pour les langages de programmation fonctionnels, notamment Scala, Clojure et F #. J'ai récemment commencé à étudier Haskell, pour apprendre le paradigme de la PF.

Je l'aime, c'est vraiment amusant et correspond à mes antécédents en mathématiques.

Mais cela importera-t-il vraiment? De toute évidence, ce n'est pas une idée nouvelle.

Voici mes questions:

1. Qu'est-ce qui a contribué à l'enthousiasme récent de la PF? Est-ce simplement de l'ennui avec OO ou est-ce que quelque chose a changé pour rendre la PF plus nécessaire qu'auparavant?
2. Cela indique-t-il un avenir de PF? Ou est-ce une lubie, comme des bases de données orientées objet?

En d'autres termes, quelqu'un peut-il m'aider à comprendre d'où cela vient et où cela pourrait aller?

Les monades sont l'une des innovations majeures de la PF qui ont entraîné "l'explosion" de l'intérêt.

En janvier 1992, Philip Wadler a écrit un article intitulé « L’essence de la programmation fonctionnelle» qui introduisait les monades dans la programmation fonctionnelle en tant que moyen de traiter les entrées-sorties.

Le problème majeur des langages de programmation fonctionnels purs, paresseux était l’utilité de traiter avec les E / S. C’est l’un des membres de la «formation maladroite» dans la programmation, car «la paresse et les effets secondaires sont, d’un point de vue pratique, incompatibles. Si vous voulez utiliser un langage paresseux, il doit s’agir d’un langage purement fonctionnel; si vous voulez utiliser des effets secondaires, vous feriez mieux d'utiliser un langage strict. " Référence

Le problème avec IO avant les monades était que le maintien de la pureté n'était pas possible pour les programmes réellement utiles. Par IO, nous entendons tout ce qui concerne les changements d'état, y compris les entrées et les sorties de l'utilisateur ou de l'environnement. En programmation fonctionnelle pure, tout est immuable, pour permettre la paresse et la pureté (sans effets secondaires).

Comment les monades résolvent-elles le problème de l'IO? Eh bien, sans trop parler des monades, elles prennent essentiellement le "Monde" (l'environnement d'exécution) en entrée de la monade et produisent un nouveau "Monde" en sortie, ainsi que le résultat: tapez IO a = World -> (a, Monde).

La PF est donc entrée de plus en plus dans le grand public, car le plus gros problème, IO (et d'autres), a été résolu. L'intégration dans les langages OO existants s'est également produite, comme vous le savez. LINQ, ce sont des monades, par exemple, de part en part.

Pour plus d'informations, je vous recommande de lire sur les monades et les documents référencés dans ma réponse.

L' un des principaux problèmes lors des langages de programmation traditionnels comme C, Java, C #, assembleur , etc. est que vous avez une délicate séquence des étapes que vous devez prendre pour accomplir une tâche donnée parce que vous devez avoir préparé toutes les dépendances d' abord et LEURS dépendances plus tôt

Un exemple: pour faire A, vous devez avoir B et C présents, et B dépend de D et E, ce qui donne quelque chose comme:

• ré
• E
• C
• B
• UNE

parce que vous devez avoir préparé les ingrédients avant de pouvoir les utiliser.

Les langages fonctionnels, en particulier les paresseux, renversent celui-ci. En laissant A dire qu'il a besoin de B et C, et en laissant à l'exécution du langage le soin de déterminer quand obtenir B et C (ce qui nécessite à son tour D et E), qui sont tous évalués lorsque cela est nécessaire pour évaluer A, vous pouvez créer des tâches très petites et concises. blocs de construction, qui se traduisent par des programmes petits et concis. Les langages paresseux permettent également d'utiliser des listes infinies car seuls les éléments réellement utilisés sont calculés, sans qu'il soit nécessaire de stocker la totalité de la structure de données en mémoire avant de pouvoir l'utiliser.

Le truc vraiment sympa, c’est que ce mécanisme automatique "oh, j’ai besoin d’un mécanisme B et C" est évolutif car il n’ya pas de restriction - comme dans le programme séquentiel - concernant le lieu et le moment où cette évaluation peut avoir lieu. même temps et même sur différents processeurs ou ordinateurs.

C’est pourquoi les langages fonctionnels sont intéressants, car le mécanisme "quoi faire quand" est pris en charge par le système d’exécution, contrairement au programmeur qui doit le faire manuellement. Cette différence est aussi importante que la récupération de place automatique fonctionnait pour Java en C, et l’une des principales raisons pour lesquelles il est plus facile d’écrire un logiciel multithread robuste et évolutif en Java qu’en C. Logiciel multi-thread évolutif en langages fonctionnels ...

À la fin des années 80 et au début des années 90, les ordinateurs sont devenus assez puissants pour la POO de style Smalltalk. De nos jours, les ordinateurs sont assez puissants pour la PF. La FP est programmée à un niveau supérieur et donc souvent - bien que plus agréable à programmer - ce n’est pas la manière la plus efficace de résoudre un problème donné. Mais les ordinateurs sont si rapides que vous ne vous en souciez pas.

La programmation multi-cœur peut être plus facile avec des langages de programmation purement fonctionnels, car vous êtes obligé d'isoler le code changeant d'état.

De plus, les frontières du langage de programmation sont floues aujourd'hui. Vous n'êtes pas obligé d'abandonner un paradigme si vous souhaitez en utiliser un autre. Vous pouvez pratiquer la PF dans la plupart des langues populaires, de sorte que la barrière d’entrée est faible.

De nos jours, besoin d'informatique distribuée.

FP utilise des fonctions en tant que blocs de construction, qui n'ont pas d'état. Par conséquent, leur appel n fois avec les mêmes paramètres devrait toujours renvoyer la même valeur, ils n'ont pas d'effets secondaires.

Ainsi, vous pouvez envoyer la même fonction à plusieurs machines à exécuter et effectuer le travail en parallèle.

Dans le paradigme OO, cela est un peu plus difficile, car les blocs de construction sont des objets, qui sont presque par définition avec état. Si vous appelez plusieurs fois la même méthode, vous devez être prudent dans la synchronisation des données internes afin d'éviter toute corruption des données. Bien qu'il soit encore possible, le paradigme de la PF fonctionne mieux que l'OO dans certains scénarios où le calcul doit être distribué.

L'avènement de FP (et de NoSQL dans une certaine mesure) vient après les histoires sur des résultats informatiques étonnants: des centaines de milliers d'ordinateurs travaillant en parallèle, et à quel point c'est facile.

Mais ce n’est probablement qu’un créneau du genre d’applications nécessitant ce type d’installation. Pour beaucoup, beaucoup d'autres applications / systèmes, procédures et procédures OO fonctionnent parfaitement.

Il est donc tout à fait sur le point d'élargir nos horizons de programmation et de reprendre ces concepts que nous pensions autrefois ne pas aller au-delà du monde universitaire.

J'ai appris à programmer à Lisp il y a des années et à l'époque, je ne savais pas que c'était même de la PF. A présent, j'ai presque tout oublié, mais m'aidez certainement à comprendre très facilement des concepts tels que la récursivité.

Nous entrons dans une ère où le traitement multicœur n'est pas simplement effectué dans les coulisses des laboratoires scientifiques ou sur du matériel spécialisé. Cela se fait maintenant avec les transformateurs de produits de base. La programmation fonctionnelle, du moins la plupart des variantes auxquelles j'ai été exposée, tente généralement de pousser une vue sur des unités de calcul sans effets secondaires et sans effets secondaires. C’est le paradigme par excellence pour le travail multicœur car il n’est pas nécessaire de maintenir l’état mélangé entre les processeurs.

Ce n'est qu'une des raisons, mais une sacrée bonne raison de voir la programmation fonctionnelle s'installer.

Je pense que la réponse principale à cette question est "exposition".

La programmation fonctionnelle n’a rien de nouveau, j’ai été enseigné à l’université Haskell il ya environ 12 ans et j’ai adoré. Mais rarement eu à utiliser la langue dans mon travail professionnel.

Récemment, un certain nombre de langues ont gagné du terrain dans le courant principal en utilisant une approche multi-paradigme; F # , JavaScript étant d’excellents exemples.

Le JavaScript en particulier, en particulier lorsqu'il est utilisé avec un langage framework de style fonctionnel tel que jQuery ou Prototype , devient un langage de tous les jours pour de nombreuses personnes en raison de tous les travaux effectués sur des sites Web dynamiques et modernes. Cette exposition au style fonctionnel incite les gens à prendre conscience du pouvoir qu’elle leur confère, en particulier lorsque l’on peut revenir à un style impératif à volonté.

Une fois que les personnes sont exposées, elles expérimentent des variantes plus complètes des langages fonctionnels et commencent à les utiliser pour des tâches quotidiennes.

Avec F # devenant un langage de premier ordre dans Visual Studio 2010 et jQuery (et autres) devenant si important, il devient réaliste d’utiliser ces langages, plutôt que de créer quelque chose d’obscur pour jouer ou créer des programmes isolés.

Rappelez-vous que le code doit être gérable - une masse critique de développeurs doit utiliser et prendre en charge les langages pour que les entreprises puissent les utiliser en toute sécurité.

Dans cette discussion, Anders Hejlsberg explique son point de vue sur le sujet.

[MODIFIER]

Désolé, le lien était faux. Maintenant, il pointe au bon endroit.

Résumé extrêmement bref de quelques points du discours d'une heure:

Les langages fonctionnels autorisant un style de programmation plus déclaratif que les langages procéduraux, les programmes écrits en FL se concentrent généralement davantage sur le quoi, que sur le comment . En raison de leur structure mathématique élégante, les FLs sont également plus faciles à optimiser et à transformer par les compilateurs, ce qui facilite également la méta-programmation et la construction de DSL intégrés. Tous ces éléments réunis rendent les programmes fonctionnels plus succincts et auto-documentés que les programmes procéduraux.

De plus, face à l'ère multicolore du futur proche, les langages de programmation doivent pouvoir utiliser le multi-threading / traitement de différentes manières. Le multi-threading sur des machines à un seul noyau était en fait un mécanisme de partage du temps, et l'architecture des systèmes le reflétait. Multi threading sur plusieurs machines sera très différent. Les langues fonctionnelles sont particulièrement bien adaptées à la parallélisation, car elles évitent généralement les états. Vous n'avez donc pas à vous soucier de l'intégrité des données mutables partagées (car il n'y a généralement pas de données mutables partagées).

Je pense que cela a à voir avec la corrélation étroite entre le paradigme de la programmation fonctionnelle et la programmation pour le Web.

Ruby on Rails a mis en évidence toute l’approche de la programmation fonctionnelle, car elle offrait un chemin très rapide vers une application Web fonctionnelle (heh heh). Il y a une discussion intéressante sur SO à ce sujet, et une réponse particulière ressort:

La programmation fonctionnelle correspond très bien aux applications Web. L'application Web reçoit une requête HTTP et génère un résultat HTML. Cela pourrait être considéré comme une fonction des requêtes aux pages.

Comparez avec les applications de bureau, où nous avons généralement un processus long, une interface utilisateur avec état et un flux de données dans plusieurs directions. Ceci est plus adapté à OO qui se préoccupe des objets avec état et transmission de message.

Étant donné que la programmation fonctionnelle existe depuis très longtemps, je me demande pourquoi je ne vois pas beaucoup d'offres d'emploi qui recherchent des développeurs Lisp pour des projets Web innovants.

La programmation fonctionnelle me donne le même sens picotant de " wow, c’est nouveau " comme lorsque j’ai commencé à manipuler des objets pour la première fois.

Je me rends compte que la PF n’est pas un nouveau concept de loin, mais OO ne l’a pas non plus été lorsqu’elle a eu sa véritable pause dans les années 90 lorsque «tout le monde» s’est soudainement écarté de la programmation procédurale. Cela était dû en grande partie au succès rapide de Java, puis de C #.

J'imagine que la même chose va se passer avec FP éventuellement lorsque le prochain lot de langues commencera à se répandre de la même manière. Tout comme ils l'ont déjà fait, du moins dans certains cercles, avec des langages comme le scala et le fa #.

Voici mes questions: 1. Qu'est-ce qui a contribué à l'enthousiasme récent de la PF? Est-ce simplement de l'ennui avec OO ou est-ce que quelque chose a changé pour rendre la PF plus nécessaire qu'auparavant? 2. Cela indique-t-il un avenir de PF? Ou est-ce une lubie, comme des bases de données orientées objet?

D'autres ont donné de bonnes raisons techniques.

Je pense que la raison principale pour laquelle FP gagne du terrain parmi les types de développeurs et de gestionnaires moyens est sa promesse de permettre une meilleure utilisation des processeurs multicœurs. D'après tout ce que j'ai lu, FP permet une programmation parallèle plus facile (pas facile).

Son utilisation future sera généralisée si la promesse est réelle et remplie.

Je pense que c'est une combinaison de deux tendances:

1. Des fonctionnalités fonctionnelles sont ajoutées aux langages traditionnels (par exemple, C #).
2. Nouveaux langages fonctionnels en cours de création.

Il y a probablement une limite naturelle à la première tendance, mais je suppose que tout nouveau langage devra prendre en charge la programmation fonctionnelle, au moins en option, pour être pris au sérieux.

Auparavant, les gens écrivaient des programmes à exécuter sur le bureau à l’aide des API natives du système d’exploitation, et ces API étaient (généralement) écrites en C, si bien que si vous vouliez écrire un programme pour les API natives, a écrit ce programme en C.

Je pense que la nouvelle innovation de ces 10 dernières années concerne la diversité des API, notamment pour le développement Web, où les API de la plate-forme ne sont pas pertinentes (dans la mesure où la création d’une page Web implique essentiellement la manipulation de chaînes). Etant donné que vous ne codez pas directement vers l'API Win32 ou l'API POSIX, les utilisateurs ont la liberté d'essayer des langages fonctionnels.

C'est propre et astucieux et chatouille votre cerveau. C'est très bien.

C'est aussi, à mon humble avis, un classique. Une solution à la recherche d'un problème.

C'est comme toutes ces start-up fondées par des ingénieurs éblouis par leur idée favorite, qui brûlent fort pendant un moment, mais sont discrètement dépassés par des entreprises fondées sur la fourniture de ce qui est nécessaire.

C'est l'idée nouvelle que j'aimerais voir décoller, une programmation basée sur les besoins, pas une programmation astucieuse. Cela peut sembler banal, mais je pense que cela peut en fait être assez créatif et astucieux.

Certainement à cause de F #, bien qu’il soit parfois difficile de dire laquelle est la cause et laquelle est l’effet.