Functional programming was invented by Backus to solve the problem of interchangeable parts. Unfortunately, he did not finish his work, and as a result people are still trying to paper over the missing hole in the theory. State monads as described above make the process of storing and manipulating state a very obscure and mysterious process. This additional complexity and abstraction can only add to the lifecycle cost of software generated using this technique, with an attendant increase in maintenance cost. If you were to take a 10 year old, and give them basic training, would they be able to understand this? I doubt it, yet computers at their core are incredibly simple. So a better paradigm awaits.
The state monad, in spite of the scary name, is an incredibly simple idea, being about functions with this signature:
S => (A, S)
That’s it. Of course this doesn’t include the definition of the monad instance, however those operations come very naturally from trying to work with, to manipulate these functions. In fact many people reinvent the state monad.
Furthermore this does a great job of simplifying impure functions that manipulate state, because for those functions the state evolution does not appear in the signature. Or in other words the state is still there, as an implicit input and output to your function, but the type system can no longer protect you and the function's output will be dependent on the history of all previous function calls. That's anything but simple.
And yes, I believe you can explain it to 10 year olds. If the 10 year old can understand functions, he can understand this as well. Your grandma might have a problem with it though.
You are returning new state of the world with every call that modified it and using monad guarantees your calls are sequential. Where is the obscurity?
