Question

Je vois beaucoup de discussions ici sur les langages fonctionnels et autres.Pourquoi en utiliseriez-vous une plutôt qu'une langue « traditionnelle » ?Que font-ils de mieux ?En quoi sont-ils pires ?Quelle est l'application de programmation fonctionnelle idéale ?

Était-ce utile?

La solution

Les langages fonctionnels utilisent un paradigme différent de celui des langages impératifs et orientés objet.Ils utilisent des fonctions sans effets secondaires comme élément de base du langage.Cela permet beaucoup de choses et rend beaucoup de choses plus difficiles (ou dans la plupart des cas différentes de ce à quoi les gens sont habitués).

L’un des plus grands avantages de la programmation fonctionnelle est que l’ordre d’exécution des fonctions sans effets secondaires n’a pas d’importance.Par exemple, dans Erlang, cela est utilisé pour activer la concurrence de manière très transparente.Et comme les fonctions des langages fonctionnels se comportent de manière très similaire aux fonctions mathématiques, il est facile de les traduire en langages fonctionnels.Dans certains cas, cela peut rendre le code plus lisible.

Traditionnellement, l’un des gros inconvénients de la programmation fonctionnelle était également l’absence d’effets secondaires.Il est très difficile d'écrire des logiciels utiles sans IO, mais IO est difficile à implémenter sans effets secondaires dans les fonctions.Ainsi, la plupart des gens n’ont jamais tiré davantage de la programmation fonctionnelle que de calculer une seule sortie à partir d’une seule entrée.Dans les langages modernes à paradigmes mixtes comme F# ou Scala, c'est plus facile.

De nombreux langages modernes contiennent des éléments issus de langages de programmation fonctionnels.C# 3.0 possède de nombreuses fonctionnalités de programmation fonctionnelle et vous pouvez également effectuer de la programmation fonctionnelle en Python.Je pense que les raisons de la popularité de la programmation fonctionnelle sont principalement dues à deux raisons :La concurrence devient un réel problème dans la programmation normale car nous avons de plus en plus d'ordinateurs multiprocesseurs ;et les langues deviennent plus accessibles.

Autres conseils

Je ne pense pas qu'il y ait de doute sur l'approche fonctionnelle de la programmation qui « fait son chemin », car elle est utilisée (comme style de programmation) depuis environ 40 ans.Chaque fois qu'un programmeur OO écrit du code propre qui favorise les objets immuables, ce code emprunte des concepts fonctionnels.

Cependant, les langues qui imposer un style fonctionnel fait couler beaucoup d’encre virtuelle ces jours-ci, et la question reste ouverte de savoir si ces langages deviendront dominants à l’avenir.Je soupçonne que les langages hybrides et multi-paradigmes tels que Échelle ou OCamldominera probablement les langages fonctionnels « puristes » de la même manière que le langage OO pur (Smalltalk, Beta, etc.) a influencé la programmation grand public mais n'est pas devenu la notation la plus largement utilisée.

Enfin, je ne peux m'empêcher de souligner que vos commentaires concernant FP sont très parallèles aux remarques que j'ai entendues de la part des programmeurs procéduraux il n'y a pas si longtemps :

  • Le (mythique, à mon humble avis) programmeur "moyen" ne le comprend pas.
  • Ce n’est pas largement enseigné.
  • Tout programme avec lequel vous pouvez écrire peut être écrit d'une autre manière avec les techniques actuelles.

Tout comme les interfaces utilisateur graphiques et le « code comme modèle d'entreprise » étaient des concepts qui ont aidé l'OO à être plus largement apprécié, je pense qu'une utilisation accrue de l'immuabilité et un parallélisme plus simple (massif) aideront davantage de programmeurs à voir les avantages qu'offre l'approche fonctionnelle. .Mais autant que nous l'avons appris les 50 dernières années qui constituent toute l'histoire de la programmation informatique numérique, je pense que nous avons encore beaucoup à apprendre.Dans vingt ans, les programmeurs seront étonnés de constater la nature primitive des outils que nous utilisons actuellement, y compris les langages OO et FP désormais populaires.

Le principal avantage pour moi est son parallélisme inhérent, d'autant plus que nous nous éloignons désormais de plus de MHz et vers de plus en plus de cœurs.

