Pourquoi des langages fonctionnels? [fermé]


332

Je vois beaucoup de discussions ici sur les langages fonctionnels et tout ça. Pourquoi voudriez-vous en utiliser une sur une langue "traditionnelle"? Que font-ils mieux? À quoi sont-ils pires? Quelle est l'application de programmation fonctionnelle idéale?


John Hughes a écrit un article à ce sujet: Pourquoi la programmation fonctionnelle est importante .
Hjulle

Réponses:


214

Les langages fonctionnels utilisent un paradigme différent 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'est pas important. Par exemple, dans Erlang, cela est utilisé pour activer la concurrence d'une manière très transparente. Et comme les fonctions dans les 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 le manque d'effets secondaires. Il est très difficile d'écrire un logiciel utile sans IO, mais IO est difficile à implémenter sans effets secondaires dans les fonctions. Ainsi, la plupart des gens n'ont jamais tiré davantage profit de la programmation fonctionnelle que du calcul d'une seule sortie à partir d'une seule entrée. Dans les langages modernes à paradigmes mixtes comme F # ou Scala, c'est plus facile.

Beaucoup de langages modernes ont des éléments de langages de programmation fonctionnels. C # 3.0 a beaucoup de fonctionnalités de programmation fonctionnelles et vous pouvez aussi faire 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 vrai problème dans la programmation normale parce que nous obtenons de plus en plus d'ordinateurs multiprocesseurs; et les langues deviennent plus accessibles.


14
Vous POUVEZ faire de la programmation fonctionnelle en python, mais c'est vraiment terrible. stackoverflow.com/questions/1017621/…
Gordon Gustafson

28
Il n'est pas difficile d'écrire du code IO dans des langages fonctionnels purs. Ils fournissent tous un mécanisme simple pour écrire du code d'E / S qui fonctionne exactement comme dans les langages impératifs. Tout ce qu'ils font est mettre en vigueur que vous ne pouvez pas appeler le code IO dans tout autre code dont l' interface est déclarée ne pas effectuer IO. Une analogie serait un programmeur de langage dynamique se plaignant qu'un langage typé statiquement comme Java rendait difficile le retour du type qu'elle voulait d'une méthode, car elle devait retourner tout ce que la déclaration de type disait qu'elle renverrait.
Ben

9
Haskell est un exemple de langage fonctionnel pur, qui n'a pas l'inconvénient que vous avez dit. Cela facilite en fait la gestion des effets secondaires, car les effets secondaires sont encapsulés, et permet au programmeur d'atteindre un niveau d'abstraction beaucoup plus puissant que les langages impératifs ... Vraiment, tout le monde devrait essayer Haskell, vraiment le comprendre et se rendre compte pourquoi il est si puissant.
FtheBuilder

202

Je ne pense pas qu'il y ait de doute sur l'approche fonctionnelle de la programmation "en cours", 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 appliquent un style fonctionnel reçoivent beaucoup d'encre virtuelle de nos jours, et si ces langues deviendront dominantes à l'avenir est une question ouverte. Ma propre suspicion est que les langages hybrides multi-paradigmes tels que Scala ou OCaml domineront probablement les langages fonctionnels "puristes" de la même manière que le langage OO pur (Smalltalk, Beta, etc.) a influencé la programmation traditionnelle mais n'a pas pris fin comme les notations les plus utilisées.

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

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

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


55
Il suffit de regarder 20 ans en arrière. Je ne pense pas que la programmation ait beaucoup évolué. Eh bien, ayez de meilleurs outils, peut-être une nouvelle langue ou 2 mais fondamentalement peu de choses changeront. Cela prendra plus de 20 ans. Nous pensions tous une fois que nous
verrions

32
O'Caml est irlandais cependant.
defmeta

7
@alex étrange: "Favoriser l'immuabilité" et "éviter les effets secondaires" sont de bonnes règles de base depuis un bon moment dans les écoles de programmation orientée objet et impérative. (Alors qu'est-ce qu'il ne faut pas aimer? ;-)
joel.neely

101
@bibac: il y a 20 ans, nous écrivions du code C et discutions des mérites de Clipper ou Turbo Pascal. L'orientation objet était le domaine exclusif des universitaires. Proposer que peu de choses aient changé est carrément absurde.
Daniel C.Sobral

