Transformation

Mutation vs Derivation

In the mutable view, the board is a living thing that changes.

When a player moves a piece, we don't create anything new. We update what exists. The pawn that was on e2 is now on e4. The same pawn, different location. The board transforms.

This is how we naturally think about physical objects. When you move a chair across the room, you don't create a new chair---you move the existing one. The chair changes position.

The Act of Change

In the mutable view, change is direct. We reach into the world and alter it.

Natural Language	Notation
Move the pawn from e2 to e4	board[e2] = empty
	board[e4] = pawn

After these two operations:

The old arrangement is gone. If you wanted to know what e2 contained a moment ago, you cannot---that information has been overwritten.

The square e2, which held a pawn, now holds nothing
The square e4, which was empty, now holds the pawn
The board has transformed

The Whiteboard Analogy

Imagine a whiteboard in a meeting room. Someone writes "Project: Alpha" at the top. Later, the project is renamed. They erase "Alpha" and write "Beta."

The whiteboard still exists. The marker still works. But "Alpha" is gone---truly gone, not hidden or stored elsewhere. The whiteboard has one state, and that state just changed.

This is the mutable view of the world. Objects persist, but their contents transform. The container remains; the contents change.

A Chess Move in the Mutable World

Let's trace through a complete move. White's knight on g1 moves to f3.

Before the Move

Knight at g1, about to move to f3

The knight sits on g1. The destination square f3 is empty.

python

    g1: white knight   <-- source
    f3: empty          <-- destination

The Transformation

Now the move happens. We reach into the board and change it. But notice: we make two alterations---two assignments to our state:

python

    board[g1] = empty           // first alteration
    board[f3] = white knight    // second alteration
    turn = black                // third alteration

But wait---there's a problem. When we clear g1, we lose the knight! How do we know what to put in f3?

The Temporary Memory

We need to remember the piece before we erase it. This requires a local variable---a temporary storage that lives only for the duration of this operation:

python

    piece = board[g1]       // remember the knight
    board[g1] = empty       // now safe to clear
    board[f3] = piece       // place the remembered piece
    turn = black

This variable piece is a small, short-lived state. It exists only within this context---this brief moment of computation. Once the move is complete, it disappears, as if it were temporary memory.

But notice the cognitive cost: we must now track four things in our minds:

The board (and its squares)
The turn
The variable piece
The sequence of steps (order matters!)

An Abstraction: Avoiding Local Variables

What if we could avoid the local variable entirely? We can, with a small abstraction. Instead of:

python

    piece = board[g1]
    board[g1] = empty  
    board[f3] = piece

We could express it as a swap---a single operation that describes the transformation:

python

    board[f3] = board[g1]   // f3 becomes what g1 has
    board[g1] = empty       // g1 becomes empty

Or even more declaratively, with an update facility:

sql

    board = move_piece(board, from: g1, to: f3)

Here, there is no local variable. No temporary state to track. Just a description: "the board after moving the piece from g1 to f3." The complexity of remembering is pushed inside the abstraction.

This is more succinct. More declarative. Almost atemporal---we describe the relationship between before and after, not the sequence of steps.

But we are still in the mutable world. The board changes. The old state is gone.

After the Move

Knight now at f3, g1 is empty

The board has transformed:

python

    g1: empty          <-- now empty
    f3: white knight   <-- piece is here

There is no "before" state stored anywhere. There is only "now."

The Flow of Time

In the mutable view, time flows forward and leaves no trace. Each moment overwrites the last.

state $→$ state $→$ state $→$ …

There is always exactly one state---the current one. The arrow represents transformation: the state changes into something new, but it remains the same state object, modified.

This is efficient. We don't need to store multiple copies of the board. Memory holds one board, and we update it as needed.

But something has been lost. The past.

What We Gain

The mutable approach offers:

Efficiency: — One copy of the state, updated in place. Minimal memory.
Familiarity: — This mirrors physical reality. Objects change.
Simplicity: — No need to think about multiple versions. There is only now.

For many programs, these advantages are compelling. Real-time games update positions sixty times per second. Databases modify records. Spreadsheets change cells.

What We Lose

But something is lost:

History: — The past is gone. We cannot revisit it without extra work.
Safety: — If two processes try to change the board at once, chaos.
Certainty: — We cannot reason about "the board" in the abstract---which version?

The mutable world is powerful but forgetful. It lives entirely in the present.

In the next chapter, we explore a different view---one where nothing is ever lost, because nothing ever truly changes.