Evaluation

When we derive state_1 from state_0, how much actually changes? In a chess move, typically:

A clever implementation doesn't copy those 62 unchanged squares. It shares them. Both state_0 and state_1 point to the same underlying data for everything that didn't change.

• Two squares change (source becomes empty, destination gets piece)
• Turn changes
• 62 squares remain exactly the same

    state_0 and state_1 share:
        - 62 unchanged squares
        - All piece definitions
        - Game rules
    
    state_1 has its own:
        - 2 changed squares
        - turn value

The memory overhead shrinks dramatically. Instead of 41 complete boards, we have one "base" plus small deltas for each change.

In the mutable approach, the previous state is gone. To support undo, we must explicitly save history:

    history = []
    
    before each move:
        history.push(copy of current board)
    
    to undo:
        current board = history.pop()

We end up copying anyway! The mutable approach, to support undo, must become partially immutable.

In the immutable approach, undo is trivial:

    states = [state_0, state_1, state_2, ...]
    current = states[2]
    
    to undo:
        current = states[1]  // just point to the previous state

The previous states were never destroyed. Undo means pointing to an earlier state. Nothing is copied; nothing is reconstructed.

Imagine two players, Alice and Bob, both try to move at once:

    Alice: move knight g1 to f3
    Bob:   move pawn e7 to e5
    
    Time 1: Alice reads g1 (knight)
    Time 2: Bob reads e7 (pawn)
    Time 3: Alice writes g1 = empty
    Time 4: Bob writes e7 = empty
    Time 5: Alice writes f3 = knight
    Time 6: Bob writes e5 = pawn

This might work---or it might not. What if Alice's move depended on reading e7? What if the writes interleave differently? The result is unpredictable.

Mutable systems require careful coordination: locks, semaphores, transactions. Complexity grows.

In the immutable approach, Alice and Bob each receive state_0. They each derive a new state:

    state_0 -> (Alice's move) -> state_1a
    state_0 -> (Bob's move)   -> state_1b

No conflict! They're not modifying the same thing. They're each creating something new from a shared, unchanging origin.

The question of "which state wins" remains---but it's a logical question, not a technical catastrophe. Neither computation corrupted the other.

In the mutable world, a function might:

• Modify its inputs
• Modify global state
• Behave differently depending on when you call it

To understand what make_move(board, move) does, you must trace through the code, tracking every modification. You must consider what else might be modifying board simultaneously.

In the immutable world, a function:

• Cannot modify its inputs (they're immutable)
• Returns a new value
• Given the same inputs, always returns the same output

To understand what make_move(state, move) does, you look at its definition. That's all. The function is a pure relationship between input and output.