From my experiences with Haskell, it takes a long while to get used to Haskell, but once you do it really pays off, especially in the area of maintainability. I

From my experiences with Haskell, it takes a long while to get used to Haskell, but once you do it really pays off, especially in the area of maintainability. It's actually one of the reasons I love Haskell so much. I've been where you are though, and I feel your pain - if you keep at it, it'll get good, promise. Some things I find help with maintainance : * the type system allows the compiler do a lot of work for you, * types have to be concrete rather than abstract, * if a little effort is applied the unit tests can be amazing, * everything's clearly defined, * codebases tend to be a bit smaller, and once you're used to it, more readable. In the particular situation you describe, maybe using the "take" function could work? Yes, the IO stuff can be tricky, I agree, but with practise it's not too bad, and separating IO from pure code gives all sorts of goodness back. There's always Debug.Trace if you need to do a quick bit of debugging by print statements. I feel the article was being unfair on Haskell there, after all the code example was being deliberately unreadable, and that's possible in any language. It's not really that hard: map (2^) [1..]