24
@Daniel: Veuillez fournir une liste de ces personnes qui ont plaidé pour les «mérites» de Clipper. Ils doivent être traqués et traduits en justice.
David

125

Le principal avantage pour moi est son parallélisme inhérent, d'autant plus que nous nous éloignons maintenant 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 que nous devons 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.


4
Nous voyons déjà cela se produire. Et cela se produira davantage à l'avenir. Je suis donc d'accord à 100% sur ce point.
Jason Baker

La chose délicate est que ce sont les aspects partagés de rien / pas d'effets secondaires de FP qui le rendent si adapté au parallélisme. Et ce sont les aspects qui ne conviennent pas aux solutions OO - fabriquer des hybrides efficaces est extrêmement difficile. Peut-être de la colle FP entre les nœuds OO?
James Brady

Pour un hybride efficace, jetez un œil à la branche 2.0 du langage de programmation D. C'est un alpha / travail en cours, mais ça y arrive.
dsimcha

2
J'ai trouvé cette réponse intéressante, je ne connais aucun langage fonctionnel, pourquoi sont-ils considérés comme plus appropriés pour le parallélisme?
andandandand

26
Puisqu'il n'y a pas de données partagées, les fonctions n'ont aucun effet secondaire. Tout ce qui vous importe, c'est la valeur de retour. (C'est une idée assez difficile pour un programmeur OO / procédural de se tourner la tête.) De nombreuses fonctions peuvent donc être appelées en même temps, tant que la sortie de l'une n'est pas utilisée comme entrée pour une autre.
Tom Smith

79

Même si vous ne travaillez jamais dans un langage fonctionnel de manière professionnelle, la compréhension de 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 font un bon travail de mélange de style fonctionnel et impératif sont les plus intéressants et les plus susceptibles de réussir.


Bon point, mais j'aimerais voir une explication de "en quoi cela fera-t-il de vous un meilleur développeur"
mt3

20
Différents paradigmes de programmation abordent les problèmes sous différents angles et nécessitent souvent une «façon de penser différente» ou un état d'esprit. Et vous entraîner dans de multiples façons de penser (ce qui implique d'apprendre lequel utiliser dans quelle situation ...) n'est jamais une mauvaise chose.
peSHIr

56

Je suis toujours sceptique quant à la prochaine grande chose. Souvent, la 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 les technologies imparfaites, toutes très réussies car elles étaient perçues soit comme résolvant les problèmes du jour, soit comme étant presque identiques aux normes établies, ou les deux. La programmation fonctionnelle peut en effet être excellente, mais cela ne signifie pas qu'elle sera adoptée.

Mais je peux vous dire pourquoi les gens sont enthousiasmés par la programmation fonctionnelle: beaucoup, beaucoup de programmeurs ont eu une sorte d '"expérience de conversion" dans laquelle ils découvrent que l'utilisation d'un langage fonctionnel les rend deux fois plus productifs (ou peut-être dix fois plus productifs) tout en produisant code plus résilient au changement et comportant moins de bogues. Ces gens considèrent la programmation fonctionnelle comme une arme secrète; un bon exemple de cet état d'esprit est Beating the Averages de Paul Graham . Oh, et sa candidature? Applications Web de commerce électronique.

Depuis le début de 2006, la programmation fonctionnelle et le parallélisme ont également fait le buzz. Depuis que des gens comme Simon Peyton Jones s'inquiètent du parallélisme 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 en ce moment.

En général, les universités américaines font un mauvais travail en enseignant la programmation fonctionnelle. Il existe un noyau solide de support pour l' enseignement de la programmation d'intro à l'aide de Scheme , et Haskell y bénéficie également d'un certain support, mais il y a très peu de méthode d'enseignement de la technologie avancée pour le programmeur fonctionnel. J'ai enseigné un tel cours à Harvard et je le ferai encore 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 valeur 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 connais pas les universités britanniques. Vous êtes plus que susceptible de constater que de nombreuses universités ici enseignent très peu de langages de programmation (Java, C, peut-être Perl si vous avez de la chance). Le problème ici est la différence de qualité, car les meilleures (quelques) universités ont les meilleurs programmes de CS.
Mike B

