People often say state is hard in functional programming, but things like the Tardis monad have convinced me that (semantically speaking) functional programming is even better at state than the imperative/OOP paradigms. Imperative programs are essentially restricted to one global monad implicitly hardcoded into the language semantics, whereas with functional programming you have the freedom to choose the most appropriate monad for the task at hand. You want state? Use the state monad. You want continuations? Use that monad. You want time traveling? Yep, there's a monad for that too. IO, randomness, nondeterminism, parallelism, environment variables, failure, backtracking, software transactional memory, you name it. Many problems are best solved with a custom monad, rather than one of the standard ones; for example, using a monad that allows your code to emit constraints to be solved (this is a common technique for implementing type inference in compilers). Satisfyingly, reifying effects with monads preserves referential transparency and is therefore compatible with laziness, unlike traditional side effects which are sensitive to evaluation order.