haskell systems that - How can I use functional programming in the real world?

3 Answers

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.

network logic to

Functional languages are good because they avoid bugs by eliminating state, but also because they can be easily parallelized automatically for you, without you having to worry about the thread count.

As a Win32 developer though, can I use Haskell for some dlls of my application? And if I do, is there a real advantage that would be taken automatically for me? If so what gives me this advantage, the compiler?

Does F# parallelize functions you write across multiple cores and cpu's automatically for you? Would you ever see the thread count in task manager increase?

Basically my question is, how can I start using Haskell in a practical way, and will I really see some benefits if I do?

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.