Je ne suis pas d'accord avec le fait que les exemples que vous avez donnés sont défectueux, de niche peut-être ou adaptés à certains domaines, mais suffisamment généraux pour être repris universellement sans une courbe d'apprentissage massive. c'est probablement la principale raison de leur succès.
gbjbaanb

J'ai fait Forth et Lisp à uni au Royaume-Uni (ainsi que Pascal, C, Modula2 et Cobol) mais c'était il y a 20 ans ..
kpollock

29
J'ai appris Java / C ++ à uni (en Australie), mais quelques-uns de mes collègues sont allés dans différentes universités où ils ont fait plusieurs unités à Haskell. Il a été utilisé à la fois pour l'introduction à la programmation et pour l'une de leurs unités de dernière année. J'ai ri quand j'ai entendu ce que mon collègue a dit à un professeur de Java après avoir été initié au casting pour la première fois (à ce stade, il ne connaissait que Haskell) - "Quoi?! Vous voulez dire que vous avez quelque chose et que vous ne le faites pas" t SAVOIR de quel type il s'agit?! "
Jacob Stanley

1
Regardez ce qui est arrivé à C # avec tous ces Européens dans l'équipe :)
Benjol

32

Je ne vois personne mentionner l'éléphant dans la pièce ici, donc je pense que ça dépend de moi :)

JavaScript est un langage fonctionnel. Alors que de plus en plus de gens font des choses plus avancées avec JS, notamment en tirant parti des points les plus fins de jQuery, Dojo et d'autres cadres, 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, mais toujours lisible.

À la vôtre, PS


2
C'est ainsi que j'ai vraiment commencé à creuser la programmation fonctionnelle. Rien n'est mieux que list.Each (function (item) {}) de Prototype.js ou toute la méthode de fonctionnement de jQuery.
Cory R. King

20
Javascript permet de programmer de manière fonctionnelle. C'est, cependant, un langage de paradigme croisé, permettant de programmer de différentes manières (ce que je préfère, mais ce n'est pas pertinent) ... OO, fonctionnel, procédural, etc.
RHSeeger


Les méthodes d'objet jQuery ne sont que des opérations dans la liste monad. Prendre un objet qui représente un conteneur (ou une séquence) en entrée et renvoyer un conteneur d'objet en sortie est un bel exemple de réinvention pratique de fmap.
Jared Updike

25

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

  1. Les moyens OO n'ont pas toujours été «normaux». 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 (programmation fonctionnelle de substitution pour Lisp):

Donc, la courte explication de la raison pour laquelle ce langage des années 50 n'est pas obsolète est qu'il ne s'agissait pas de technologie mais de mathématiques, et les mathématiques ne sont pas périmées. La bonne chose à comparer à Lisp n'est pas du matériel des années 50, mais, disons, l'algorithme Quicksort, qui a été découvert en 1960 et est toujours le type à usage général le plus rapide.


25

Je parie que vous ne saviez pas que vous étiez une programmation fonctionnelle lorsque vous avez utilisé:

  • Formules Excel
  • Compositeur de quartz
  • Javascript
  • Logo (graphiques tortue)
  • LINQ
  • SQL
  • Underscore.js (ou Lodash), D3

10
Comment Javascript est-il considéré comme une programmation fonctionnelle?
Pacerier

8
Il a des fonctions de première classe, des fonctions d'ordre supérieur, des fermetures, des fonctions anonymes, une application partielle, un curry et une composition.
daniel1426

2
Haha. Une fois, j'ai écrit une formule Excel de remboursement de charge qui était plus large que l'écran avec des fonctions imbriquées. Je savais en quelque sorte que je programmais fonctionnellement, mais je ne connaissais pas encore le terme.
ProfK

7
Veuillez ajouter C à cette liste
Mandeep Janjua

2
@MandeepJanjua: Hein? Comment venir? Ou pourquoi pas une langue alors?
Sz.

18

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

Mais ce n'est qu'une question de temps. Votre programmeur d'entreprise moyen apprend quelle que soit la grande chose actuelle. Il y a 15 ans, ils ne comprenaient pas la POO. SI FP se propage, 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é, SML est la toute première langue que les étudiants connaissent. Je crois que le MIT enseigne LISP comme un cours de première année. Ces deux exemples peuvent ne pas être représentatifs, bien sûr, mais je pense que la plupart des universités offrent à tout le moins des cours optionnels sur la PF, même s'ils n'en font pas une partie obligatoire du programme d'études.

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