Je ne pense pas que cela deviendra le prochain paradigme de programmation et remplacera complètement les méthodes de type OO, mais je pense que nous arriverons au point où nous devrons soit écrire une partie de notre code dans un langage fonctionnel, soit nos langages à usage général le feront. grandir pour inclure des constructions plus fonctionnelles.

Même si vous n’avez jamais travaillé professionnellement dans un langage fonctionnel, comprendre la programmation fonctionnelle fera de vous un meilleur développeur.Cela vous donnera une nouvelle perspective sur votre code et votre programmation en général.

Je dis qu'il n'y a aucune raison de ne pas l'apprendre.

Je pense que les langages qui réussissent bien à mélanger les styles fonctionnel et impératif sont les plus intéressants et les plus susceptibles de réussir.

Je suis toujours sceptique quant au Next Big Thing.Bien souvent, le Next Big Thing est un pur accident de l’histoire, étant là au bon endroit au bon moment, que la technologie soit bonne ou non.Exemples:C++, Tcl/Tk, Perl.Toutes des technologies imparfaites, toutes extrêmement réussies parce qu’elles étaient perçues soit comme résolvant les problèmes du moment, soit comme étant presque identiques aux normes établies, ou les deux.La programmation fonctionnelle est peut-être géniale, mais cela ne veut pas dire qu’elle sera adoptée.

Mais je peut te dire pourquoi les gens sont excité à propos de la programmation fonctionnelle :De très nombreux programmeurs ont eu une sorte d'« expérience de conversion » dans laquelle ils ont découvert que l'utilisation d'un langage fonctionnel les rend deux fois plus productifs (ou peut-être dix fois plus productifs) tout en produisant un code plus résistant au changement et comportant moins de bogues.Ces personnes considèrent la programmation fonctionnelle comme une arme secrète ;un bon exemple de cet état d'esprit est celui de Paul Graham Battre les moyennes.Oh, et sa candidature ?Applications Web de commerce électronique.

Depuis début 2006, il y a également eu un certain buzz autour de la programmation fonctionnelle et du parallélisme.Puisque les gens aiment Simon Peyton Jones Je m'inquiète du parallélisme de temps en temps depuis au moins 1984, je ne retiens pas mon souffle jusqu'à ce que les langages fonctionnels résolvent le problème multicœur.Mais cela explique une partie du buzz supplémentaire actuel.

En général, les universités américaines enseignent mal la programmation fonctionnelle.Il existe un solide noyau de soutien pour enseigner la programmation d'introduction à l'aide de Scheme, et Haskell bénéficie également d'un certain soutien là-bas, mais il y a très peu d'enseignements de techniques avancées pour les programmeurs fonctionnels.J'ai enseigné un tel cours à Harvard et je le ferai à nouveau ce printemps à Tufts.Benjamin Pierce a enseigné un tel cours à Penn.Je ne sais pas si Paul Hudak a fait quelque chose à Yale.Les universités européennes font un bien meilleur travail ;par exemple, la programmation fonctionnelle est mise en avant dans des endroits importants au Danemark, aux Pays-Bas, en Suède et au Royaume-Uni.J'ai moins une idée de ce qui se passe en Australasie.

Je ne vois personne mentionner l'éléphant dans la pièce ici, donc je pense que c'est à moi de décider :)

JavaScript est un langage fonctionnel.Alors que de plus en plus de personnes font des choses plus avancées avec JS, en tirant notamment parti des subtilités de jQuery, Dojo et d'autres frameworks, FP sera introduit par la porte dérobée du développeur Web.

En conjonction avec les fermetures, FP rend le code JS vraiment léger, tout en restant lisible.

Bravo, PS

La plupart des applications sont suffisamment simples pour être résolues de manière normale en OO.

  1. Les manières oo n'ont pas toujours été «normales». La norme de cette décennie était le concept marginalisé de la dernière décennie.

  2. La programmation fonctionnelle est mathématique. Paul Graham sur Lisp (remplacer la programmation fonctionnelle par Lisp) :

