don't think in terms of modifying state, think of it as computing new values from old values. I find that the payoff of learning to think ,like this is massive, as it's usually much easier to reason about. </qoute> Indeed. [warning: what follows is a rant with a purpose:] The imperative/OO guys have learnt this as well, and the result comes under different names, e.g., "a service component should be stateless", "stateless session bean", "refactoring: introduce state object". It's kind of funny how they re-invent functional programming (in several places, e.g. "composite pattern" = algebraic data type, "visitor pattern" = fold, "iterator pattern" = lazy list). ... after trying to avoid the truth for some 20 years or so. You're exactly right, the functional/declarative way is "much easier to reason about", and this matches the observation that there was not much reasoning going on during these decades instead, just hacking, and then some testing. Well, they even finally admitted one should write the tests before coding. Yes, that's called specification before implementation, and that's what Dijkstra had been teaching for ages, e.g., http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1305.html Still, given their strange approach to programming, the imperative/OO guys have rather brilliant tools for developers. No surprise, without them they'd be lost immediately. But we have http://leksah.org/ , and there's a GSoC project for eclipsefp . [now, the punchline:] (for extended rants on the subject, register for http://www.iba-cg.de/hal4.html ) -- View this message in context: http://www.nabble.com/using-haskell-for-a-project-tp23348425p23353526.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.