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


50

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?



13
Ce n’est pas un doublon - c’est se demander pourquoi les gens se mettent à faire des histoires, car ce n’est pas une idée nouvelle (alors que cette question demande davantage de différences objectives).
Peter Boughton

2
Les gens font des histoires sur la PF récemment? La nouvelle, j’ai pensé que c’était toujours le cas, un groupe faisait des histoires sur la façon dont la PF allait prendre le contrôle du monde de la programmation impérative.
Chris

1
Je pense avoir déjà répondu à cette question sur StackOverflow.
Ken Bloom

1
Ouais - FP était déjà vieux, je pense, quand j'utilisais Scheme comme étudiant de premier cycle à Columbia en 1989. C'est la toute nouvelle chose brillante, je suppose.
Tim

Réponses:


33

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.


Extrêmement informatif, merci. J'accepte cette réponse, non pas parce qu'elle a raison et que les autres ont tort (j'ai voté plusieurs fois), mais parce que je pense qu'elle mérite la visibilité qui en résulte.
Eric Wilson

Un exemple plus pertinent serait type IO a = UI -> (a, UI)une réponse fantastique cependant.
ChaosPandion

@Richard: "tapez IO a = World -> (a, World)" semble presque trop beau pour être vrai (je pensais que je n'aurais jamais de monades). Je suppose que vous comparez LINQ à des monades, car lorsque vous transmettez un lambda à un opérateur LINQ, le lambda "voit" tout son environnement, est-ce exact?
Stefan Monov

@Stefan: Cela semble un peu juste de dire que le lambda voit son environnement, mais je ne suis pas tout à fait clair là-dessus, alors j'hésite à répondre jusqu'à ce que j'en apprenne plus moi-même. Cependant, je peux affirmer avec une certitude absolue que LINQ est une monade, car les créateurs l’ont dit à maintes reprises. SelectMany est exactement équivalent à Bind in Haskell. Si vous n'avez pas lu "Les merveilles des monades" ( blogs.msdn.com/b/wesdyer/archive/2008/01/11/… ), je le recommande vivement ... Cela montrera que LINQ est vraiment des monades. À votre santé.
Richard Anthony Hein

1
@Job, voir blogs.msdn.com/b/wesdyer/archive/2008/01/11/…, comme indiqué dans le commentaire ci-dessus.
Richard Anthony Hein

30

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:

  • 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 ...


3
C'était vrai en 1950, bien sûr.
Eric Wilson

1
@ FarmBoy, pas vraiment, mais c'est aujourd'hui.

5
Comment cela diffère-t-il de l'injection de dépendance?
Bill K

2
@ Bill K, excellente observation - je n'avais pas fait cette connexion moi-même. La différence est que les objets à injecter - du moins en Java - sont évalués avec impatience et non paresseusement. Vous ne pouvez pas injecter une liste infinie.

1
@ Thorbjørn Ravn Andersen Je ne suis pas certain de comprendre pourquoi une liste infinie serait utile. Pouvez-vous réellement faire la somme des opérations de type (liste infinie)? Cela semble très improbable. Sinon, cela ressemble à la façon dont Java utilise les itérateurs, vous codez-le de manière à instancier les objets uniquement lorsque vous les demandez - pas tout à fait infini, mais sans fin (il y a une énorme différence, hein? )
Bill K

21

À 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.


6
J'allais ajouter une réponse, mais vous avez tout à fait raison dans votre dernière phrase. La programmation fonctionnelle va devenir de plus en plus répandue à mesure que le nombre de cœurs dans une seule machine augmente. Le manque d’état inhérent facilite la scission mécanique des programmes fonctionnels entre les processeurs (ce qui signifie que si vous avez un programme purement fonctionnel, un compilateur peut théoriquement s’occuper du parallélisme pour vous avec un effort minimal de votre part, voir youtube.com/watch? v = NWSZ4c9yqW8 pour une discussion sur le parallélisme des données).
Inaimathi

1
@ Inaimathi Ditto. La programmation fonctionnelle est très évolutive, ce qui est logique pour les architectures multicœurs.
EricBoersma

Notez que mon premier commentaire a été écrit avant que la réponse ne soit modifiée pour contenir une déclaration supplémentaire.
Inaimathi

Désolé. J'ai juste oublié ce point.
LennyProgrammers

Est-il vraiment généralement admis que des compilateurs fonctionnels ne peuvent pas produire un code machine aussi optimisé qu'un OOPS? Je ne peux pas penser à une raison théorique pour laquelle cela doit être vrai; et je peux imaginer des moyens de rendre possibles des optimisations plus avancées que dans un OOPS.
Jeremy

7

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é.


2
La question concerne les avantages des langues de type PF . Ce que vous avez décrit peut également être fait en utilisant les langues traditionnelles.
Pacerier

6

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.


5

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é.


3

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).


1
Pourriez-vous résumer?

1
@Thorbjorn Cela me rappelle l'homme qui n'a pas pu résumer . (Ne vous dirigez pas vers cela, répondez l'auteur.)
Mark C

1
Le lien ne relie même pas au bon endroit.
Ken Bloom

2

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.


Je pense que l'analogie fonctionnelle ne s'applique au Web qu'incidemment, car le protocole sous-jacent est sans état. Les applications Web ne sont pas vraiment sans état, ce qui explique pourquoi nous devons toujours travailler avec HTTP.
Mladen Jablanović

@Mladen Hmmm, est-il possible que vous associez l'état de communication client-serveur (HTTP) avec l'état de l'application (DAO, etc.)? Citation de Stefan Tilkov à partir d’ici ( codemonkeyism.com/stateless-applications-illusion ) "Dans une application Web, chaque requête individuelle doit contenir suffisamment d’informations pour pouvoir être traitée, qu’une requête précédente ait eu lieu ou non. Ressource côté serveur persistante l'état est correct, l'état côté client est correct, la communication transitoire (session) ne l'est pas parce que cela va ruiner l'évolutivité et la possibilité de création de marque-pages. " C'est la base de REST.
Gary Rowe

1
Vous voudrez peut-être lire paulgraham.com/avg.html pour mieux comprendre pourquoi il n'y a pas beaucoup d'offres d'emploi qui recherchent des développeurs Lisp.

@ Thorbjørn Ravn Andersen Bon article. M'inspire pour sortir mon éditeur Lisp.
Gary Rowe

1

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 #.


OO est bien plus jeune que FP, mais il a été mis à l'honneur bien avant. Je suppose que la parenthèse a effrayé trop de gens
Javier

1

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.


C'est un grand "si". COBOL, être "en anglais" allait signifier que tout le monde pouvait programmer. L'intelligence artificielle allait rendre la programmation obsolète. OO allait rendre la programmation aussi simple que d'assembler des tinkertoys. Les codeurs sont comme des groupies de rock, toujours à la recherche de la "prochaine grande chose", et de celle qui suit, et de la ...
Mike Dunlavey

0

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.


0

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.


0

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.


-1

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.