Donc, la courte explication de la raison pour laquelle cette langue des années 1950 n'est pas obsolète est qu'elle n'était pas de la technologie mais les mathématiques et les mathématiques ne sont pas périmées.La bonne chose à comparer LISP n'est pas le matériel des années 1950, mais, par exemple, l'algorithme Quicksort, qui a été découvert en 1960 et est toujours le type à usage général le plus rapide.

Je parie que vous ne saviez pas que vous faisiez de la programmation fonctionnelle lorsque vous utilisiez :

  • Formules Excel
  • Compositeur de quartz
  • Javascript
  • Logo (graphiques de tortue)
  • LINQ
  • SQL
  • Souligner.js (ou lodash), d3

Le programmeur d'entreprise moyen, par ex.La plupart des gens avec qui je travaille, ne le comprendront pas et la plupart des environnements de travail ne vous laisseront pas programmer

Mais celui-là n’est qu’une question de temps.Votre programmeur d'entreprise moyen apprend quel que soit le Big Thing actuel.Il y a 15 ans, ils ne comprenaient pas la POO.SI FP fait son chemin, vos "programmeurs d'entreprise moyens" suivront.

Ce n'est pas vraiment enseigné dans les universités (ou est-ce de nos jours?)

Varie beaucoup.Dans mon université, le SML est la toute première langue à laquelle les étudiants sont initiés.Je crois que le MIT enseigne le LISP en première année.Bien sûr, ces deux exemples ne sont peut-être pas représentatifs, mais je pense que la plupart des universités proposent au moins des cours optionnels sur la PF, même si elles n'en font pas une partie obligatoire du programme.

La plupart des applications sont assez simples pour être résolues de manière normale OO

Ce n'est pas vraiment une question de "assez simple".Une solution serait-elle plus simple (ou plus lisible, robuste, élégant, performant) en FP ?Beaucoup de choses sont « assez simples pour être résolues en Java », mais cela nécessite quand même une énorme quantité de code.

Dans tous les cas, gardez à l’esprit que les partisans du FP prétendent qu’il s’agit de la prochaine grande nouveauté depuis plusieurs décennies maintenant.Peut-être ont-ils raison, mais gardez à l’esprit qu’ils ne l’étaient pas lorsqu’ils ont fait la même affirmation il y a 5, 10 ou 15 ans.

Une chose qui compte définitivement en leur faveur, cependant, est que récemment, C# a pris un virage radical vers FP, dans la mesure où il transforme pratiquement une génération de programmeurs en programmeurs FP, sans même qu'ils s'en aperçoivent.Cela pourrait bien ouvrir la voie à la « révolution » de la PF.Peut être.;)

L’homme ne peut pas comprendre la perfection et les imperfections de l’art qu’il a choisi s’il ne peut pas voir la valeur des autres arts.Suivre des règles ne permet que de développer la technique jusqu'à un certain point, puis l'étudiant et l'artiste doivent en apprendre davantage et chercher plus loin.Il est logique d’étudier d’autres arts en plus de ceux de la stratégie.

Qui n’a pas appris davantage sur lui-même en observant les activités des autres ?Pour apprendre l’épée, étudiez la guitare.Pour apprendre la première étude du commerce.Étudier simplement l’épée vous rendra étroit d’esprit et ne vous permettra pas de grandir vers l’extérieur.

-- Miyamoto Musashi, "Un livre aux cinq anneaux"

Une caractéristique clé d’un langage fonctionnel est le concept de fonctions de première classe.L'idée est que vous pouvez transmettre des fonctions en tant que paramètres à d'autres fonctions et les renvoyer sous forme de valeurs.

La programmation fonctionnelle consiste à écrire du code qui ne change pas d'état.La principale raison en est que les appels successifs à une fonction produiront le même résultat.Vous pouvez écrire du code fonctionnel dans n'importe quel langage prenant en charge des fonctions de première classe, mais certains langages, comme Haskell, ne vous permettent pas de changer d'état.En fait, vous n'êtes pas censé créer d'effets secondaires (comme l'impression de texte) - ce qui semble complètement inutile.

Haskell utilise plutôt une approche différente des IO :monades.Ce sont des objets qui contiennent l'opération IO souhaitée à exécuter par le niveau supérieur de votre interpréteur.À tout autre niveau, ils ne sont que des objets dans le système.

