There are really only two types of computations: calculating stuff about an unchanging thing, and calculating a new version of a thing that is changing over time. Recognizing this simplified debate about functional versus imperative programming.
If you have an imperative program and can’t identify “the thing”, then the thing is the entire state of your program. To translate that to a functional program, you’d need to plumb the thing into and out of every function in your program.
This transformation is doable, but the problem is that references inside the original imperative program have to be turned into some sort of representation of the entire path from the top level state object to the thing the reference can be modified.
Hence I think the sweet spot for large-scale programming is an imperative language with a pure functional subset, not a functional language with imperative plumbing like Haskell monads. Then the beast that needs to be tamed is data races in the shared state concurrency model.
In an engine, “the thing” is the scene graph. The simulation updates it once per frame based on object interactions. Then perhaps there are several much smaller independent things, like the state of the input system, the network replication system, and so on.
