Sequential Code and Hidden Runtime State
May 27, 2021

Software-architecture noteOriginally posted 2021-05-27; rewritten here around sequential source code and hidden runtime state.

Included: instruction pointers, event order, state ownership, locality, parallel work, and why a program can be hard to reason about even when each function is readable.

The Sequential View Hides Runtime Shape

Sequential source code is readable because it gives one line after another. A running application is often not that simple. It may have event handlers, timers, queues, workers, sockets, caches, subscriptions, GPU kernels, browser callbacks, or devices that all affect state at different times.

The instruction pointer is a useful local explanation. It becomes a weak global explanation when the important behavior is distributed across many active boxes.

Why the Circuit Analogy Helps

A circuit forces the reader to ask where state lives, which paths can change it, what happens on a clock boundary, and which values are local. Software needs the same questions once the program becomes event-driven or parallel.

The goal is not to make all software look like hardware. The goal is to preserve enough runtime structure that a future change can be made without guessing which hidden state will move next.

Useful Scope

The practical target is source code that keeps event order, ownership, locality, and failure visible. That matters for live feeds, background workers, remote-control paths, browser state, database migrations, and parallel computation.