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?
Réponses:
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.
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:
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.
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.
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.
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 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
La plupart des applications sont suffisamment simples pour être résolues de manière OO normale
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.
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.
Je parie que vous ne saviez pas que vous étiez une programmation fonctionnelle lorsque vous avez utilisé:
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. ;)
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"
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.
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.
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 #?
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?
F # pourrait prendre de l'ampleur car Microsoft le pousse.
Pro:
Contra:
Donc, je donne 50:50 chance à F # de devenir important. D'autres langages fonctionnels ne le feront pas dans un avenir proche.
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.
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.
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.
En lisant "The Next Mainstream Programming Language: A Game Developer's Perspective" par Tim Sweeney, Epic Games, ma première pensée a été - j'ai appris Haskell.
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.
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.
Il prend de l'ampleur car c'est le meilleur outil pour contrôler la complexité. Voir:
- diapositives 109-116 de Simon Peyton-Jones talk "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer's Perspective" par Tim Sweeney
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?
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.
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.
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.
À 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.
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%.
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.