Quelle est votre opinion la plus forte contre la programmation fonctionnelle? [fermé]


25

La programmation fonctionnelle est l'un des plus anciens paradigmes de programmation. Cependant, il n'est pas beaucoup utilisé dans l'industrie par rapport aux paradigmes plus populaires. Mais cela a été largement souligné dans le monde universitaire.

Quelle est votre opinion la plus forte contre la programmation fonctionnelle?


5
LINQ? Délégués .NET? Des DSL comme Mathematica?
Jon Harrop

5
Soit dit en passant, le terme «programmation fonctionnelle» est utilisé par différentes personnes pour signifier différentes choses, vous devez donc clarifier la signification que vous utilisez.
Jon Harrop

2
Vous ne trouverez jamais, jamais personne à coder sur votre base de code fonctionnelle. Pas une bonne décision commerciale, limitant votre bassin de talents.
Patrick Hughes

Réponses:


52

Le problème est que le code le plus courant implique par nature l'état - les applications professionnelles, les jeux, l'interface utilisateur, etc. Il n'y a aucun problème avec certaines parties d'une application qui sont purement fonctionnelles; en fait, la plupart des applications pourraient bénéficier dans au moins un domaine. Mais forcer le paradigme partout semble contre-intuitif.


19
Absolument. La programmation fonctionnelle pure n'est PAS bien adaptée aux applications très orientées état. C'est pourquoi j'aime les langages hybrides qui peuvent faire les deux. Utilisez des paradigmes fonctionnels pour les problèmes fonctionnels, des paradigmes impératifs pour les problèmes impératifs.
Matt Olenik

8
D'accord! L'État est un élément essentiel de la programmation. C'est pourquoi même Haskell, à certains égards le plus pur des langages FP, permet l'utilisation de l'état et des IO - il applique simplement une distinction entre le code IO / code d'état mutable et le code pur, ce qui est très agréable pour les tests et pour la facilité de compréhension .
Projet de loi

8
C'est pourquoi j'aime Haskell. Il encourage à minimiser ces codes avec état. Dans OO, je vise à écrire du code réutilisable, facile à comprendre et facile à tester. La plupart du temps, je me retrouve avec du code que je n'écrirais pas très différemment en Haskell.
LennyProgrammers

4
"il impose simplement une distinction entre le code IO / code d'état mutable et le code pur, ce qui est très agréable pour les tests". Vous ne pouvez même pas imprimer de messages de débogage sans contourner le système de saisie ou introduire un fluage de monade.
Jon Harrop

2
Vraisemblablement, un programme de fonction pure laisserait le monde totalement inchangé en l'exécutant?
Martin Beckett

24

Le problème avec la programmation fonctionnelle n'est pas la programmation fonctionnelle elle-même - c'est la plupart des gens qui le font et (pire) la plupart des gens qui conçoivent des langages dans lesquels le faire.

Le problème vient du fait que, même s'ils sont très intelligents (parfois carrément brillants), beaucoup trop de gens sont juste un peu trop fanatiques de la pureté, de la perfection et appliquent leur propre vision (souvent assez étroite) du monde et de la programmation sur le monde. la langue et tous ceux qui l'utilisent.

L'un des résultats est un échec de compromis. Cela conduit (entre autres) à environ 10 000 langues et dialectes suffisamment différents pour déranger, mais rarement assez différents pour que l'un ait un avantage vraiment significatif sur les autres. Beaucoup regardent également le monde réel et décident que comme il ne correspond pas très bien au modèle fonctionnel, il est fondamentalement faux et mieux ignoré.

L'incapacité à faire des compromis a également conduit à un certain nombre de langues qui sont absolument magnifiques pour un type de problème spécifique (ou quelques types de problèmes spécifiques) mais qui sont vraiment nulles pour beaucoup d'autres. Une partie de cela est probablement causée par le modèle fonctionnel lui-même, mais beaucoup plus semble (au moins pour moi) être causé par le type de personnalité de base qui est attiré par ce domaine au départ.

Cela entraîne un certain nombre de problèmes. Tout d'abord, l'apprentissage de la "programmation fonctionnelle" a surtout une valeur philosophique. Avec la plupart des autres types de langues, la connaissance d'une langue d'un genre particulier est d'une grande aide pour en apprendre une autre. Si mon projet utilise la langue XI, je peux généralement embaucher quelqu'un qui connaît la langue Y (mais pas X) en toute sécurité. Avec les langages fonctionnels, c'est beaucoup moins vrai. Vous connaissez peut-être assez bien Erlang, mais vous trouvez toujours des monades Haskell complètement étrangères et incompréhensibles.

