Arguments pour la programmation fonctionnelle [clos]

J'ai récemment appris F # pour le plaisir (je suis un développeur VB.NET/C#), et j'aime vraiment certains de ses avantages. Théoriquement, c'est. Mais j'ai du mal à imaginer des scénarios où je choisirais de coder en F # plutôt qu'en C #. Des idées?

Quelques arguments pour une programmation fonctionnelle pure:

• Il est plus facile de diviser les tâches pour les systèmes multicœurs d'aujourd'hui
• Il est plus facile de prouver que votre programme est correct
• La composition fonctionnelle peut être étonnante, concise et puissante

Pour un traitement complet, voir Pourquoi la programmation fonctionnelle est importante et Pourquoi la programmation fonctionnelle est importante .

J'ai du mal à imaginer des scénarios où je choisirais de coder en F # plutôt qu'en C #. Des idées?

D' ici :

Serveurs asynchrones

• Workflows asynchrones pour les E / S asynchrones.
• Processeur de boîte aux lettres pour le passage du message thread-safe.
• Types d'union pour l'état du serveur et le catalogue de messages.
• Correspondance de motif et récursion de queue pour les machines d'état.

Métaprogrammation (par exemple analyse)

• Générateurs d'analyseurs comme fslex et fsyacc.
• Combinateurs d'analyseurs comme FParsec.
• Modèles actifs pour des analyseurs élégants roulés à la main.
• Types de données algébriques pour représenter les arbres d'analyse.
• Correspondance de motifs pour manipuler les arbres, par exemple appliquer des étapes d'optimisation.
• Réflexion pour la génération d'exécution de code rapide.

Informatique technique

• Fonctions d'ordre supérieur pour un code algorithmique élégant et rapide.
• Types de données algébriques et correspondance de motifs pour la manipulation symbolique.
• Interopérabilité pour une multitude de bibliothèques .NET.
• Interactivité à l'aide de F # interactif.
• Expressions de calcul pour masser les données.
• Unités de mesure pour une meilleure correction.

Applications GUI

• Modélisez comme un message asynchrone passant entre le code d'interface utilisateur et le code logique d'application.
• Les fonctions d'ordre supérieur vous permettent de définir les interfaces utilisateur de manière déclarative.

Programmation logique

• Collections persistantes pour un retour en arrière facile.
• Tail exige de la fiabilité.
• Généralisation automatique pour une programmation générique facile.

Essai

• Exécutez les tests unitaires de manière interactive.
• BDD signifie écrire un interprète.
• Bon langage de script pour écrire des faisceaux de tests et visualiser les résultats.

Performance

• inline pour une abstraction d'ordre supérieur gratuite.
• La queue demande des machines à états rapides.
• Structures de données purement fonctionnelles pour une faible latence.
• Métaprogrammation pour la génération de code optimisé.

Voici à quoi sert la programmation de style fonctionnel - sur une base plus ou moins quotidienne.

Nous faisons beaucoup de choses statistiques et actuarielles avec des ensembles de données assez volumineux. Les données extraites de la base de données sont - essentiellement des objets statiques et immuables. Aucune raison de créer une classe avec des méthodes.

Chaque étape du calcul ajoute quelques détails supplémentaires, mais ne mute pas essentiellement l'objet. À la «fin» du pipeline, nous faisons vraiment une réduction de fantaisie pour calculer les sommes et les comptes et d'autres choses.

Imagine ça.

for data in summarize( enrich( calculate( some_query( criteria() ) ) ) ):
    print data

Chaque "phase" du calcul est une boucle de programmation fonctionnelle qui fait un simple lecture-calcul-rendement et crée un objet composite d'autres choses ainsi que des résultats.

(Nous utilisons Python, d'où la programmation fonctionnelle utilisant des fonctions de générateur.)

Il est plus facile d'utiliser des objets sans état et immuables.

Techniquement, ce n'est pas une propriété unique d'une programmation fonctionnelle, et F # n'est pas un langage fonctionnel pur. F #, en tant que descendant de ML, fournit une excellente correspondance de motifs et des types de données algébriques. Ainsi, pour toute tâche nécessitant des structures de données complexes, F # est beaucoup plus expressif et facile à utiliser que C #.

Imaginez implémenter un compilateur en C # et F # - représentant un arbre de syntaxe abstraite et les transforme dessus est beaucoup plus simple si votre langage fournit des ADT et une correspondance de modèle.

Idéal pour réduire le type de carte de parallélisme multisystème massif et multicœur massif. Assez cool, étant donné que de nos jours, les serveurs d'entrée de gamme sont livrés avec 48 cœurs (96 comptant HT).

Si vous voulez essayer Haskell entièrement fonctionnel, Erlang a aussi des trucs très sympas à ce sujet.

Simon Payton-Jones a dit à propos de Haskell, qu'il veut avoir un programme qui n'a évidemment aucun bogue, plutôt que d'avoir aucun bogue évident.

(J'ai probablement obtenu un peu la citation, mais vous avez l'idée)

En contraignant les effets secondaires, il est beaucoup plus facile de prouver que votre code est correct.

Un avantage certain est qu'il est beaucoup plus facile à paralléliser.