I think the idea behind immutability is as follows. Given X, we are completely comfortable with applying functions to X which take it from its current domain t

I think the idea behind immutability is as follows. Given X, we are completely comfortable with applying functions to X which take it from its current domain to a different one. These functions are composable. f: X -> Y g: Y -> Z g . f : X -> Z The "state" is transforming from one operation to another. The TWO tricky parts are how the initial state is populated, and how the state is presented to the enduser. Good programming practices involve isolating these two endpoints from the code logic that does this change anyway. As I see it, Haskellers will have two "dirty" modules which handle I/O with monads, and a lot of pure modules that are very easy to reason about. However, doing this requires discipline and employing a certain coding style that many are not used to. Having worked with Haskell a lot, my programming style in other languages has improved a fair bit, and I intend to revisit Haskell for possible production use in the near future.