3 minutes reading time
A piece of software has to start with an idea. An idea to perform some action. An action in some context, some problem domain.
But we also need to know how to build it. Which user interactions exist? How should outputs be presented? What data do we need to process? Which states can the software be in? Are there existing concepts we can reuse?
Based on the answers to these questions, we can start shaping our software, give it some structure. We can split problems into parts, define interfaces, group elements into modules and link them together. Even if the structure is not explicit, some representation of it exists in our minds while we work on the source code. But it does remain in the realm of concepts. After the compiler ingests our code and spits it back out as a binary, few traces remain.
During execution, a program lives in memory. Any data it consumes and produces must exist in memory at some point. Memory is what the CPU operates on. What the values represent is context dependent. Some bytes are instructions that the CPU runs, grouped into functions, themselves grouped into libraries. Other bytes are data, where we even use the keyword struct to tell the compiler how we want to interpret a number of bits. Some bytes may even start out as data, but will be executed as instructions later.
Even though all of that happens in a linear address space, the connections, reads, and writes usually form a complex web. Functions refer to other functions to call them. Data references other data to model concepts in the problem domain. Functions manipulate data, reading and writing from memory. Data stores function pointers to dynamically dispatch to at runtime. Everything spread throughout dense and sparse memory blocks received from the operating system.
Code is data, and data is code. The cross-references in the data form trees, graphs, webs, and sometimes spaghetti.
When we look at the changes of a program over time, more structure reveals itself. Let's take a look at the update loop of an immediate mode UI application, where the interface gets fully re-rendered every frame. Starting from the root, each parent, recursively draws its children. Setting a breakpoint and traversing up the stack lets us walk along the UI hierarchy. Repeating this for procedure for each leaf element will give us a tree. That tree is the UI.
But drawing the interface is only half the battle. We draw the UI to read input to update the state. Changes in state produce changes in memory. Values change. New memory regions may be allocated and others freed. References are updated. After everything has settled and we draw the next frame, maybe the changes in the data prompt the CPU to take different branches this time. This results in a different call-tree, and we draw a changed UI.
The UI is a function that transitions the data from one state to the next. One path through the space of transitions produces a sequence of states in time. The set of possible transitions form a structure that hopefully matches the concept we're modelling.