Combinez le nombre de langues avec la portabilité limitée des talents entre elles, et vous obtenez une situation laide: il est presque impossible pour une langue ou un dialecte de former la "masse critique" nécessaire pour en faire un usage raisonnablement général. Cela change lentement, mais cela ressemble toujours beaucoup à ce que Linux devienne le système d'exploitation de bureau dominant - chaque année, les gens arrivent avec des arguments convaincants que finalement ce sera l' année - et tout comme les gens qui ont prédit que chaque année depuis des décennies maintenant, ils auront encore tort. Cela ne veut pas dire que cela (l'un ou l'autre) ne peut jamais arriver - juste que les personnes qui regardent les prédictions et pensent "non, pas cette année" ont été celles qui avaient raison jusqu'à présent.


4
Il y aurait peut-être plus de croisement entre les langages fonctionnels s'il y avait plus de langages fonctionnels.
Barry Brown

5
Vous ne pouvez pas être "fonctionnel" sans cette pureté. Une fois que vous franchissez la ligne, le concept entier s'effondre et vous vous retrouvez avec un langage standard désordonné et parallèle sans aucun des avantages.
Patrick Hughes

7
Donc, votre premier problème est que les langages fonctionnels ne sont pas assez différents pour avoir un avantage les uns sur les autres, et votre deuxième problème est qu'ils sont trop différents pour être facilement interchangeables?
Tikhon Jelvis

2
Pour moi, cette réponse se lit comme une diatribe. Votre argument serait beaucoup plus convaincant si vous deviez donner quelques exemples.
Benjamin Hodgson

1
...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...Non, cela ressemble à toutes ces langues procédurales. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceylan, Python, la liste est longue - ce ne sont que des itérations ennuyeuses de C qui ne résolvent pas les vrais problèmes. C'est mon opinion déclamée pour compléter cette réponse déclamante: D
cat

17

Je pense que la raison pour laquelle la programmation fonctionnelle n'est pas très largement utilisée est qu'elle vous gêne trop. Il est difficile de regarder sérieusement, par exemple, Lisp ou Haskell, sans dire "tout ce langage est une grande inversion d'abstraction". Lorsque vous établissez des abstractions de base que le codeur ne peut pas atteindre en cas de besoin, vous établissez des choses que le langage ne peut tout simplement pas faire, et plus le langage est fonctionnel, plus il a tendance à en avoir.

Prenez Haskell, par exemple. Au nom de la pureté fonctionnelle, vous devez utiliser des inversions d'abstraction révolutionnaires que personne ne comprend pour gérer l'état et les E / S, les deux parties les plus fondamentales de tout programme informatique qui interagit avec quoi que ce soit! Ça vieillit vite.


9
+1, même si je ressens parfois la même chose lorsque je programme dans des langues impératives de haut niveau. Par exemple, pourquoi le fsck dois-je créer une classe de méthode unique qui implémente une interface de méthode unique en Java au lieu d'utiliser simplement un pointeur de fonction comme je le ferais en C?
dsimcha

14
Je dirais que ce n'est pas que vous "ne pouvez pas vous soustraire" à ces abstractions, c'est plus que cela prend juste beaucoup de travail. Nous avons l'habitude de ramasser une banane et de la manger dans un langage impératif; Haskell (par exemple) vous fait d'abord remplir un formulaire de 20 pages car il priorise en garantissant qu'aucune banane ne sera jamais mystérieusement mangée lorsque vous ne regarderez pas. Ce qui aide à raisonner sur les bananes, mais parfois vous avez juste faim.
j_random_hacker

4
@dsimcha: c'est une particularité de Java plutôt qu'une tendance dans les langages impératifs de haut niveau. En fait, les langages de haut niveau sont probablement plus susceptibles d'avoir la fonction d'objet de première classe.
Muhammad Alkarouri

3
La nécessité des monades à Haskell ne vient pas de la pureté fonctionnelle, mais du fait que les effets secondaires et l'évaluation paresseuse sont deux saveurs formidables qui ne sont PAS délicieuses ensemble. Les monades forcent une évaluation séquentielle. (Vraiment, ils devraient être appelés des constructeurs de calcul ou quelque chose comme ça. 'Monade' est un nom moche pour quiconque autre qu'un théoricien des catégories.) Et vous pouvez faire du FP avec bonheur sans (en utilisant sciemment) des monades!
Frank Shearar