Ce n'est pas vraiment une question de "assez simple". Une solution serait-elle plus simple (ou plus lisible, robuste, élégante, performante) en FP? Beaucoup de choses sont "assez simples pour être résolues en Java", mais cela nécessite toujours une quantité de code illimitée.

Dans tous les cas, gardez à l'esprit que les partisans de la PF ont affirmé que c'était la prochaine grande chose depuis plusieurs décennies maintenant. Peut-être qu'ils ont raison, mais gardez à l'esprit qu'ils ne l'étaient pas lorsqu'ils ont fait la même demande il y a 5, 10 ou 15 ans.

Une chose qui compte vraiment en leur faveur, cependant, est que récemment, C # a pris un virage serré 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 rendent compte . Cela pourrait ouvrir la voie à la "révolution" du FP. Peut être. ;)


MIT utilisé pour enseigner le schéma dans son cours CS intro, mais il utilise Python maintenant.
mipadi

1
"Il y a 15 ans, ils ne comprenaient pas la POO" - Le problème est qu'il y a 15 ans, ils ne comprenaient pas non plus la PF. Et ils ne le font toujours pas aujourd'hui.
Jason Baker

15

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

Qui n'a pas appris quelque chose de plus sur lui-même en observant les activités des autres? Pour apprendre l'épée, étudiez la guitare. Pour apprendre le premier commerce d'étude. Étudier simplement l'épée vous rendra étriqué et ne vous permettra pas de grandir vers l'extérieur.

- Miyamoto Musashi, "Un livre de cinq anneaux"


12

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

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

Haskell utilise à la place une approche différente de l'IO: les monades. Ce sont des objets qui contiennent l'opération d'E / S souhaitée à exécuter par le niveau supérieur de votre interprète. À tout autre niveau, ce ne sont que des objets du système.

Quels avantages offre la programmation fonctionnelle? La programmation fonctionnelle permet de coder avec moins de potentiels de bugs car chaque composant est complètement isolé. En outre, l'utilisation de fonctions de récursivité et de première classe permet de simples preuves de correction qui reflètent généralement la structure du code.


12

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 des problèmes mathématiques, mais des règles impératives velues pour déplacer les données et les afficher de diverses manières, ce qui signifie que ce n'est pas un bon ajustement pour le paradigme de programmation fonctionnelle pure (la courbe d'apprentissage de la monade dépasse de loin OO.)

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

Cela fait de vous un meilleur être sensible.


6
Je ne pense pas que OO soit intrinsèquement plus facile que FP. Cela dépend vraiment de votre expérience (je suis un mathématicien, devinez ce que je trouve beaucoup plus facile? :)
temp2290

14
Les monades ne sont pas difficiles à comprendre. N'achetez pas cette connerie.
Rayne

-1 OOP est plus difficile que FP
juste quelqu'un

-1 Nous n'écririons pas des compilateurs d'optimisation en utilisant OCaml ou Haskell si FP n'était approprié que pour de jolis problèmes mathématiques.
gracchus

8

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 comme F # où vous pouvez regarder le code source et voir comment et pourquoi il était préférable d'utiliser une telle approche que, disons, C #?


Bonne remarque +1. @Mendelt: "plus accessible"? Voulez-vous dire que le mal de tête est plus rapide lorsque vous regardez le code?
Patrick Honorez

2
Voir cette bibliothèque F #: quanttec.com/fparsec/tutorial.html . J'adorerais voir un exemple de code en C # avec des analyseurs qui semblaient à moitié aussi élégants et lisibles que le code F #, même s'ils sont compilés selon les mêmes instructions. Et essayez de porter FParsec de F # vers C # et voyez comment le code gonfle.
Jared Updike

8

Je voudrais souligner que tout ce que vous avez dit sur les langages fonctionnels, la plupart des gens parlaient de 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 indépendamment du fait que les personnes formées aux technologies antérieures considèrent que le changement n'est pas nécessaire. Pensez-vous que le passage à OO était bon malgré toutes les personnes qui étaient contre à l'époque?


