>>29
yeah, there are many algorithms that depend on mutable state in order to obtain their run times. And there are many examples of applications where using only immutable data structures wouldn't be that great of an option. A good example would be a video game, where all entities need to be aware of changes made to other entities. This can be made functional by storing all entities in an environment data type, and making a full copy of the environment with added changes to the entities, every time the game advances a step. This sounds horrible, but it can be made efficient by double buffering the objects, IE, you have two allocated environments, and upon every tick, you swap which one is in use, assigning the new state into the previously unused one, while referring to the previously used environment to construct the new entities. A typical imperative solution would be to iteravely call an update function on every entity in the environment, modifying each in place. This can create strange effects though, as the order in which the update function is called on the entities can cause strange effects. Like, say characters A and B were to punch each other hard in the face, at the exact same time. Using the functional approach, both A and B in the next state would be knocked out, because they were punched by B and A in the previous state respectively. In the in place modification approach, say A's update function is called first, and A punches B out cold. Then when B's update function is called, B is unconscious, and no longer able to knock out A. So the results differ. This effect can be made less significant by maintaining a high frame rate, as interesting things are less likely to happen at the same time, but in some other applications there is no way to get around it. IE, there are sometimes dynamic interactions that occur in every frame, and the order of application of the update function can cause very strange artifacts in the simulation.