4
Une chose à noter: étant donné ces "inversions d'abstraction", le langage peut être plus limité, mais le compilateur et le runtime ont plus de garanties sur votre code et peuvent faire plus. C'est comme la récupération de place - dans un langage gc, vous ne pouvez pas simplement utiliser l'espace malloc (ce qui pourrait être utile), mais en retour, le runtime peut gérer toute votre mémoire pour vous, potentiellement plus efficacement que vous ne le pourriez manuellement. C'est la même chose avec la pureté fonctionnelle.
Tikhon Jelvis

8

Avec tout le respect que je vous dois, je pense que votre question est mal posée. La programmation fonctionnelle est un outil, ou plutôt un ensemble d'outils utiles pour résoudre certains types de problèmes. Avoir une opinion à ce sujet n'a de sens que dans le contexte d'un problème ou d'une application spécifique. Avoir une opinion contre elle en général, c'est comme avoir une opinion contre les pinces ou les clés.


4
C'est un point logiquement valable, mais il peut être résolu en plaçant "pour le type de problèmes de programmation que vous rencontrez fréquemment" sur la dernière phrase de la question du PO. (Peu importe que les lecteurs individuels rencontrent des problèmes différents, à condition qu'ils décrivent ce qu'ils sont.)
j_random_hacker

4

Même si je l'avais maîtrisé, je serais peut-être peu enclin à utiliser un langage fonctionnel pour un produit commercial pour la simple raison qu'ils ne sont pas largement compris et si je m'attendais à ce que l'entreprise se développe, je serais préoccupé par la capacité de trouver d'autres développeurs capables de le maintenir ou de l'étendre dans le temps.

Ce n'est pas inconcevable, et vous obtiendriez probablement un niveau de développeur plus élevé, car un diplômé de la javaschool sans compétences réelles en piratage ne saurait pas par où commencer un projet de ce type, mais le bassin limité de développeurs capables serait certainement une considération nécessaire d'un point de vue commercial.


2

Temps de mise sur le marché

Difficile de débarrasser un paysage informatique complet du code procédural et des mantras.


1
Les programmes fonctionnels sont souvent plus faciles à tester. Et ils sont plus courts. Donc en désaccord. Je pense que vous répondez à une autre question "Quelle est votre opinion la plus forte contre le passage à la programmation fonctionnelle?".
Jonas


2

tout d'abord, je n'accepte aucun des arguments concernant la programmation d'État et fp. examinez la monade d'État dans haskell et vous trouverez un certain nombre de nouvelles façons intéressantes d'évaluer l'impact de l'État sur votre code.

si je devais faire un argument significatif contre fp, ce serait qu'apprendre un langage fonctionnel sérieux comme haskell, c'est comme apprendre à conduire une voiture de formule 1 ... exaltant et éducatif, mais malheureusement inutile pour le codage industriel quotidien car, en moyenne , vos collègues conduisent des camrys et sont très heureux de le faire. il est toujours extrêmement difficile de trouver du travail dans un environnement favorable aux fp, et je ne vois pas cela changer à moins que quelqu'un ne veuille se lancer seul ou chercher certains des praticiens bien connus du fp.

je suppose que ma réponse me montre comme un fanboy fp. je suggère de donner une vraie tournure à un langage fp comme haskell avant de vous soucier de trouver des raisons pour lesquelles vous ne devriez pas.


6
Je pense que votre premier paragraphe décrit exactement ce qui ne va pas avec l'état d'esprit FP. Nous ne voulons pas de «nouvelles façons intéressantes d'évaluer l'impact de l'État sur notre code». Qu'est ce que ça veut dire?!? Nous voulons simplement que l'État soit là et facilement accessible, car nous en avons besoin pour faire avancer les choses.
Mason Wheeler

2
La Camry I drive a ses problèmes, mais elle ne nécessite pas que je vérifie constamment sous le capot les fuites d'espace . Haskell ressemble plus à un langage qui ressemble à une voiture de F1, mais ne peut pas réellement faire de hauts régimes pendant une période prolongée. :-P
j_random_hacker

1
@Mason Wheeler: "Nous ne voulons pas de nouvelles façons intéressantes d'évaluer l'impact de l'état sur notre code." Au lieu de cela, nous préférons passer une semaine à rechercher un bug très méchant en raison d'un effet secondaire indésirable (je parle d'expérience personnelle).
Giorgio

@brad clawsie: Je pense que toute la question du contrôle des effets secondaires dans la PF peut rendre le codage beaucoup plus productif: l'écriture prend plus de temps mais moins de temps à corriger. Malheureusement, il faut d'abord consacrer beaucoup d'efforts à l'apprentissage, et beaucoup de programmeurs n'ont pas cette pensée à long terme: les choses doivent se faire rapidement. Il n'y a pas de temps pour le faire correctement la première fois, mais il est toujours temps de le déboguer et de le corriger plus tard. :-)
Giorgio