2
* Le programmeur d'entreprise moyen, par exemple la plupart des gens avec qui je travaille, ne le comprendra pas et la plupart des environnements de travail ne vous laisseront pas le programmer - C'est encore vrai de la POO dans de nombreux endroits où j'ai travaillé :) (bien sûr, ils disent ils font de la POO, mais ils ne le sont pas)
tolanj

7

F # pourrait prendre de l'ampleur car Microsoft le pousse.

Pro:

  • F # va faire partie de la prochaine version de Visual Studio
  • Microsoft construit une communauté depuis un certain temps maintenant - des évangélistes, des livres, des consultants qui travaillent avec des clients de haut niveau, une exposition importante aux conférences MS.
  • F # est un langage .Net de première classe et c'est le premier langage fonctionnel qui vient avec de très grandes bases (pas que je dis que Lisp, Haskell, Erlang, Scala, OCaml n'ont pas beaucoup de bibliothèques, elles ne sont tout simplement pas aussi complètes que .Net est)
  • Un fort soutien au parallélisme

Contra:

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

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


6
Je dirais que Scala était une fondation assez profonde avec le JRE.
cdmckay le

2
En ce qui concerne les bibliothèques, cela dépend vraiment de ce que vous faites. F # est destiné au secteur financier et est également applicable au calcul scientifique, mais OCaml possède en fait de bien meilleures bibliothèques pour de telles applications que .NET. Par exemple, lorsque je suis arrivé en F # d'OCaml, je n'ai pas réussi à trouver une FFT décente et j'ai fini par écrire (et vendre) la mienne en C # puis en F #.
Jon Harrop

1
LINQ est un bon pont pour utiliser des concepts fonctionnels avec C # et VB.Net ... Et je trouve que c'est beaucoup moins pénible à lire par rapport à F #
Matthew Whited

5

Je pense que l'une des raisons est que certaines personnes pensent que la partie la plus importante de l'acceptation d'une langue est la qualité de la langue . Malheureusement, les choses sont rarement aussi simples. Par exemple, je dirais que le plus grand facteur derrière l'acceptation de Python n'est pas le langage lui-même (bien que ce soit assez important). La plus grande 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 être l'exception à la règle à ce sujet étant donné qu'ils sont construits sur la JVM / CLR. En conséquence, je n'ai pas de réponse pour eux.


+1, mais n'oubliez pas la puissance du marketing et le fait que la montagne de code hérité de votre entreprise ne changera pas de langue en raison d'une nouvelle tendance cool.
temp2290

Et vous avez oublié de mentionner: Google popularise le python.
Hao Wooi Lim

4

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

Bien que cela soit vrai, différents outils peuvent être utilisés pour résoudre différents problèmes. Fonctionnel permet juste une autre abstraction de haut niveau (plus élevé?) Qui permet de faire notre travail plus efficacement lorsqu'il est utilisé correctement.


4

Il me semble que les personnes qui n'ont jamais appris le Lisp ou le Scheme en tant que premier cycle le découvrent maintenant. Comme pour beaucoup de choses dans ce domaine, il y a une tendance à exagérer et à créer des attentes élevées ...

Ça va passer.

La programmation fonctionnelle est excellente. Cependant, il ne prendra pas le contrôle du monde. C, C ++, Java, C #, etc. seront toujours là.

Ce qui en résultera, je pense, sera une plus grande capacité multilingue - par exemple, implémenter des choses dans un langage fonctionnel et donner ensuite accès à ce genre de choses dans d'autres langues.


1
C # est maintenant un langage de programmation fonctionnel (autant que Lisp) car il possède des fermetures lexicales de première classe. En effet, ils sont déjà utilisés dans WPF et le TPL. La programmation fonctionnelle est donc évidemment déjà là.
Jon Harrop


3

Les choses évoluent dans une direction fonctionnelle depuis un certain temps. Les deux nouveaux enfants 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 "assez proche".

Et avec le matériel massivement parallèle mettant une pression évolutive sur tout le monde - et les langages fonctionnels au meilleur endroit pour faire face aux changements - ce n'est pas aussi loin que de penser que Haskell ou F # sera la prochaine grande chose.


3