Quels avantages offre la programmation fonctionnelle ?La programmation fonctionnelle permet de coder avec moins de risques de bugs car chaque composant est complètement isolé.De plus, l'utilisation de fonctions de récursion et de première classe permet d'obtenir des preuves simples d'exactitude qui reflètent généralement la structure du code.

Je ne pense pas que la plupart des gens réalistes pensent que la programmation fonctionnelle va faire son chemin (devient le paradigme principal comme OO).Après tout, la plupart des problèmes commerciaux ne sont pas de jolis problèmes mathématiques mais des règles impératives poilues pour déplacer les données et les afficher de différentes manières, ce qui signifie que ce n'est pas un bon choix pour le paradigme de programmation fonctionnelle pure (la courbe d'apprentissage de la monade dépasse de loin l'OO.)

OTOH, la programmation fonctionnelle est ce qui rend la programmation amusante.Cela vous fait apprécier la beauté inhérente et intemporelle des expressions succinctes des mathématiques sous-jacentes à l’univers.Les gens disent qu’apprendre la programmation fonctionnelle fera de vous un meilleur programmeur.Ceci est bien sûr très subjectif.Personnellement, je ne pense pas non plus que ce soit tout à fait vrai.

Cela fait de vous un meilleur être sensible.

Je dois être dense, mais je ne comprends toujours pas.Existe-t-il des exemples réels de petites applications écrites dans un langage fonctionnel tel que F# où vous pouvez consulter le code source et voir comment et pourquoi il était préférable d'utiliser une telle approche que, disons, C# ?

Je tiens à souligner que tout ce que vous avez dit sur les langages fonctionnels, la plupart des gens le disaient sur les langages orientés objet il y a environ 20 ans.À l’époque, il était très courant d’entendre parler d’OO :

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

Le changement doit venir de quelque part.Un changement significatif et important se produira, même si les personnes formées aux technologies antérieures estiment que le changement n'est pas nécessaire.Pensez-vous que le passage à OO était une bonne chose malgré tous les gens qui s'y opposaient à l'époque ?

F# pourrait faire son chemin parce que Microsoft le pousse.

Pro:

  • F# fera partie de la prochaine version de Visual Studio
  • Microsoft construit une communauté depuis un certain temps déjà - des évangélistes, des livres, des consultants qui travaillent avec des clients de premier plan, une visibilité significative lors des conférences MS.
  • F# est un langage .Net de première classe et c'est le premier langage fonctionnel doté d'une très grande base (je ne dis pas que Lisp, Haskell, Erlang, Scala, OCaml n'ont pas beaucoup de bibliothèques, ils ne sont tout simplement pas aussi complets que .Net). est)
  • Fort soutien au parallélisme

Contra:

  • F# est très difficile à démarrer même si vous maîtrisez C# et .Net - du moins pour moi :(
  • il sera probablement difficile de trouver de bons développeurs F#

Donc, je donne 50 :50 de chance à F# de devenir important.D’autres langages fonctionnels ne seront pas disponibles dans un avenir proche.

Je pense qu'une des raisons est que Certaines personnes pensent que l'élément le plus important pour déterminer si une langue sera acceptée est la qualité de la langue..Malheureusement, les choses sont rarement aussi simples.Par exemple, je dirais que le facteur le plus important derrière l’acceptation de Python n’est pas le langage lui-même (même si cela est assez important).La principale raison pour laquelle Python est si populaire est son énorme bibliothèque standard et la communauté encore plus grande de bibliothèques tierces.

Des langages comme Clojure ou F# peuvent faire exception à la règle étant donné qu'ils sont construits sur JVM/CLR.Par conséquent, je n’ai pas de réponse à leur donner.

La plupart des applications peuvent être résolues en [insérez votre langue, paradigme, etc. préféré.ici].

Même si cela est vrai, différents outils peuvent être utilisés pour résoudre différents problèmes.Functional permet simplement un autre niveau d'abstraction élevé (supérieur ?) qui permet de faire notre travail plus efficacement lorsqu'il est utilisé correctement.

Il me semble que ceux qui n'ont jamais appris Lisp ou Scheme au premier cycle le découvrent maintenant.Comme pour beaucoup de choses dans ce domaine, il y a une tendance à faire du battage médiatique et à créer des attentes élevées...