@Mason Wheeler: D'un point de vue fonctionnel, avoir un état partagé n'est utile qu'à des fins d'optimisation: la copie de valeurs autour prend trop de temps et de mémoire, donc vous partagez un objet de données pour éviter une copie inutile. Mais imposer un état partagé en règle générale depuis le début est une sorte d'optimisation prématurée.
Giorgio

2

Je suis un grand fan et défenseur de la programmation fonctionnelle. Mais voici mes points:

  • facile à apprendre
    Les langages de programmation comme python et ruby ​​(et de nombreux autres langages) sont faciles à apprendre. La programmation fonctionnelle avancée, avec des langages comme Haskell, Agda, Coq, ATS, etc., est assez difficile à apprendre. Certains utilisent le terme «programmation structurée mathématique». C'est facile si vous êtes familier avec la théorie des catégories et les mathématiques abstraites, mais pas mal de travail si vous n'avez aucune idée de ce que sont par exemple les "monades".

  • la programmation avec un langage de script peut signifier plus de productivité.
    Dans certaines situations, l'utilisation de langages de script comme python et ruby ​​peut augmenter la productivité. Cela signifie un prototypage rapide et le collage de différents packages ou bibliothèques. Même l'utilisation de langages dynamiques (par exemple la programmation orientée objet dynamique) peut être une bonne chose dans ce contexte. Habituellement, la frappe statique est meilleure, mais les scripts avec des types dynamiques peuvent avoir un effet positif.

  • considérations commerciales La
    programmation n'est qu'un petit sous-ensemble de projets logiciels réussis. Le logiciel doit fonctionner, les utilisateurs doivent être satisfaits et cela ne dépend pas nécessairement du langage de programmation utilisé. Les gestionnaires doivent penser aux avantages et aux risques lors de l'évaluation des nouvelles technologies et langages de programmation. Les nouveaux programmeurs peuvent-ils apprendre rapidement le nouveau langage de programmation? Y a-t-il une expérience dans l'entreprise avec la technologie? Y a-t-il un risque et sera-t-il difficile de discuter avec la haute direction?

Dans le contexte commercial, la programmation fonctionnelle peut être utilisée dans des systèmes qui s'ajoutent aux composants logiciels de base, par exemple, des composants qui ne sont pas si critiques pour la mission. Par exemple, une banque qui ne changera guère le logiciel de base, mais ajoutera de nouvelles parties (GUI, logiciel de surveillance, etc.) dans un nouveau langage de programmation. (Peut-être qu'il y a des exceptions, mais c'est mon expérience avec les banques.)

De plus, la programmation fonctionnelle est très utile lorsque la vérification formelle est un avantage ou un must.


3
"facile à apprendre": je ne trouve pas plus difficile de maîtriser Haskell que de maîtriser le C ++ moderne. Je pense que nous avons tendance à réfléchir sérieusement à ce que nous ne connaissons pas.
Giorgio

1

Je ne suis pas opposé à la FP comme paradigme utile, mais je m'y oppose comme le seul paradigme disponible dans un langage de programmation.

Il offre des avantages pour résoudre de nombreux problèmes. Cependant FP peut, et a été, appliqué dans des langages procéduraux comme C.


D'accord avec la première phrase, en désaccord avec la seconde. Vous ne pouvez essentiellement pas faire de FP sans garbage collection.
dsimcha

Il n'y a aucune exigence que le système d'exécution d'un langage manque de gestion transparente de la mémoire (avec récupération de place) afin de s'adapter à l'étiquette "procédurale", il est donc ironique que vous ayez formulé votre deuxième phrase de cette façon. BASIC est l'une de ces langues.
Huperniketes

"Vous ne pouvez pas faire de FP sans ramasser les ordures." - Pourquoi?
quant_dev

+1 La programmation fonctionnelle au niveau le plus élémentaire est la programmation sans état. Je ne pense pas qu'il y ait un langage qui ne puisse pas faire cela dans une certaine mesure. J'ai écrit des fonctions en C, C ++, Java, assembleur, C #, même Basic. Tout ce qui est requis est que la fonction n'ait pas d'effets secondaires ou ne conserve pas d'état entre les appels.
Michael K

