Comment utiliser la programmation fonctionnelle dans le monde réel?
Les langages fonctionnels sont bons car ils évitent les bogues en éliminant l'état, mais aussi parce qu'ils peuvent être facilement parallélisés automatiquement pour vous, sans que vous ayez à vous soucier du nombre de threads.
En tant que développeur Win32, puis-je utiliser Haskell pour certaines DLL de mon application? Et si je le fais, y a-t-il un réel avantage qui serait automatiquement pris pour moi? Si oui, qu'est-ce qui me donne cet avantage, le compilateur?
Est-ce que F # parallélise les fonctions que vous écrivez sur plusieurs cœurs et processeurs automatiquement pour vous? Avez-vous déjà vu le nombre de threads augmenter dans le gestionnaire de tâches?
Fondamentalement, ma question est, comment puis-je commencer à utiliser Haskell de manière pratique, et verrai-je vraiment des avantages si je le fais?
Il semble que le livre Real World Haskell soit exactement ce que vous cherchez. Vous pouvez le lire gratuitement en ligne:
F # ne contient pas de poussière de lutin magique qui transmettra des fonctions à différents CPU ou machines. Ce que F #/Haskell et les autres langages de programmation fonctionnels facilitent l'écriture de fonctions qui peuvent être traitées indépendamment du thread ou du CPU sur lequel elles ont été créées.
Je ne me sens pas bien de poster un lien ici vers un podcast auquel je participe, semble un peu décalé, mais dans l'épisode Herding Code où nous avons parlé avec Matt Podwysocki, nous avons posé la même question et il a donné des réponses intéressantes. Il y a aussi beaucoup de bons liens concernant la programmation fonctionnelle dans cet épisode. J'ai trouvé un titre de lien " Pourquoi la programmation fonctionnelle est importante " Cela peut vous fournir des réponses.
Cela pourrait également être intéressant: " Programmation fonctionnelle du monde réel "
Les exemples sont en F # et C #, mais la théorie est assez générique. D'après ce que j'ai lu (pré-version), c'est certainement intéressant, mais jusqu'à présent, je pense que cela me donne envie de rester de plus en plus avec C #, en utilisant des bibliothèques comme Parallel Extensions.
Vous n'avez pas mentionné, mais je suppose, que vous utilisez C++. Un moyen potentiellement facile d'entrer dans la fonctionnalité est via C++/CLI vers F #. C++ contient de la "poussière magique de lutin" (appelée IJW: It Just Works) pour vous permettre d'appeler et de sortir du code managé. Avec cela, appeler du code F # est presque aussi simple que depuis C #.
Je l'ai utilisé dans un programme (FreeSWITCH), qui est entièrement écrit en C/C++. Avec un seul C++/CLI géré (utilisez le commutateur/clr), il passe comme par magie en code managé, et à partir de là, je peux aller charger mes plugins F # et les exécuter. Pour faciliter encore plus le déploiement, F # peut lier statiquement toutes ses dépendances, vous n'avez donc pas besoin de déployer les fichiers d'exécution F #. Une autre chose qui rend le code CLR attrayant est que vous pouvez passer du code managé (délégués) au code C, et le runtime crée automatiquement un thunk pour vous.
Si vous décidez de suivre la voie Haskell, la fonctionnalité que vous rechercherez est FFI: Foreign Function Interface. Cependant, je ne pense pas que cela vous donnera le même niveau d'intégration que C++/CLI avec F #.
J'apprends actuellement Haskell moi-même, lorsque vous commencez à l'apprendre, cela ne semble pas très intriguant car l'expérience d'apprentissage n'est RIEN comme l'apprentissage d'un langage comme C #, c'est un tout nouveau monde, mais j'ai remarqué que je pouvais écrire très très complexe expressions en seulement quelques lignes de code, quand j'ai regardé le code, il était beaucoup plus concis, il était petit et serré. J'adore ça! Vous pouvez en effet écrire des programmes du monde réel qui seront plus petits, plus faciles à maintenir et beaucoup plus complexes que la plupart des autres langues le permettent, je vote pour que vous l'appreniez !!
Bonne chance.
Puisque vous mentionnez Win32 et les DLL, je suppose que vous travaillez avec du code non managé. Dans ce cas, GHC fonctionnera très bien pour vous. À la fin de l'année dernière, j'ai écrit un serveur DDE sous Windows en utilisant FFI pour parler aux bibliothèques MS DDE, et, étonnamment, ce fut une expérience extrêmement agréable (surtout compte tenu que je suis un gars Unix). Le FFI de Haskell est puissant (même en supportant, par exemple, les rappels dans les fonctions Haskell à partir de C ou d'autres bibliothèques), et avoir la vérification de type de Haskell lors de l'écriture de code de niveau C est comme un rêve devenu réalité.
Ce dernier point est l'un des avantages majeurs de Haskell: le système de typage est incroyable. Cela dit, c'est comme n'importe quel outil puissant; il faut du temps et des efforts pour en faire bon usage.
Alors oui, il est possible de commencer à écrire de petits morceaux de code dans Haskell qui se lient au reste de votre code (bien que vous puissiez trouver plus facile de commencer avec de petits programmes Haskell qui se lient à votre autre code), et cela vaut la peine d'être dépensé beaucoup de temps pour en savoir plus et l'utiliser partout où vous le pouvez. Vous pouvez finir comme moi, planifier un projet assez important étroitement intégré au code Windows (dans mon cas, un complément Excel sophistiqué) dans Haskell.