The Parts Based Programming Kernel - by Paul Tarvydas

Programming Simplicity

SubscribeSign in

The Parts Based Programming Kernel<br>July 1, 2026

Paul Tarvydas<br>Jul 02, 2026

Share

Every system has a kernel — the irreducible core that makes everything else possible. For operating systems, it’s the code that loads programs, manages memory, and controls the CPU. For Parts Based Programming (PBP), the kernel is simpler: two things.<br>A template registry.

Coroutining.

That’s it. Let me explain what that means and why it matters.

A Simulation of Isolation

The PBP kernel runs on a single development computer, but what it simulates is a set of fully isolated, asynchronous components — each with its own private state, communicating only by passing messages.<br>This is a deliberate design choice, not a limitation. The shared-memory model that underlies conventional operating systems works fine on a single machine, but it breaks down badly when you try to scale across geography. You can’t share memory between machines in Tokyo and Toronto. You can pass messages. If you write your software from the start using PBP’s isolated-component model, it scales to distributed systems naturally — because the architecture never assumed shared memory in the first place.

What the Kernel Does

When you draw a diagram in PBP, that diagram becomes a template. Boxes become parts. Connections become message routes. The visual is the program.<br>A single drawio file can contain many drawings, each on a separate editor tab. Each drawing is a Container part. Any part on a drawing that doesn’t correspond to another drawing is assumed to be a Leaf part — an atomic component that does actual work without containing other parts. Containers are converted by das2json into machine-readable JSON that lists their children and the routing between them. Leaf parts are simply assumed to exist — assumed to be imported by the main program (e.g. main.pywhen Python is the host language).<br>When a PBP system starts up, it does three things in sequence:<br>First, it loads all the templates. Container parts are loaded from those JSON files. Container parts are automatically registered when their JSON is read. Leaf parts must be declared in code using mkTemplate(...) and explicitly registered withregister_component(...). All Leaf parts must be registered before the system can run.<br>Second, it instantiates. Starting from the top-most Container, the runtime recursively creates unique instances of every part, all the way down through the hierarchy to the leaves.<br>Third, it runs. The top-most Container walks its children. Each Container processes one input message-event (mevent) at a time, ticking each child in a loop until that child has no more work to do. Containers can hold Containers, so this walk is recursive. When you hit a Leaf, the recursion stops — Leaves don’t contain anything; they just act.<br>This is a clean, explicit, traceable execution model. No surprises.

Sound Familiar? It Should.

This is almost exactly what an operating system does — and coroutining is what OSes do under the hood.<br>An OS loads a program: reads the object file (.obj, .o, or whatever), fixes up addresses, tweaks the MPU, then hands control to the code. That’s the registry and instantiation steps. Then the OS scheduler takes over — and the scheduler is, at its core, a coroutine manager.<br>The scheduler keeps a list of ready threads and algorithmically picks one to run. It then does something remarkable: it saves the entire state of the currently running thread — registers, stack pointer, program counter — into a privileged block of OS memory, loads the saved state of the chosen thread, sets a hardware timer, and yields to it. From that thread’s point of view, it simply resumed. When the timer fires, an OS interrupt handler forces the thread to yield back to the scheduler, and the cycle repeats.<br>Each thread looks like a plain function (or a chain of functions), but it is actually a state machine whose state is being saved and restored by the scheduler on every context switch. The OS is doing coroutining, just wrapped in layers of hardware privilege management, timer interrupts, and memory protection machinery.<br>PBP makes the coroutining explicit and visible, without the machinery.

The 20th Century Tax

Operating systems got this complicated to solve a specific 1960s problem: CPUs were expensive. One CPU, many users. You had to time-share.<br>Time-sharing is where the complexity explosion happened. If you have 10 apps and 90 OS threads running, each app gets roughly 1/100th of a CPU — give or take, modulo complicated priority management, scheduling queues, and preemption logic. The software architect doesn’t get to control any of it. Start a new app or thread and it silently steals cycles from everything already running.<br>This also gave us “thread safety” — an entire category of bugs that exists solely because multiple threads share memory on a single CPU. Mutexes, semaphores, lock-free data...