Ça va passer.

La programmation fonctionnelle est géniale.Cependant, il ne conquérira pas le monde.C, C++, Java, C#, etc. seront toujours là.

Ce qui en résultera, je pense, c'est davantage de capacités multilingues - par exemple, implémenter des choses dans un langage fonctionnel, puis donner accès à ces éléments dans d'autres langues.

En lisant « Le prochain langage de programmation grand public :Le point de vue d'un développeur de jeux" par Tim Sweeney, Epic Games, ma première pensée a été : j'ai pu apprendre Haskell.

PPT

Version HTML de Google

Depuis un moment, les choses évoluent dans un sens fonctionnel.Les deux nouveaux venus cool de ces dernières années, Ruby et Python, sont tous deux radicalement plus proches des langages fonctionnels que ceux qui les ont précédés – à tel point que certains Lispers ont commencé à prendre en charge l'un ou l'autre comme étant « assez proches ».

Et avec le matériel massivement parallèle qui exerce une pression évolutive sur tout le monde – et les langages fonctionnels au meilleur endroit pour faire face aux changements – il n’est plus aussi loin qu’avant de penser que Haskell ou F# seront la prochaine grande nouveauté.

Avez-vous suivi l'évolution des langages de programmation ces derniers temps ?Chaque nouvelle version de tous les langages de programmation traditionnels semble emprunter de plus en plus de fonctionnalités à la programmation fonctionnelle.

  • Les fermetures, les fonctions anonymes, le passage et le renvoi de fonctions en tant que valeurs étaient des fonctionnalités exotiques connues uniquement des pirates Lisp et ML.Mais progressivement, C#, Delphi, Python, Perl, Javascript ont ajouté la prise en charge des fermetures.Il n’est pas possible qu’une langue émergente soit prise au sérieux sans fermetures.

  • Plusieurs langages, notamment Python, C# et Ruby, prennent en charge nativement les compréhensions de listes et les générateurs de listes.

  • ML a été le pionnier de la programmation générique en 1973, mais la prise en charge des génériques (« polymorphisme paramétrique ») n'est devenue une norme industrielle qu'au cours des cinq dernières années environ.Si je me souviens bien, Fortran prenait en charge les génériques en 2003, suivi de Java 2004, C# en 2005, Delphi en 2008.(Je sais que C++ prend en charge les modèles depuis 1979, mais 90 % des discussions sur la STL de C++ commencent par « ici, il y a des démons ».)

Qu’est-ce qui rend ces fonctionnalités attrayantes pour les programmeurs ?Cela devrait être clairement évident : cela aide les programmeurs à écrire du code plus court.À l’avenir, toutes les langues soutiendront – au minimum – les fermetures si elles veulent rester compétitives.À cet égard, la programmation fonctionnelle est déjà largement répandue.

La plupart des applications sont assez simples pour être résolues de manière normale OO

Qui a dit qu’on ne pouvait pas également utiliser la programmation fonctionnelle pour des choses simples ?Tous les programmes fonctionnels ne doivent pas nécessairement être un compilateur, un prouveur de théorèmes ou un commutateur de télécommunications massivement parallèle.J'utilise régulièrement F# pour des scripts jetables ad hoc en plus de mes projets plus compliqués.

Cela prend de l'ampleur car c'est le meilleur outil pour contrôler la complexité.Voir:
- diapositives 109 à 116 de la conférence de Simon Peyton-Jones "A Taste of Haskell"
- "Le prochain langage de programmation grand public :Le point de vue d'un développeur de jeux" par Tim Sweeney

Je suis d'accord avec le premier point, mais les temps changent.Les entreprises réagiront, même si elles sont des adeptes tardives, si elles voient qu'il y a un avantage à en tirer.La vie est dynamique.

Ils enseignaient Haskell et ML à Stanford à la fin des années 90.Je suis sûr que des endroits comme Carnegie Mellon, le MIT, Stanford et d'autres bonnes écoles le présentent aux étudiants.

Je conviens que la plupart des applications « exposer des bases de données relationnelles sur le Web » continueront dans cette veine pendant longtemps.Java EE, .NET, RoR et PHP ont développé de très bonnes solutions à ce problème.

