Hillel Wayne writes:
Some function programmers stay “shared mutable state is the enemy”. I think it’s more like “time is the enemy”, and time represents itself as mutable state. If a state update is purely internal and cannot affect the observable state (such as a statement in an uncommitted transaction), then it does not advance time.
I have been explicitly thinking about shared mutable state, inside and outside of computing, since Herb Sutter’s 2009 Sharing Is the Root of All Contention (and have, since becoming a father, greatly appreciated his “two children drawing with crayons” example). I interpret “shared mutable state is the enemy” in two ways:
- It is the enemy of computer performance (Sutter calls it scalability) due to coordination necessary to ensure state integrity in systems with shared mutable state.
- It is the enemy of human performance due to the cognitive overhead necessary to ensure state integrity in systems with shared mutable state.
Techniques like transactions (locks, mutexes, semaphores, etc.) are necessary for ensuring correctness and also help human performance by making the reasoning easier but they necessarily impact the computer performance. And so, while uncommitted transactions do not advance time (in Hillel’s wording), they are still the enemy in the first sense: they are the enemy of computer performance.
Last modified on 2024-08-29