Mike,
I'm evaluating several high-level languages as development vehicles for our next suite of applications.
.. just code some really simple problems. Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a "master" state holder and many slaves. Or quicksort. Etc. etc.
I would be careful about using your experience with these toy programs as an indication of how suitable functional languages (and lazy ones in-particular) are as 'development vehicles' for your applications. A functional programmer's idea of a 'toy' program tends to be somewhat different from a C++/GUI programmers one. Lazy functional languages lend themselves nicely to parsing, list processing, search trees and the like - but if you're planning to load a wave file, apply a filter and then display the result on the screen .. then let's just say that you've got an adventure ahead of you, and it's not going to take 2 weeks. ... as far as GUIs are concerned, check out http://www.haskell.org/libraries and look at how many seperate GUI libraries there are - I counted 16 - then ask what made the developer for the 16th one choose to start over.
Haskell is lazy all the time. That's awfully nice...I'm not sure if there's a performance penalty somewhere, but assuming there isn't, kudos to it.
There is.. and its name is 'space leak'.. and the function mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) is by far the most elegant way of expressing it :) BTW: I've just dedicated the next 3 years of my life to trying to write non-toy programs in lazy functional languages... "adventure" is the operative word.. not "can't". Ben.