在现实世界中如何使用函数式编程?

函数式语言很好,因为它们通过消除状态来避免 bug,还因为它们可以很容易地为您自动并行化,而不必担心线程数量。

但是,作为一个 Win32开发人员,我可以为我的应用程序的一些 dls 使用 Haskell 吗?如果我这么做了,有没有一个真正的优势会自动为我所用呢?如果是这样,是什么给了我这个优势,编译器?

F # 是否能够自动将您编写的函数并行化到多个核和 CPU 上?您是否曾看到任务管理器中的线程数量增加?

基本上,我的问题是,我如何开始以一种实际的方式使用 Haskell,如果我这样做,我真的会看到一些好处吗?

19559 次浏览

I'm currently learning Haskell myself, when you start out learning it, it doesn't seem very intriguing because the learning experience is NOTHING like learning a language like C#, it's a whole new world, but I noticed I could write very very complex expressions in just a few lines of code, when I looked back at the code it was much more concise, it was small and tight. I'm absolutely loving it! You can indeed write real-world programs that will be smaller, easier to maintain, and much more complex then most other languages allow, I vote for you to learn it!!

Good luck.

F# does not contain any magic pixie dust that will pass functions off to different CPU's or machines. What F#/Haskell and other functional programming languages do is make it easier for you to write functions that can be processed independent of the thread or CPU they were created on.

I don't feel right posting a link here to a podcast I participate in, seems a little off, but in the Herding Code episode where we talked with Matt Podwysocki we asked the same question and he gave some interesting answers. There are also a lot of good links relating to functional programming in that episode. I found one link titles "Why Functional Programming Matters" That may provide some answers for you.

It seems like the book Real World Haskell is just what you're looking for. You can read it free online:

http://book.realworldhaskell.org/

This might also be interesting: "Real World Functional Programming"

Examples are in F# and C#, but the theory is fairly generic. From what I've read (pre-release) it is definitely interesting, but so far I think it is making me want to stick more and more with C#, using libraries like Parallel Extensions.

You didn't mention, but I'm assuming, that you're using C++. One potentially easy way to get into functional is via C++/CLI to F#. C++ contains "magic pixie dust" (called IJW: It Just Works) to allow you to call into and out of managed code. With this, calling F# code is almost as simple as it is from C#.

I've used this in one program (FreeSWITCH), which is written entirely in C/C++. With a single managed C++/CLI (use the /clr switch), it magically transitions into managed code, and from there, I can go load my F# plugins and execute them. To make things even easier for deployment, F# can statically link all its dependencies, so you don't need to deploy the F# runtime files. One other thing that makes CLR code attractive is that you can pass managed code (delegates) to C code, and the runtime automatically makes a thunk for you.

If you decide to go the Haskell way, the feature you'll be looking for is FFI: Foreign Function Interface. However, I don't think it'll give you the same level of integration as C++/CLI with F#.

Since you mention Win32 and DLLs, I presume you're working with unmanaged code. In that case, GHC will work very well for you. Late last year I wrote a DDE server under Windows using FFI to talk to the MS DDE libraries, and, surprisingly, it was an extremely pleasant experience (especially given that I'm a Unix guy). Haskell's FFI is powerful (even supporting, e.g., callbacks into Haskell functions from C or other libraries), and having Haskell's type checking when writing C-level code is like a dream come true.

That last point is one of the major advantages of Haskell: the type system is amazing. That said, it's like any powerful tool; it needs time and effort to make good use of it.

So yes, it is possible to start out writing small bits of code in Haskell that link into the rest of your code (though you may find it easier to start with small Haskell programs that link to your other code), and it's well worth spending a fair amount of time learning about this and using it wherever you can. You may end up like me, planning a fairly major project tightly integrated with Windows code (in my case, a sophisticated Excel add-in) in Haskell.