Vous avez touché quelque chose d'important :Il s'agit peut-être d'un problème qui ne peut pas être résolu facilement par d'autres moyens qui stimuleraient la programmation fonctionnelle.Qu'est-ce que ce serait ?

Le matériel multicœur massif et le cloud computing les feront-ils progresser ?

Parce que FP présente des avantages significatifs en termes de productivité, de fiabilité et de maintenabilité.Many-core est peut-être une application tueuse qui amènera finalement les grandes entreprises à basculer malgré de grands volumes de code existant. De plus, même les grands langages commerciaux comme C# prennent une saveur fonctionnelle distincte en raison de préoccupations multi-cœurs - des effets secondaires simplement ne correspondent pas bien à la concurrence et au parallélisme.

Je ne suis pas d'accord avec le fait que les programmeurs "normaux" ne le comprendront pas.Ils le feront, tout comme ils ont finalement compris la POO (qui est tout aussi mystérieuse et étrange, sinon plus).

En outre, la plupart des universités enseignent la FP, beaucoup l'enseignent même comme premier cours de programmation.

Wow – c'est une discussion intéressante.Mes propres réflexions à ce sujet :

FP rend certaines tâches relativement simples (par rapport aux langages sans FP).Les langages non-FP commencent déjà à s'inspirer des idées de FP, donc je soupçonne que cette tendance se poursuivra et que nous assisterons à une plus grande fusion qui devrait aider les gens à faire le saut vers FP plus facilement.

Je ne sais pas si cela va se répandre ou non, mais d'après mes enquêtes, un langage fonctionnel vaut presque certainement la peine d'être appris et fera de vous un meilleur programmeur.Le simple fait de comprendre la transparence référentielle rend de nombreuses décisions de conception beaucoup plus faciles et les programmes qui en résultent beaucoup plus faciles à raisonner.Fondamentalement, si vous rencontrez un problème, il s'agit généralement d'un problème lié à la sortie d'une seule fonction, plutôt que d'un problème lié à un état incohérent, qui aurait pu être causé par l'une des centaines de classes/méthodes/fonctions. dans un langage imparatif avec des effets secondaires.

La nature apatride de FP correspond plus naturellement à la nature apatride du Web, et les langages fonctionnels se prêtent donc plus facilement à des applications Web plus élégantes et RESTFUL.Contrairement aux frameworks JAVA et .NET qui doivent recourir à des HACKS horriblement laids comme les clés VIEWSTATE et SESSION pour maintenir l'état de l'application et maintenir l'abstraction (parfois assez fuyante) d'un langage impératif avec état, sur une plate-forme fonctionnelle essentiellement apatride comme le Web.

Et aussi, plus votre application est apatride, plus elle peut se prêter facilement au traitement parallèle.Terriblement important pour le Web, si votre site Web devient populaire.Il n'est pas toujours simple d'ajouter simplement du matériel à un site pour obtenir de meilleures performances.

Mon point de vue est que cela va prendre de l’ampleur maintenant que Microsoft l’a poussé beaucoup plus loin dans le grand public.Pour moi, c'est attrayant en raison de ce qu'il peut faire pour nous, parce que c'est un nouveau défi et en raison des opportunités d'emploi qu'il représente pour l'avenir.

Une fois maîtrisé, ce sera un autre outil qui nous aidera à devenir plus productifs en tant que programmeurs.

Un point oublié dans la discussion est que les meilleurs systèmes de types se trouvent dans les langages FP contemporains.De plus, les compilateurs peuvent déduire automatiquement tous les types (ou du moins la plupart).

Il est intéressant de noter que l'on passe la moitié du temps à écrire des noms de types lors de la programmation Java, mais Java n'est de loin pas sûr.Bien que vous ne puissiez jamais écrire de types dans un programme Haskell (sauf en tant que sorte de documentation vérifiée par le compilateur) et que le code est 100% sécurisé.

En plus des autres réponses, présenter la solution en termes purement fonctionnels oblige à mieux comprendre le problème.À l’inverse, penser selon un style fonctionnel développera de meilleures* compétences en résolution de problèmes.

*Soit parce que le paradigme fonctionnel est meilleur, soit parce qu'il offrira un angle d'attaque supplémentaire.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top