Even if we factor state into a monad and/or pass it in as a parameter, imperative updates still exist and must be dealt with! Try writing a type checker or even a parser with pure functions, and you get to a point where you are passing in your state from the top anyways (either as a monad or explicitly). Many interesting computations simply aren't pure.

> Separating the grok of the code from the state eventually helps. And sadly there is little research spent in there, which is direct value to developers.

I would argue that there is plenty of research in this direction in the functional programming community. This is what monads seem to be about, at any rate. The problem is that developers don't want to adopt these solutions because they are way too inconvenient or even unworkable from an expressiveness standpoint. So maybe we should look for a better way to temper state without throwing it into a ghetto...

> I am amazed with what you can do though. I've had my shot at designing a language and miserably failed multiple times... But this why I'm raving about it... You may be able to solve this global problem that I never could.

We will see; I went through my purity stage relatively early and am being extremely pragmatic these days. The secret sauce in my current approach is to have state, but limit how it can be updated: operations in Glitch must be undoable and commutatively ordered, which are huge restrictions but the result is very compelling (re-execution is possible AND re-execution can occur in arbitrary orders).