Pour quels problèmes courants la programmation fonctionnelle ne convient-elle pas? [fermé]

22

Fermé . Cette question doit être plus ciblée . Il n'accepte pas actuellement de réponses.

Voulez-vous améliorer cette question? Mettez à jour la question pour qu'elle se concentre sur un seul problème en modifiant ce post .

Fermé il y a 5 ans .

La programmation fonctionnelle est un paradigme déclaratif. L'un des points forts de la PF est que les effets secondaires sont évités. On dit que pour certains problèmes, la PF ne convient pas.

Pour quels problèmes courants la programmation fonctionnelle ne convient-elle pas?

functional-programming paradigms

— Jonas
source

Ouf! Pendant un instant, j'ai cru que vous aviez dit "est un paradigme défectueux ". Puis je suis revenu et j'ai vérifié.

— Mark C

1

Je pense qu'il est plus exact de dire que les effets secondaires sont isolés (en tout cas dans Haskell) qu'évités. Les monades permettent des changements d'état, et l'une est même nommée "État".

— Larry Coleman

Comme l'explique Larry Coleman, il n'est pas vrai que la programmation fonctionnelle évite les effets secondaires, mais qu'elle décourage leur utilisation et, dans certains langages, elle les isole clairement. Lire par exemple la section 7 de research.microsoft.com/en-us/um/people/simonpj/papers/…

— Giorgio

17

Applications de nature très dynamique. Les jeux vidéo en sont un bon exemple car ils modélisent le monde réel. Il est beaucoup plus logique de penser à modifier l'état du monde au lieu de reconstruire à partir de l'état précédent chaque fois que quelque chose change.

Un exemple concret serait de changer la santé d'un monstre après avoir été abattu. Il est beaucoup plus judicieux de simplement modifier sa santé que de la remplacer par un monstre entièrement nouveau qui est le même dans tous les sens, sauf qu'il a maintenant moins de santé. Ce genre de changements constitue à peu près tout dans un monde de jeu, et le faire de manière purement fonctionnelle n'est pas très intuitif. J'imagine qu'il peut y avoir des pénalités de performance importantes, du moins si vous le faites dans un langage purement fonctionnel.

(En remarque, certains problèmes dans les jeux sont très bien adaptés à la programmation fonctionnelle, comme l'IA. Un langage hybride fonctionnel / impératif conviendrait parfaitement à ces cas.)

— Matt Olenik
source

9

L'article The Next Mainstream Programming Languages: A Game Developer's Perspective plaide pour un pl, spécifiquement pour le développement de jeux, où le comportement purement fonctionnel est la valeur par défaut, et le changement d'état est suivi à travers les types, pour éviter les bugs. Donc, tout le monde ne croit pas que le paradigme fonctionnel est intrinsèquement mal adapté à la programmation de jeux.

— sepp2k

1

@ sepp2k, merci pour le lien. Je suis heureux de voir la perspective argumentée de quelqu'un qui a fait de vrais jeux.

— Matt Olenik

3

@ sepp2k attendez, ai-je raté quelque chose? Après avoir lu la présentation de plus près, il semble que Sweeney plaidait pour que la majeure partie du moteur principal soit écrite avec du code purement fonctionnel, et que la majeure partie de la logique du jeu soit écrite impérativement (ou du moins le permette) et utilise STM pour aider à la concurrence. . Cela me semble très raisonnable.

— Matt Olenik

@Matt: Non, vous avez raison, il dit que la partie logique du jeu contiendra un état mutable. Cependant, cela n'empêche pas le langage de suivre la mutabilité à travers les types (qu'il propose dans la section "rêveries"). Bien sûr, "suivre l'état à travers les types" n'est pas égal à "fonctionnel", donc j'aurais peut-être formulé mon commentaire un peu trop optimiste.

— sepp2k

@ sepp2k à droite, je vois ce que tu veux dire.

— Matt Olenik

17

La programmation intégrée en temps réel concerne les effets secondaires. Interagissant avec les io numériques et analogiques, les minuteries, les ports série et parallèles, tout ce qui est intéressant se fait en appelant des fonctions avec des effets secondaires.

— AShelly
source

3

Eh bien, si vous voulez juste dire que l'interface matérielle, je doute que tout autre que C / C ++ soit un bon choix. Cependant, sur la couche au-dessus de cela, des langues comme Erlang sont parfois utilisées, en particulier dans les systèmes de télécommunications. Erlang est un langage fonctionnel conçu pour les systèmes temps réel embarqués critiques et tolérants aux pannes.

— Jonas

@Jonas: Erlang pourrait minimiser la mutation, mais il dépend fortement des E / S pour transmettre des messages, ce qui est, bien sûr, un effet secondaire.

— Jon Harrop

11

Je dirais que la programmation GUI n'est pas un bon choix pour la programmation fonctionnelle. Les interfaces graphiques sont généralement très dynamiques, et il est beaucoup plus facile de les modéliser / gérer en utilisant l'état plutôt que d'utiliser un effet secondaire gratuit. Il est certainement possible d'utiliser un langage de programmation fonctionnel pour les interfaces graphiques ... mais ce n'est probablement pas une bonne idée.

Comme indiqué dans une autre réponse, les jeux sont souvent plus faciles à gérer en suivant l'état, et bien que vous puissiez écrire un jeu dans un langage fonctionnel, il est souvent plus facile et plus efficace de le faire dans un langage «avec état» (c'est-à-dire orienté objet la langue).

— mipadi
source

