Try to implement infinite levels of undo in an imperative solution. The functional approach makes it trivial, since everything in the simulation is just a big reduce function applying a sequence of changes to a state object. Mutable state on the other hand, makes it very hard to write.
I'm sure you're right about infinite levels of undo being hard to implement in an imperative language. I do think functional languages have a lot going for them (even though I didn't think the original post made a very convincing case for functional languages).
I would be interested in hearing what advantage anybody thinks "infinite undo" would bring to a scientific simulation. I can sort of conjure up a scenario where you're doing a probabilistic optimization, and you want to be able to re-visit every single time step, in order to perturb the boundary conditions and watch how the system evolved differently. But the cost of storing all the meaningless "false" states that the solver generated as it searched around in the solution space for each time step, hardly seems worth it (compared to, say, some kind of way-pointing capability, which many scientific software programs have got already).
Infinite levels of undo does sound like something that would cause a big memory leak for a long-running simulation. It could be accomplished in an imperative language if it was written in a functional style (assuming the language is sufficiently powerful).
I didn't quite follow your comment. If the imperative solution tracks a list of changes why couldn't it implement infinite levels of undo in a similar fashion to the functional approach?
It's a question of persistent data structures and sharing. Efficient code without mutability tends to recreate only the parts that change, and so you don't have to store a fresh copy of the whole world each update. Of course there is nothing preventing you from doing this in an imperative language, but a preference for mutability discourages it.
