Question

Les langages fonctionnels sont bons parce qu’ils évitent les bugs 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 at-il un avantage réel qui serait automatiquement utilisé pour moi? Si oui, qu'est-ce qui me donne cet avantage, le compilateur?

F # parallélise-t-il automatiquement les fonctions que vous écrivez sur plusieurs cœurs et cpu? Souhaitez-vous jamais voir le nombre de threads augmenter dans le gestionnaire de tâches?

En gros, ma question est la suivante: comment puis-je commencer à utiliser Haskell de manière pratique et verrai-je réellement des avantages si je le fais?

Était-ce utile?

La solution

Il semble que le livre Real World Haskell soit exactement ce que vous recherchez. Vous pouvez le lire gratuitement en ligne:

http://book.realworldhaskell.org/

Autres conseils

F # ne contient pas de poussière magique de lutin qui transmettra des fonctions à différents processeurs ou machines. F # / Haskell et d’autres langages de programmation fonctionnels facilitent l’écriture de fonctions pouvant être traitées indépendamment du thread ou du processeur sur lequel elles ont été créées.

Je ne me sens pas bien de poster ici un lien vers un podcast auquel je participe, ça semble un peu bizarre, mais dans l'épisode Herding Code où nous avons parlé à 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 des titres de lien " Pourquoi la programmation fonctionnelle est importante " Cela pourrait vous apporter quelques réponses.

Cela pourrait aussi être intéressant: " Programmation fonctionnelle dans le 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 (version préliminaire), 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 le C ++. Un moyen potentiellement facile d’être fonctionnel est de passer de C ++ / CLI à F #. C ++ contient de la "poussière de lutin magique" (appelé IJW: It Just Works) pour vous permettre d’appeler et de sortir du code géré. Avec cela, appeler du code F # est presque aussi simple que de C #.

Je l'ai utilisé dans un programme (FreeSWITCH), entièrement écrit en C / C ++. Avec un seul C ++ / CLI géré (utilisez le commutateur / clr), il se transforme comme par magie en code managé et à partir de là, je peux charger mes plug-ins 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 géré (délégués) au code C, et le moteur d’exécution génère automatiquement un thunk pour vous.

Si vous décidez d'utiliser la méthode Haskell, la fonctionnalité que vous recherchez est l'interface 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 à apprendre, cela ne semble pas très intriguant, car l'expérience d'apprentissage n'a rien à voir avec l'apprentissage d'une langue comme C #, c'est un tout nouveau monde, mais j'ai remarqué que je pouvais écrire. expressions très très complexes dans seulement quelques lignes de code, quand j'ai regardé en arrière le code était beaucoup plus concis, c'é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 vous de l’apprendre !!

Bonne chance.

Puisque vous mentionnez Win32 et les DLL, je suppose que vous travaillez avec du code non géré. Dans ce cas, GHC fonctionnera très bien pour vous. L'année dernière, j'ai écrit un serveur DDE sous Windows en utilisant FFI pour discuter avec les bibliothèques MS DDE et, chose surprenante, ce fut une expérience extrêmement agréable (surtout si je suis un gars sous Unix). Le FFI de Haskell est puissant (il prend même en charge, par exemple, les rappels dans les fonctions Haskell à partir de C ou d'autres bibliothèques), et vérifier le type de Haskell lors de l'écriture de code au niveau C est comme un rêve devenu réalité.

Ce dernier point est l’un des principaux avantages de Haskell: le système de types 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 sont liés au reste de votre code (bien que vous trouviez peut-être plus facile de démarrer avec de petits programmes Haskell qui sont liés à votre autre code), Cela vaut vraiment la peine de passer assez de temps à apprendre à ce sujet et à l’utiliser chaque fois que vous le pouvez. Vous pouvez vous retrouver, comme moi, à planifier un projet assez important étroitement intégré au code Windows (dans mon cas, un complément Excel sophistiqué) sous Haskell.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top