In the electronic and bureaucratic control systems, changing state is the point of the program. The thinking revolves around state, when it should be update

In the electronic and bureaucratic control systems, changing state is the point of the program. The thinking revolves around state, when it should be updated, and what it should be updated to. Stuffing this all behind a monad results in unnatural-feeling programs. Changing state is the point of almost any long-running user-facing application. And you are correct, thinking about when state should be updated and what it should be updated to is very important. So important in-fact, that allowing state updates to occur anywere in the program, with no rhyme nor reason, dramatically reduces an engineer’s ability to understand that program. It may feel natural, or familiar, or easy to change state wherever it is convenient to do so. But that doesn’t make it a good engineering decision. As I mentioned in another comment it introduces complexity around logical reasoning, future change, code re-use, and testing. It is much simpler if you define your application’s state in one place, and in terms of the actions that can be performed to update the state. This is simple, and easy to reason about. Then the functions to update the state can be pure. Again, this is simple, and easy to reason about.