-1: Vous parlez de pureté et d'ignorer l'utilisation de fonctions de première classe, par exemple les rappels dans le code GUI sont beaucoup plus faciles avec les langages FP impurs qu'avec les langages OOP.

— Jon Harrop

4

@ Jon Harrop: Les fonctions de première classe ne sont pas propres aux langages de programmation fonctionnels. Je soutiens toujours que le style FP ne convient pas aux interfaces graphiques.

— mipadi

1

Cela dépend de qui vous demandez. Pour la plupart des programmeurs fonctionnels, les fonctions de première classe sont la définition même de la programmation fonctionnelle.

— Jon Harrop

@ Jon Harrop: La plupart des programmeurs fonctionnels diraient que la programmation fonctionnelle est une méthode pour décrire les programmes comme la composition et l'évaluation des fonctions mathématiques. Les fonctions de première classe sont une partie importante de ce paradigme, mais les fonctions de première classe ne constituent pas à elles seules un langage de programmation fonctionnel (ou un programme fonctionnel). Le paradigme de programmation fonctionnelle s'efforce de minimiser l'utilisation de structures de données d'état et mutables, et même des langages de PF impurs encouragent ce style. FP concerne autant un style de programmation que des fonctionnalités individuelles comme des fonctions de première classe, et ...

— mipadi

... Je ne trouve pas que ce paradigme se prête particulièrement à la programmation GUI - les langages orientés objet conviennent mieux aux GUI, d'une manière générale.

— mipadi

5

Applications métier pilotées par les données. L'interface utilisateur et les opérations de données simples n'ont pas besoin de FP.

— Branimir
source

2

Et toute autre application de données / vue, vraiment. La majorité des jeux concernent l'état et le changement, et ne se traduisent donc pas bien en style fonctionnel.

— Jon Purdy

18

Vraiment? J'ai toujours pensé que FP serait spécialement bon pour cela. N'est-ce pas comme 99% de ce que font ces applications pour sélectionner, agréger et projeter des données? C'est essentiellement filter, reduceet map. Ajoutez à cela certains sort, partition, groupBy. Après tout, le langage de programmation le plus utilisé pour écrire de telles applications est Excel, qui est un langage fonctionnel.

— Jörg W Mittag

3

Les applications commerciales basées sur les données et les applications avec des opérations de données simples semblent être un très bon choix pour FP et j'ai entendu dire que FP est populaire pour de telles choses. Par exemple, voir Adventures fa programmeur fonctionnel à Wall Street

— Jonas

1

-1: Vous avez répertorié une application dans laquelle FP excelle.

— Jon Harrop

2

Vous ne pouvez pas facilement ignorer un ensemble de problèmes non adapté à la programmation fonctionnelle en soi.

Cela dépend beaucoup du langage réel utilisé pour la programmation fonctionnelle et de ses fonctionnalités.

Un exemple est l'Erlang déjà mentionné pour les systèmes embarqués en temps réel.

La plénitude de l'état n'est pas non plus un bon critère contre la programmation fonctionnelle, il existe plusieurs façons efficaces de les gérer dans les langages de programmation fonctionnels.

Les effets secondaires sont également souvent mentionnés contre la programmation fonctionnelle. Chaque programme qui n'est pas totalement solipsiste a des effets secondaires. Donc, chaque langage de PF du monde réel a un moyen de faire face à cela, c'est seulement une question d'élégance pour encapsuler les effets secondaires du monde.

Il n'y a aucun besoin d'effets secondaires arbitraires comme des variables globales.

Mais il existe des ensembles de problèmes qui facilitent l'accès à la programmation fonctionnelle, car ils ne déforment pas autant votre façon habituelle de voir le problème. Mais une fois que vous parvenez à penser que les ensembles de problèmes fonctionnels sont de plus en plus ouverts à moins d'effets secondaires.

Même lors de la programmation de C, c'est toujours une bonne idée de réduire autant que possible les effets secondaires arbitraires comme les variables globales.

— Peer Stritzinger
source

Les applications d'État comme les applications GUI sont en fait difficiles à faire de manière fonctionnelle, ou avez-vous des recommandations?

— Jonas

Si vous avez une sorte d'abstraction de processus / thread (par exemple comme dans Erlang), vous pouvez passer votre état dans un processus.

— Peer Stritzinger

3

Les applications GUI sont généralement construites autour d'une boucle d'événement. Vous pouvez très bien écrire une boucle d'événements dans un langage fonctionnel. Si c'est plus compliqué, vous ajouterez probablement des threads / processus pour le traitement en arrière-plan. Mais si vous avez une sorte d'abstraction de processus / thread (comme par exemple dans Erlang), vous pouvez facilement passer votre état dans un processus. Les continuations pourraient également être utiles. Je pense que c'est juste de s'habituer à faire des choses de manière fonctionnelle pour même avoir une idée des interfaces graphiques. Une des raisons pour lesquelles la programmation GUI est considérée comme difficile aujourd'hui est que la plupart des kits d'outils ne sont pas destinés à un usage fonctionnel.

— Peer Stritzinger

1

@Jonas: dans Haskell, vous utiliseriez la monade IO, la monade State ou une combinaison.

— Larry Coleman

1

@Jonas: cela dépend de votre définition d'utile. L'exemple de wikibook utilise wxHaskell, tandis que Real World Haskell utilise gtk2hs. Je n'ai pas essayé non plus car mon application Haskell est basée sur la ligne de commande.

— Larry Coleman