Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...?
If you're looking for a challenge, how about this one (there used to be lots of Haskellers into this game, any of you still around?-): http://computer-go.org/pipermail/computer-go/2008-October/016680.html The specification is the numbered list at the end of the message, or in the zip file with the Java example implementation (README). Actually, the interesting part from a performance perspective doesn't even require GTP or AMAF, just implement the random legal playouts for a 9x9 board, do a loop over them, keeping some basic win/loose/game length statistics. Can you complete that in competitive speed, preferably from the specs, without just transliterating the low-level Java code? I won't tell you yet what typical playouts-per-second-per-core numbers are floating about for "lightly" optimised code; try to improve your code and say "stop, this is good enough" before comparing with the Java bot runtimes. You'll probably have no room left for any high-level operations, ending up with mostly imperatively threaded array manipulations in a loop that is expected to be run several thousand times per real-game move (the idea being to run lots of dumb, but legal, simulations to the end, where evaluation is easy, gather statistics, then choose the move that seems to have the most potential). Bonus points if you can preserve any of the high-level advantages of working in Haskell (such as easy debuggability, because there will be bugs, especially if you can't afford to maintain redundant information representations) without sacrificing speed. (*) As specified, the bot won't win any tournaments - it is the starting point (or remote ancestor) for the current champions, with lots of room for algorithmic improvement, not to mention actual game knowledge, tree search and parallelization (the configurations being used for tournaments and exhibition games are highly parallel). The reference spec is a recent effort, meant to provide a first milestone for aspiring Go programmers to compare their code against, while also inviting programmers to to show how their favourite language is eminently suitable for Go programming (without sacrificing performance!). There are versions in Java, D, C++, C#, and C around somewhere, possibly others. But: please, no language evangelism on that mailing list! Those people seem decent, peaceful and open-minded (there's even a Haskell spec of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ). And some of them have years (a few even decades) of experience, much of which is made available in the mailinglist archives and bibliography (pointers available on request - if you wanted to get serious about playing with Go programming, you'd be expected to mine the archives and bibliography, because just about anything you'll come up with in your first few months will have been discussed already;-), in spite of commercial interests and ongoing competitions. They are already tired and wary of useless language wars (who isn't?). Claus (who has been wanting to write a Go player ever since he had to decide between research and learning more Go, either one trying to eat all available time and then some; perhaps I should write a researcher instead, and return to playing Go?-) (*) it would be nice if the sequential baseline performance of functional Haskell/Ghc arrays would be better, btw; that would make the ongoing work on parallel arrays much more interesting.