If you mix FP and OO you'll often end up with terrible FP which simply reproduces the "old" approach: lots of mutable stuff everywhere. Many Clojure toy games are like that: they start with a lot of "variables" in mutable refs.
But it doesn't need to be that bad: you can create a game that is fully deterministic. A game which is purely a function of its inputs. And it can of course be applied to more than games.
The problem is that it feels "weird" to non-FP people.
The state monad is definitely what you're looking for. If you use a state monad approx. 95% of what you just wrote is utter rubbish.
But the state monad (and the maybe monad) sadly aren't that trivial to understand.
> If you mix FP and OO you'll often end up with terrible FP which simply reproduces the "old" approach: lots of mutable stuff everywhere.
What I'm suggesting is that mutable state isn't inherently bad. It's entirely possible that we will someday enter a new age of mainstream, pure FP where we look back at mutable state and cringe. But that's pure speculation. Our current world is full of successful applications written in languages built on mutable state.
So I'm not saying that mutable state is inherently better than the alternatives. Just that the case against it--and for the alternatives--has to be pretty darn compelling to outweigh the tremendous real-world success of languages like Ruby, Python, JavaScript, and so on.
I wouldn't call what you've written a straw-man argument, but neither is it a steel-man...
My biggest takeaway, and an entirely legitimate criticism, is that if all your functions become instead State World (), your type signature no longer gives you much information about what the function does. In light of this I intend, when/if I get around to playing with a game in Haskell (or anything else that involves shipping around a huge wad of state), to look into splitting types of game state changes into multiple typeclasses, so as to see about preserving some more information about what various state transformations touch (both reading and writing)...
But it doesn't need to be that bad: you can create a game that is fully deterministic. A game which is purely a function of its inputs. And it can of course be applied to more than games.
The problem is that it feels "weird" to non-FP people.
The state monad is definitely what you're looking for. If you use a state monad approx. 95% of what you just wrote is utter rubbish.
But the state monad (and the maybe monad) sadly aren't that trivial to understand.