Avez-vous suivi l'évolution des langages de programmation récemment? 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, les fonctions de passage et de retour en tant que valeurs étaient auparavant des fonctionnalités exotiques connues uniquement des pirates Lisp et ML. Mais progressivement, C #, Delphi, Python, Perl, Javascript, ont ajouté le support des fermetures. Il n'est pas possible de prendre au sérieux toute langue émergente sans fermeture.

  • 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 lancé 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 que depuis environ 5 ans. Si je me souviens bien, Fortran a pris 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 évident: cela aide les programmeurs à écrire du code plus court . À l'avenir, toutes les langues vont soutenir - au minimum - les fermetures si elles veulent rester compétitives. À cet égard, la programmation fonctionnelle est déjà courante.

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

Qui a dit qu'on ne pouvait pas utiliser la programmation fonctionnelle pour des choses simples aussi? Tous les programmes fonctionnels n'ont pas besoin d'ê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.



3

Le lien ne s'ouvre pas. Erreur 403.
Alexey Frunze

Cela pourrait être un bon remplacement? cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
canadiancreed

Lien mort. C'est pourquoi ces types de réponses sont défavorables à la citation ainsi qu'à la liaison.
Sylwester

J'ai corrigé le lien. @Sylwester c'est vrai, mais c'est un document de 23 pages. Distiller le papier pour répondre sur ce site ne lui rendrait pas justice.
grom

2

Je suis d'accord avec le premier point, mais les temps changent. Les entreprises répondront, même si elles adoptent tardivement, si elles voient qu'il y a un avantage à avoir. 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, MIT, Stanford et d'autres bonnes écoles le présentent aux étudiants.

Je suis d'accord 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: ce pourrait être le problème qui ne peut pas être résolu facilement par d'autres moyens qui stimulera la programmation fonctionnelle. Qu'est-ce que ce serait?

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


2

Parce que FP présente des avantages importants en termes de productivité, de fiabilité et de maintenabilité. Many-core peut être une application qui tue et fait finalement basculer les grandes entreprises malgré de gros volumes de code hérité.De plus, même les grands langages commerciaux comme C # prennent une saveur fonctionnelle distincte en raison de préoccupations multi-core - effets secondaires tout simplement ne correspondent pas bien à la concurrence et au parallélisme.

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

De plus, la plupart des universités enseignent la PF, beaucoup l'enseignent même comme premier cours de programmation.


Désolé, mais FP existe depuis presque 3 fois plus longtemps que la POO. Ce n'est tout simplement pas une question de besoin de plus de temps. Il faudra quelque chose de plus pour intégrer la PF.
Jason Baker

Comment pourriez-vous manquer la partie de mon article où j'explique que le "quelque chose de plus" pourrait très bien être multicœur? Et quelque chose "d'être autour" n'est pas vraiment pertinent. Les gens comprenaient la POO parce qu'elle offrait des avantages tangibles à l'époque, la PF n'est que récemment devenue pratique.
Sebastian

2

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 langues sans PF commencent déjà à prendre des idées de FP, donc je soupçonne que cette tendance se poursuivra et nous verrons plus d'une fusion qui devrait aider les gens à faciliter le saut vers la PF.


2

Je ne sais pas si cela va prendre de l'ampleur ou non, mais d'après mes recherches, un langage fonctionnel vaut presque certainement la peine d'être appris et fera de vous un meilleur programmeur. La simple compréhension de la transparence référentielle facilite beaucoup les décisions de conception et les programmes qui en résultent sont beaucoup plus faciles à raisonner. Fondamentalement, si vous rencontrez un problème, cela tend à être uniquement un problème avec la sortie d'une seule fonction, plutôt qu'un problème avec un état incohérent, qui pourrait avoir été causé par l'une des centaines de classes / méthodes / fonctions dans un langage imparatif avec des effets secondaires.

La nature sans état de FP correspond plus naturellement à la nature sans état du Web, et les langages fonctionnels se prêtent donc plus facilement à des applications Web RESTFUL plus élégantes. 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 sans état comme le Web.

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


2

À mon avis, cela va se faire sentir maintenant que Microsoft l'a poussé beaucoup plus loin dans le courant dominant. 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 pour nous aider à devenir plus productifs en tant que programmeurs.


2

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

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


1

En plus des autres réponses, la formulation de la solution en termes purement fonctionnels oblige à mieux comprendre le problème. À l'inverse, la pensée dans 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.

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.