En revanche, si votre langage est entièrement pur, le compilateur a plus de latitude dans ses optimisations. En outre, le code devient plus facile à tester et à raisonner. Être fonctionnel tout au long de ne donner quelques avantages par rapport à une approche hybride; si vous voulez que la majorité de votre code soit de toute façon apatride, vous pouvez aussi bien aller un peu plus loin et récolter les avantages supplémentaires.
Tikhon Jelvis

1
  1. (et de loin le plus important) Le personnel de programmation n'est pas formé dans ces langages ou styles
  2. Beaucoup d'évangélistes fonctionnels se présentent comme des trous ou des gâteaux aux fruits en raison de la façon dont ils essaient de vendre des fonctionnels. Personne n'aime un trou et personne ne va jeter de l'argent derrière un gâteau aux fruits. Attention, j'aime vraiment les trucs fonctionnels et j'aimerais les utiliser, mais je sais que sur mon lieu de travail, je serais la seule personne qui pourrait les développer sans dépenser d'argent pour la formation (vente difficile), et presque tout le bien fait référence au lecteur.

La fonctionnalité viendra quand nous aurons des centaines de cœurs et nous nous rendrons compte que les verrous ne se mettent pas à l'échelle. Ensuite, les données imbriquées parallèles seront la seule voie à suivre pour les programmes "big iron", et les fonctionnalités fonctionnelles à cela.


0

FP est cool dans le milieu universitaire car il est cool d'écrire de bons programmes courts, tout en ignorant les performances. Il n'y a pas de complot contre cela dans le monde réel. Aussi, par exemple, la mise en œuvre de certaines choses (tri radix par exemple) semble être une douleur totale en PF. Oh et le code généré est IMHExperience sloooooooooooooooooooow.


4
Ouais, c'est tout simplement faux. Le code Haskell est généralement à égalité avec C et Java, et beaucoup plus rapide que Python et ses amis. Il est également généralement trivial de paralléliser, ce qui donne potentiellement encore plus de vitesse.
Tikhon Jelvis

0

Certains ont une courbe d'apprentissage assez abrupte, qui prend beaucoup de temps (surtout si vous venez de la POO; vous vous pencherez la tête plusieurs fois avant de changer de paradigme).

Même si j'ai commencé à obtenir de la programmation fonctionnelle (venant de Java et allant vers Clojure), je trouve cela assez difficile. La communauté ne semble pas écrire du code aussi expressif que Java.

On dirait qu'il y a une petite perte d'expressivité et une petite augmentation de complexité.


Je pense que les personnes sans expérience préalable en programmation diraient que la POO a une courbe d'apprentissage plus abrupte que FP, car FP est plus proche des mathématiques. Je ne comprends pas ce que vous voulez dire par "La communauté ne semble pas écrire du code aussi expressif que Java", quel est votre point?
Jonas

Je n'ai jamais entendu parler de langage fonctionnel perdant de son expressivité. Mais alors je n'ai jamais utilisé un langage moins expressif que Java non plus, donc je peux avoir une définition différente de "expressif".
glenatron

@Jonas - à cause d'une chose simple: raccourcir les noms des fonctions, des variables, etc ... je veux dire, pourquoi ne pas simplement nommer les choses pour ce qu'elles sont ou sont censées faire? pourquoi "pmap"?
Belun

1
@Belun: Cela n'a rien à voir avec la programmation fonctionnelle. Vous devez vous référer à un langage de programmation spécifique. La carte est une fonction courante dans de nombreux langages de programmation fonctionnels et elle a un bon nom . pmapvous faites référence peut être une variante parallèle.
Jonas

j'ai dit "la communauté ne semble pas écrire". cela signifie que c'est ce que j'ai vécu et cela concerne la communauté que j'ai regardée. il ne doit pas s'appliquer à tous, bien que j'en doute. cela a à voir avec la programmation fonctionnelle, c'est comme son style
Belun

0

Même si j'ai peu d'expérience avec les langages de programmation fonctionnels (je connais certains Haskell et Lisp), je trouve le paradigme FP très puissant et souvent plus élégant que les autres paradigmes. J'aurais aimé avoir l'opportunité de travailler sur un projet sérieux utilisant la PF.

Le seul domaine dans lequel j'ai de sérieux doutes quant à l'efficacité de la PF est de savoir comment elle peut gérer des structures de données complexes qui ne peuvent pas être définies de manière inductive, par exemple les graphiques. Par exemple, si je dois implémenter un algorithme qui fonctionne sur un grand graphique, en parcourant éventuellement le graphique et en faisant de petits changements locaux, je me demande si une approche FP peut correspondre à une approche impérative dans laquelle le programme est autorisé à passer d'un nœud à nœud en utilisant des pointeurs.

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.