Programming Simplicity

TDPL, BUPL, and the Trade-Off We Never Revisited

Paul Tarvydas — Mon, 31 Aug 2026 20:50:05 GMT

There’s an old, slightly obscure acronym worth resurrecting: TDPL, “Top-Down Parsing Language.” It was coined by Aho and Ullman in The Theory of Parsing, Translation and Compiling, describing formal work Alexander Birman had done a couple years earlier under the name “TMG Schema.” TDPL — and its generalization, GTDPL — modeled the kind of backtracking recursive-descent parser that programmers had already been writing by hand.

Most of the parsers we actually learned in school, though, came from the other direction. YACC and its descendants are bottom-up. There’s no equally catchy acronym for that lineage, so let’s coin one to match: BUPL, “Bottom-Up Parsing Language.” It’s a fair pairing, because the two approaches aren’t just different algorithms — they carve up the space of expressible languages differently. BUPL-style parsers are built to handle context-free grammars. TDPL-style parsers, as it turns out, are strictly more powerful: GTDPL can recognize some languages that aren’t context-free at all.

That gap is the part I want to dwell on.

Context-free grammars were never chosen because they were the natural shape of the languages we wanted to describe. They were chosen because they were the shape we could analyze — tractably, on 1960s and 70s hardware, with the theory available at the time. CFGs are a technology-driven compromise, not a human-driven one. The rules people actually want to express — “this identifier must already be declared,” “indentation determines scope,” “this word means something different depending on what came before it” — are context-sensitive by nature. We just got very good at designing around that fact, and then forgot it was a workaround.

TDPL-style parsing didn’t disappear; it resurfaced as packrat parsing and PEG (parsing expression grammar) technology. Packrat parsers take the old backtracking recursive-descent idea and make it linear-time by memoizing every partial match. The result is a parser that can express things a CFG struggles with — longest-match rules, syntactic predicates, lookahead-sensitive grammar — in a single, readable grammar, without the contortions BUPL grammars require to fake context sensitivity.

The reason packrat parsing lost the popularity contest for so long comes down to one word: slow. Naive backtracking parsing can blow up combinatorially, and memoizing every rule at every position isn’t free — it trades time for space, aggressively. In the 20th century, that trade was a real cost. Memory was precious; cycles were precious. “Slow” meant something concrete and often disqualifying.

But “slow” in the 21st century is a different animal. We routinely throw gigabytes of RAM and billions of cycles per second at problems that would have been unthinkable to solve this way fifty years ago. A packrat parser’s memory appetite, once a dealbreaker, is now a rounding error on a phone. The trade-off that justified CFGs and bottom-up parsing was a trade-off against scarcity. We’re not scarce anymore, at least not in the way that mattered when the decision was made.

So it’s worth asking, plainly: if the constraint that shaped our parsing technology has largely dissolved, why are we still defaulting to the grammar formalism that constraint produced? Context-sensitive, TDPL-style, packrat-flavored parsing isn’t a curiosity from before the field “matured” — it may be the more honest match for how humans actually express structure. We just needed the hardware to catch up to the idea. It has.

References

packrat parsing

Experiment — Projectional Viewer

Paul Tarvydas — Wed, 26 Aug 2026 15:37:11 GMT

Purpose

Modern programming languages bury structure under implementation detail. The signal-to-noise ratio is too low — there’s too much how cluttering up the what — and that makes it hard to reason about anything beyond fairly simple problems.

This experiment asks whether implementation detail can be elided from code, rather than removed. The detail stays in the source; it’s just toggled out of view in the editor. The goal is a clearer picture of a solution’s structure, without having to wade through the mechanics of how that structure gets executed.

The immediate irritant was PEG (parsing expression grammar) libraries. I know grammars reasonably well, and most PEG implementations I’ve used smear the grammar itself under a layer of code for capturing and acting on matches during and after the parse. The grammar — the actual structure of what’s being recognized — disappears into the plumbing.

A full round-trip projectional editor, where you edit the elided view and it writes back to the source, is hard to build well. So this experiment settles for a one-way trip: elide the detail for reading, without trying to support editing the elided form. The question is whether that lesser goal is easy to reach and still worth having.

Underlying this is a way of treating a “grammar” as a DSL for pattern matching — one little language embedded in another. If eliding works here, it suggests a broader path: composing many small special-purpose languages into a single codebase, instead of forcing every concern through one general-purpose paradigm.

Method

I started from a small, real example: a phone-number grammar written in Rebol, implementation detail and all.

parse "(416)555-1234" [
    "(" copy area 3 digits ")"
    copy exch 3 digits "-"
    copy line 4 digits
    (print rejoin [area "-" exch "-" line])
]

The copy area, copy exch, copy line, and the trailing (print rejoin ...) block are all implementation detail — they’re about capturing values and doing something with them, not about the shape of a valid phone number. Stripped of that, the grammar itself is just:

parse "(416)555-1234" [
    "(" 3 digits ")"
    3 digits "-"
    4 digits
]

To get from one to the other automatically, I had Claude Sonnet 5 Code write an Emacs Lisp file, pelide-view.el, that shells the buffer (or region) out to a small pipeline built on T2T: an OhmJS parser followed by RWR rewrite semantics. The pipeline reads the annotated source and hands back the elided grammar, which the elisp code then displays back in the editor.

The grammar for the pipeline’s parser (pelide.ohm) and its rewrite rules (pelide.rwr) are in the appendix, as is the generated pelide-view.el. The rest of the code lives in the github repo.

Given the time available, I only ran this against the one example above. Whether it generalizes to messier grammars is an open question.

To reproduce it: eval and load pelide-view.el, load ex.r into Emacs, then hit C-c p tto toggle into the elided view, and again to toggle back.

Observations

The pipeline did what it was supposed to: it elided the copy clauses and the trailing action block, and left behind the bare grammar shown above. Toggling back and forth in Emacs worked as expected.

Under the hood, this is my T2T transmogrifier technology at work: OhmJS does the parsing, and a custom DSL I call RWR does the filtering, rewriting, and eliding. The result is handed back to Emacs for read-only viewing.

Conclusions

Even from this one example, the elided grammar reads better than the annotated original — it’s easier to see, at a glance, what pattern is actually being matched. That’s a good sign for the general idea.

It’s a small enough result that I’d want to try it against more grammars before drawing strong conclusions, but it seems worth pursuing. A natural next step would be writing elision grammars for other, more current PEG implementations — Lua’s and Janet’s come to mind.

This also suggests that using T2T as a filter is fast and usable enough on modern hardware — the lag when toggling is almost imperceptible. I don’t expect that to change as long as we keep the little languages little: there’s no need to write grammars for Turing-complete behemoths here, since small code snippets are all that’s required.

The experiment also points at a follow-on problem worth tackling: writing grammars that can detect the presence of elidable code within a larger file, rather than assuming the whole file is a single elidable unit.

Further ideas: composing many little languages instead of one paradigm

This experiment is one piece of a larger question: how do you let many small DSLs coexist inside a single project, instead of forcing everything through one general-purpose language?

One direction already underway is transmogrification rather than elision: writing in a small meta-language and generating standard target languages from it. The PBP kernel is built this way — three source files (0d.rt, stock.rt, jit.rt) written in the .rt meta-language, currently transmogrified into Python, JavaScript, and Common Lisp. The transmogrifier itself works (see the kernel repo for details), but I haven’t yet run the projectional-viewing experiment against it.

A further-out direction is diagrammatic programming: generating code snippets from a diagrammatic programming language (DPL) rather than text. There are small, early examples of this using drawio — a decision-tree repo and a state-machine repo — but again, the elision experiment hasn’t been done against them, and it isn’t even clear yet how drawio would couple to Emacs.

Appendix — Generated `pellide-view.el` Code

;;; pellide-view.el --- Shell out to PELLIDE for a condensed view -*-
;;; lexical-binding: t; -*-

(defgroup pellide-view nil
  "Shell buffer/region out to the PELLIDE tool for a condensed view."
  :group 'tools)

(defcustom pellide-view-command "pellide"
  "Shell command to run. Reads source on stdin, writes condensed view on stdout."
  :type 'string)

(defcustom pellide-view-command-args nil
  "Extra CLI args to pass to `pellide-view-command'."
  :type '(repeat string))

(defvar-local pellide-view--original nil
  "Buffer-local stash of the pre-toggle source, used by `pellide-view-toggle-in-place'.")

(defun pellide-view--run (text)
  "Pipe TEXT through `pellide-view-command'; return its stdout as a string."
  (with-temp-buffer
    (insert text)
    (let ((exit-code (apply #'call-process-region
                             (point-min) (point-max)
                             pellide-view-command t t nil
                             pellide-view-command-args)))
      (unless (zerop exit-code)
        (error "%s exited %s: %s" pellide-view-command exit-code (buffer-string)))
      (buffer-string))))

;;;###autoload
(defun pellide-view-region-or-buffer ()
  "Shell the region (or whole buffer) out to PELLIDE; show the result read-only
in a `*PELLIDE View*' side window. Non-destructive -- source buffer is untouched."
  (interactive)
  (let* ((text (if (use-region-p)
                    (buffer-substring-no-properties (region-beginning) (region-end))
                  (buffer-string)))
         (mode major-mode)
         (result (pellide-view--run text))
         (out-buf (get-buffer-create "*PELLIDE View*")))
    (with-current-buffer out-buf
      (let ((inhibit-read-only t))
        (erase-buffer)
        (insert result)
        (funcall mode)
        (setq buffer-read-only t)))
    (display-buffer out-buf
                     '((display-buffer-reuse-window display-buffer-in-side-window)
                       (side . right) (window-width . 0.5)))))

;;;###autoload
(defun pellide-view-toggle-in-place ()
  "Toggle the CURRENT buffer's text between source and PELLIDE's condensed view.
Destructive: only safe if you don't edit while in the condensed view --
PELLIDE is not assumed invertible, so toggling back just restores the stashed
original, discarding any edits made to the condensed text."
  (interactive)
  (if pellide-view--original
      (let ((orig pellide-view--original)
            (modified (buffer-modified-p)))
        (setq pellide-view--original nil)
    (setq buffer-read-only nil)
        (erase-buffer)
        (insert orig)
        (set-buffer-modified-p modified))
    (let ((orig (buffer-string))
          (modified (buffer-modified-p)))
      (erase-buffer)
      (insert (pellide-view--run orig))
      (setq buffer-read-only t)
      (setq pellide-view--original orig)
      (set-buffer-modified-p modified))))

(global-set-key (kbd "C-c p v") #'pellide-view-region-or-buffer)
(global-set-key (kbd "C-c p t") #'pellide-view-toggle-in-place)

(setq pellide-view-command "~/projects/rebol/pellide")

(provide 'pellide-view)

Appendix — T2T Grammar `pelide.ohm`

pelide {
  main = "parse" spaces item spaces pGrammar spaces
  item = string | id
  string = "\"" (~"\"" any)+ "\""
  id = letter idtail*
  idtail = alnum
  pGrammar = "[" grammarItem+ "]"
  grammarItem =
    | space -- space
    | string -- string
    | copyItem -- copy
    | topLevelActionItem -- action
    | ~"[" ~"]" ~"(" ~")" ~"copy" ~space ~string any -- other
  topLevelActionItem = "(" spaces actionItem+ spaces ")"
  copyItem = "copy" spaces id spaces int? spaces id
  actionItem = 
    | "(" spaces actionItem+ spaces ")" -- recparen
    | "[" spaces actionItem+ spaces "]" -- recbrack
    | ~"]" ~"[" ~"(" ~")" ~"copy" any -- other
  int = digit+
}

Appendix — T2T Rewrite Rules `pelide.rwr`

%rewrite pelide {
  main [_parse ws1 item ws2 pGrammar ws3] = ‛parse«ws1»«item»«ws2»«pGrammar»«ws3»’
  item [x] = ‛«x»’
  string [lq cs+ rq] = ‛«lq»«cs»«rq»’
  id [letter idtail*] = ‛«letter»«idtail»’
  idtail [alnum] = ‛«alnum»’
  pGrammar [lb item+ rb] = ‛«lb»«item»«rb»’
  grammarItem_space [s] =‛«s»’
  grammarItem_string [s] =‛«s»’
  grammarItem_copy [x] =‛«x»’
  grammarItem_action [x] =‛«x»’
  grammarItem_other [x] = ‛«x»’
  topLevelActionItem [lp ws1 A+ ws2 rp] = ‛’
  copyItem [_copy ws1 id ws2 int? ws3 id2] = ‛«int»«ws3»«id2»’
  actionItem_recparen [lp ws1 a+ ws2 rp] =‛’
  actionItem_recbrack [lb ws2 a+ ws3 rb] =‛’
  actionItem_other [x] =‛’
  int [digit+] = ‛«digit»’
}

Simplicity Is in the Eye of the Beholder

Paul Tarvydas — Fri, 21 Aug 2026 14:03:43 GMT

“General Purpose Languages” promise to make programming easier by covering every case. What they actually do is force everyone, regardless of what they’re building, to adopt the same pile of complexity — instead of letting each of us go looking for the simplicity that actually fits our problem. I don’t think that’s an accident of language design. I think it’s what happens when you forget that “simple” was never one thing to begin with.

What Is Simplicity?

Ask most engineers what “simple” means and you’ll get some version of “easy to understand” or “not complicated.” That’s circular — it just restates the word. Here’s a sharper definition, one that actually does work: simplicity is a lack of nuance.

That sounds backwards. We’re trained to admire nuance. A “nuanced” argument is a sophisticated one; a nuanced understanding is a deep one. But nuance is also where complexity hides. Every special case, every “well, except when,” every extra rule bolted on to handle one more scenario — that’s nuance accumulating. A system with a lot of nuance is a system with a lot of surface area for things to go wrong, and a lot of surface area a newcomer has to learn before they can be trusted with it.

But there’s a second, harder truth sitting underneath the first one: simplicity isn’t a property of the thing itself. It’s a property of the thing relative to what you’re trying to do with it. Simplicity is in the eye of the beholder.

If you’re an accountant, a spreadsheet is about as simple as tools get — rows, columns, formulas, done. But if you’re trying to analyze a program for self-consistency and correctness, a spreadsheet stops being simple the moment you try to use it for that job. It doesn’t have the nuance to represent the edge cases correctness analysis actually needs, so you end up bolting nuance on by hand until it can — at which point it’s not the simple tool you started with anymore.

The same split shows up in language design. If you’re trying to invent a new software system, garbage collection is a genuine boon — it lets you stop thinking about low-level memory management and put your attention on the design instead, and deep type checking mostly gets in your way while you’re still figuring out what you’re building. But if you’re production-engineering that system afterward — dotting every i, crossing every t, squeezing real efficiency out of the design — the opposite is true. Now you want to get rid of generalized garbage collection in favor of memory management tuned to exactly this project, and you want as much type checking as you can get, because that’s what catches the edge cases before they ship. A language that makes deep type checking effortless is “simple” for that job. A language that lets you manipulate memory in excruciating detail, while still checking that every operation is self-consistent and safe, is “simple” for that job too — a different job, a different simplicity.

Physics has a name for this kind of move: much-greater-than (>>) analysis. You look at a system, decide which effects dominate in the regime you actually care about, and drop everything that’s small by comparison. It’s how you get a spherical cow: an idealization that’s genuinely useful for the question in front of you, and genuinely wrong the moment you forget it was only ever an idealization of one regime. The discipline isn’t in finding the simplification — it’s in remembering which domain it’s valid for, and knowing that you’ll eventually need to superimpose several such simplifications, each valid in its own regime, to get back something closer to the full picture.

I think we’ve largely forgotten that our dominant notation for programming — the functional one — is exactly this kind of simplification. It was built for a specific regime: analyzing programs, proving things about them, reasoning about what they compute. It was not built for designing them, and it was not built for controlling machines. Most of what we actually mean by “programming,” in practice, is writing software that controls a machine — I/O, timing, hardware, concurrency, the physical world leaking in at the edges — and that’s a domain the functional simplification was never valid for. We inherited the >> analysis, forgot it was one, and started treating a tool for analyzing programs as though it were the definition of what a program is.

Examples of Simplicity

With that caveat in front of you — that every example below is simple for a purpose, not simple in some absolute sense — here are some cases where someone found the edges of a domain and built a notation that fit only inside them.

UNIX made this move at the level of the whole operating system. Devices, pipes, sockets, regular data on disk — wildly different things — all get normalized to one kind of object: a file, addressed through a file descriptor. You don’t need a special API for talking to a printer versus reading a config versus piping output from one program into another. It’s all read() and write() on a descriptor. That single normalization is why shell pipelines work at all, and it’s a textbook case of stripping nuance out of an interface until only one shape is left.

Forth Haiku shows the same move at a much smaller scale. A few lines of dense, unglamorous Forth notation can expand into a hundred lines of GLSL shader code. The notation is small because it says exactly what needs to be said and nothing else — the complexity of the output is real, but it isn’t paid for in the complexity of the source.

Forth itself and Lisp 1.5 both make this trade at the language-design level: an almost absurdly small set of primitives (words and a stack in Forth’s case, s-expressions and a handful of special forms in Lisp’s) that compose into everything else. Neither language tries to have a construct for every situation. They have one or two constructs and trust you to build the rest.

BNF, and its descendant eBNF, do for grammars what UNIX did for I/O: instead of describing “how to parse this particular language,” they give you one small notation for describing any string-matching grammar. Once you know BNF, you can read the shape of a language you’ve never seen before, because the notation for describing structure is separated from the structure itself.

CPU opcodes are simplicity imposed on physics. Underneath every instruction is a genuine rat’s nest of electronics — gates, latches, timing — but the opcode gives you one normalized unit of action (“add these two registers”) instead of asking you to reason about the rat’s nest directly. It’s the same move UNIX makes with files: pick one small vocabulary and hide the mess behind it.

Feynman diagrams did this for particle physics. Before them, interactions were described with sprawling functional equations. Feynman gave physicists a small set of lines and vertices that could be composed like a notation, and the diagrams could be read and manipulated almost visually instead of algebraically. Complicated interactions became combinations of a few simple pictures.

K&R C, compared to the ANSI C that came after it, is a smaller and blunter language. It defined every routine as a “function,” full stop, and it shipped with a type-checking model that was good enough to build real systems software without trying to be good enough for everything. It didn’t cover every case. That was the point — it covered enough cases, and refused the temptation to keep adding nuance to cover the rest.

UNIX itself makes the point sharper. It wasn’t invented in C — it was invented in assembler, and stayed that way until Version 4 rewrote the kernel in C in 1973. Assembler was “simple enough” for inventing the core of an operating system; K&R C came later, as a step toward production-engineering and extending what the original, simpler constructs had already proven out. Ivan Sutherland’s Sketchpad tells the same story from computer graphics — also built in assembler, also invented rather than production-engineered. Asked how he’d managed to build the first interactive graphics program, the first non-procedural programming language, and the first object-oriented software system in a single year, Sutherland said, “Well, I didn’t know it was hard.” Assembler was “simple” for what he was doing — not because it had fewer nuances than a high-level language would have, but because inventing didn’t yet need the nuances a high-level language exists to manage.

Prolog, and relational programming generally, buys simplicity of expression at a real cost: you describe relationships instead of steps, and the language figures out how to satisfy them, at the cost of runtime performance. Simplicity, here, is a trade of your cognitive load for CPU cycles — not a free lunch, just a different bill.

Children’s LEGO blocks are maybe the purest physical example. There’s exactly one type of connector — a round peg of fixed dimensions — and every block uses it. No block is tightly coupled to any other specific block; anything connects to anything. That single, boring, unglamorous decision is why a five-year-old can build things an engineer would call “extensible” without ever hearing the word.

Multi-stage computation — pipelines where each stage does one thing and does it well — applies the same idea to how we structure programs, not just interfaces. When a stage only has to do one job, the person writing it can actually think about that job deeply, instead of splitting their attention across five concerns and reaching for workarounds to keep them from tangling.

Examples of Anti-Simplicity

The failure mode isn’t “trying and failing to be simple.” It’s usually nuance creeping in disguised as generality — someone reaching to cover every domain at once instead of admitting which one they’re actually in.

Overuse of the functional paradigm is the clearest case. Forcing every problem into the shape of a mathematical function creates workarounds wherever the problem doesn’t naturally fit that shape, and a lot of real problems don’t. This isn’t an accident of language design; it’s a hangover from using CPUs to automate mathematics first, and programming second. Most languages are built around “functions” even though the CPUs underneath them don’t implement functions at all — you need extra code just to turn a subroutine into something that behaves like one. We inherited a nuance we didn’t have to have.

User-defined types are another. Machines fundamentally have only a couple of types — a bit, and a pointer to a bit, optimized into bytes for convenience. Every user-defined type is a new layer of invented structure sitting on top of that, and each layer needs its own type-checking rules. It’s nuance stacked on nuance, and it’s why type systems keep growing more elaborate instead of settling down.

Using “functions” to describe asynchronous parts is the sharpest case, because it’s a category error dressed up as convenience. A function call is synchronous by nature — the caller blocks and waits for the callee to answer. Asynchronous parts are, definitionally, not that. Describing async behavior with a synchronous vocabulary doesn’t just add nuance — it adds nuance that actively lies about how the system behaves.

BNF, held up above as a genuine simplification, is also a cautionary tale in how a simplification gets captured by one purpose and then mistaken for having only that purpose. Almost immediately after BNF appeared, its main use became building the same kind of thing over and over: niggly, bottom-up, over-burdened parser state machines that are “simple” only if your job is shipping production-quality parsers. That’s a narrow reading of a notation good for a lot more than that — specifying string matchers for programming-tool development, for instance, matching recursive text structures in ways plain regular expressions can’t easily reach. PEG — formalized by Bryan Ford in the mid-2000s, with OhmJS a well-known later implementation — finally gave recursive-descent, top-down parsing a first-class alternative to BNF’s bottom-up habits, but even PEG is still mostly discussed as competition for production parser generators, not as a door into a different way of building programming tools altogether.

Operating systems are the anti-simplicity example that’s easiest to miss, because we’ve stopped being able to imagine programming without one. Step back far enough, though, and the concept isn’t actually necessary — early gaming systems are a working proof of that. A game cartridge plugged into hardware that had no operating system on it at all, and none of the complicated, brittle fluff that comes bundled with a modern OS was needed to make that work.

The original intent was reasonable: supply common libraries of code so program development goes faster. But instead of building those libraries the way LEGO blocks are built, joined through one small interchangeable connector instead of welded tightly to each other, we built them inside the functional paradigm, and got a huge ball of over-coupled functionality that ships to every user whether they need 2% of it or 90%, and gets cherry-picked at runtime. Instead of production-engineering individual applications, we kept adding nuance and complication to the libraries themselves, hoping a big enough general-purpose pile of code could solve every production problem in advance. And because the functional paradigm was never suited to expressing asynchronous operation or the composition of programs in the first place, that pile keeps growing without closing the gap — getting closer to the asymptote, never reaching it.

Operating systems genuinely make software development simpler, and that part is worth keeping. Where the reasoning breaks down is the next step: shipping that same sprawling, general-purpose pile whole-hog to every end user’s machine. Underneath the megabytes and gigabytes, an operating system is mostly a much more complicated replacement for hardware that used to be a rotary switch or a game cartridge — simpler to use, simpler to reason about, and not carrying around code for every possibility it will never be asked to serve.

GPUs are one production-engineering answer to a simple problem: how do you provide a lump of code for every pixel on a screen? Maybe the simpler answer — in hardware and in software — would have been one small CPU, with its own private memory, per pixel.

How Do You Teach Simplicity?

I don’t know yet.

What I notice, looking back over the examples above, is that they all seem to come from the same place: first-principles thinking — refusing to solve a problem with the first niggly fix that comes to mind, and instead asking what the smallest true thing underneath it actually is, for the regime you’re actually in.

In my first physics course at university, before we were allowed to solve a single problem, we were taught to invent notations for the problem domain — essentially small, purpose-built DSLs — and only then start reasoning inside them. That’s >> analysis again, just applied to notation instead of forces: decide what regime you’re in, build the smallest language that’s valid there, and don’t pretend it generalizes further than it does.

I don’t have a tidy answer for how you teach that skill. Pattern-matching a problem to its right regime seems to take taste as much as method. But I’m fairly sure teaching it starts by refusing the premise I opened with — that one notation, sufficiently general, could ever replace it.

I’ve written about this before, if you want to keep pulling on the thread:

References

Unix V4 Tape Successfully Recovered
Forth Haiku Salon
What I’ve Learned From Forth Haiku Thus Far (see, also, the substack listed below for articles related to Forth Haiku)
OhmJS

Macros With OhmJS

Paul Tarvydas — Thu, 13 Aug 2026 02:50:45 GMT

grammar

macro {
  main = stuff+
  stuff = 
    | applySyntactic -- macro
    | any -- other
  HamburgerAndFries = "hamburger" "and" "fries"
}

“ApplySyntactic<…>” is unique to OhmJS. A capitalized rule skips spaces automagically. You can’t use a syntactic rule (capitalized) within a lexical rule (non-capitalized) unless you specify applySyntactic<...>.

The parser looks for “hamburger and fries” with any number of spaces and newlines in between the words - i.e. a syntactic rule.

test

a b c hamburger and bacon d e f hamburger and fries g h i

This test shows that “hamburger and bacon” is rejected as a macro pattern . The parser sees only “hamburger and fries” as a macro pattern. Everything else is a “stuff_other”, parsed character by character - wildly inefficient by 20th century standards, but quite reasonable using 21st century hardware. (Not reasonable for production code, but, macros are used for development code, wherein the definition of “efficiency” is different from what we’ve been led to believe by 20th century biases)

What happens to the macro match depends on the semantics code attached to that grammar rule (“stuff_macro”). The simplest thing to do is to simply rewrite it as a different string. That’s what T2T (using .rwr rules) does…

ohm-editor

Appendix - T2T

T2T is one of the tools in the PBP toolkit — once you install PBP, you have access to T2T.

Appendix RWR

RWR is part of T2T. This is the specification for RWR

Appendix - PBP

PBP tools

Appendix - Further About PBP

Towards Parts Based Programming
PBP cookbook playlist
Decision Tree Diagram Transmogrifier
State Machine Diagram Tool

FDD LLM - 5 Whys Tool - code repository
State Machine Tool - code repository
Decision Tree Tool - code repository
PBP all tools (PBP, T2T, das2json)

The Spherical Cows of Programming
The Wrong Spherical Cow - First Principles of Parts Based Programming
The Case For Composable Notations (1 / 5) - The Spherical Cow We Forgot We Were Riding
The Case For Composable Notations (2 / 5) - The Restrictions That Came With The Cow
The Case For Composable Notations (3 / 5) - State Isn’t The Enemy The Case For Composable Notations (4 / 5) - Ease of Expression Is the Whole Point
The Case For Composable Notations (5 / 5) - UNIX Already Showed Us the Way
The Case For Composable Notations (6 / 5) - WIP - Notations in Progress
# See Also

Paid subscriptions are a voluntary way to support this work.

Skipping With OhmJS

Paul Tarvydas — Thu, 13 Aug 2026 02:24:20 GMT

grammar

skip {
  main = stuff+
  stuff = 
    | "(" stuff* ")" -- recursive
    | ~"(" ~")" any -- other
}

test

function foo (bar, baz) {
  xyz;
  f(g(1,h(2)),99);
}

ohm-editor

Preventing the Collapse of Civilization

Paul Tarvydas — Wed, 12 Aug 2026 19:26:41 GMT

A comment from a non-programmer family member sent me back to Jonathan Blow’s lecture, Preventing the Collapse of Civilization. Watching it again, I found myself nodding along to most of the same points as before, e.g.

abstraction leads to complication not simplification
- “… [32:24] but somewhere through this chain it becomes wrong and that that’s how people are wrong a lot of the times right like you start out by being right and then you extrapolate it too far into wrong territory …”
the majority of modern programmers don’t know how CPUs work
- “[33:11] I certainly don’t know what the CPU is doing in response to the code that I’ve written”
technology does not automatically improve
software is in decline
software has been free-riding on hardware
- software technology, itself, has not improved for quite a while
- so I would characterize software as having small local technological improvements like machine learning with overall inertia or degradation in the rest of the field and we’re very impressed by the improvements
- we simply don’t expect software to work anymore
- if you’re using a program and it does something wrong you’re just like yeah it’s software restart it whatever and that didn’t used to be and if our standards are shrinking over time how low can they shrink before it becomes unsustainable
Five 9’s
- four nines would be ninety-nine point nine nine whatever and we don’t use this anymore I think in part because the number of nines would be going down and we can’t make it go up again and […] certain parties don’t seem to care
- IMO correct code does not imply correct design
“if you haven’t seen an entire industry produce robust software for decades what makes you think they actually can”
“[34:01] but programmers are not more productive now than they used to be in fact it looks to me like productivity [34:08] per programmer is approaching zero”
“[36:31] (Kernighan) programmers aren’t productive these days like that and everybody laughs but it’s funny but it’s not funny”
“LSP Is The Devil”
“[57:26] counterpoint to this and what if we just let software get really complicated and then just make an AI that understands it [57:32] and that’s fine and it’s like okay maybe but you really want human beings to not be able to understand software it”
“Q: [58:40] my way of thinking changed don’t you think that tools they somehow [58:46] force us to think in the certain type of way and for you making a new language as a somehow to break through this … A: [58:55] … I I think I would agree with that and I would also [59:00] say though you know because we think with tools often unnecessary complications or bugs in the tools [59:07] interfere with the thought process right like you’re in flow you’re doing stuff and then something bad happens and …”

Here’s where I diverge: I think we’ve backed ourselves into a corner by writing software in a brittle paradigm — the functional paradigm — and then treating it as the only legitimate way to build anything. That assumption pushes us toward bad designs, and we paper over the mismatch with workarounds (“epicycles”) that force fundamentally non-functional operations into a functional shape.

We got here due to false advertising about C. C is a functional programming language (albeit, not sufficiently anal retentive). C is not ‘close to the hardware’. K&R C was close to PDP-7 hardware, but not to other, non-PDP CPU architectures. UNIX was written in assembler, not C. When UNIX was rewritten in C (V4 UNIX), it was written in a language called K&R C, not ANSI C. K&R C was a tool that helped programmers to create boilerplate assembler code suitable for implementing UNIX. K&R C had #asm. ANSI C is a different language - it emphasizes portability to architectures that are not similar to PDP style architectures. ANSI C should not be called “C”.

The 1972 version of Atari Pong fits on one page of paper. A Lua version of Pong looks nothing like that original design, mostly because the design has been warped to fit into a functional mold.

Work on theorem proving builds better theorem provers but does not imply better, more reliable software in general. Only a small class of people want to prove theorems. Most people don’t care about this ability nor about research in this direction. A program is not a theorem. A program is a set of instructions that direct a dumb machine to perform various actions, often seen as useful to humans. Humans reading a program should be able to understand exactly what the architect had intended the machine to do - if the readers have to theorize about the program, then the DI (Design Intent) has not been clearly stated. This is a problem - trying to solve the problem by using a programming notation that straddles both domains (instructing a machine, expressing DI) isn’t working as we’d hoped. I’m experimenting with black box notation (which I call PBP) to see if the box structure and wiring between boxes is more informative to humans while the innards of the boxes provide methodical instructions to machines.

You can’t use software functions like black boxes. A function delivers control flow as well as data to the receiver and the function must block itself waiting for a result from the receiver. This is strong coupling and is the antithesis of how black boxes (aka LEGO blocks) work.

We need to be researching simplicity not how to add more complexity.

Opinions About Compiler Building

Paul Tarvydas — Wed, 12 Aug 2026 09:40:32 GMT

My random opinions about compiler building in the 21st century based on 30+ years of software consulting. I think of language design and compiler-building as two different things. One should actually avoid building compilers in the 21st century - we have enough compilers already. There’s always room for new languages, though. (In fact, I favour languages that use something better than characters for syntax, but, I digress…)

(Caveat: some of the links below point to experimental code, I write more about this stuff in my substack articles, blog, YouTube (all listed below))

prototype the language and play with it first
- use OhmJS to whip together a parser
  - OhmJS is based on PEG technology which makes it easy to write grammars
  - use Ohm-editor (part of the OhmJS package) - it’s essentially a REPL for grammar writing that shows parse trees (CSTs), it saves a lot of time up front
  - when satisfied, you can re-code the grammar using whatever other technology you deem is necessary (e.g. Pratt parsing, whatever)
    - writing the code twice (or more) is more efficient than starting out dealing with implementation issues right off the bat
  - the easiest part of building a compiler is writing a parser (and scanner if you use something other than PEG), but, it’s been formalized and therefore discussed more often than the hard parts
- you can build an MVI (Minimum Viable Implementation) of a language by transpiling code written in the language to some already existing language (e.g. Python, Javascript, etc.)
  - I favour using a text-to-text transmogrifier (“transpiler”) like the T2T stuff in Parts Based Programming
  - Steve Philips invented a new language Voltair by transpiling Voltair code into Go code. I think that he used an LLM to build the transpiler.
  - Alan Kay is on record saying that new languages should use existing languages as “assembler”
type checking is best expressed as a relational program
- use something like Prolog or one of its descendants
- use triples only, don’t bother with the OO extensions to Prolog
  - a triple is relation(subject,object)
  - you can code up your own exhaustive search inferencer based on Nils Holm’s Prolog in Scheme code or my automated port of it to Javascript, but why bother? Write it first in Prolog (or …), then when satisfied re-code it in something else
- type checking is much harder and more involved than parsing, start by expressing the rules in relational form and getting the rules right before calcifying implementation details
when doing code emission, emit “dumb” code first, then clean it up with a peepholer as described in Fraser/Davidson or Cordy’s OCG (GCC uses RTL, IMO, Cordy’s OCG is even better)
- go for simplicity first, make code emission easy, then tighten up later after measurements prove which parts need to be tightened up
Holt et al, invented Data Descriptors - a way to normalize all data into the same form, which then makes things like allocation easy to think about
I favour a UNIX-y pipeline approach - use multiple stages, each written in a language that is better suited to each particular problem, e.g. Ohm for parsing, Prolog for type checking, Cordy’s MISTs for portability, etc.
making a compiler blazing fast and efficient is a different problem from creating a language, Production Engineers should worry about efficiency, but these issues should not impose themselves on the initial design, MVI of a language
first, write an interpreter for the language, and only then tighten up efficiency by building a compiler for the language
a compiler / language is just a really big program that takes a long time to implement
Javascript or Lisp are pretty good IRs (Intermediate Representation), LLVM is overkill and complicated, Python is good but it’s indentation-based syntax is painful to generate (I “solve” this problem by generating code in a meta-python (Python with braces instead of indentation) then use a small (40 lines of JS) program to replace brace-bracketed code with properly indented code)
what we “know” about compiler-building is based on crufty old ideas from the 20th century, we have better tools and machines today and we should be able to do better
- my PBP kernel] (“multi-tasking”, “coroutining”) (especially 0d.rt, stock.rt, jit.rt) is written in a meta-language .rt that generates the kernel in multiple languages (Python, JS, CL - it can do more, but I ran out of interest)

Appendix - T2T

T2T is one of the tools in the PBP toolkit — once you install PBP, you have access to T2T.

Appendix RWR

RWR is part of T2T. This is the specification for RWR

Appendix - PBP

PBP tools

Appendix - Further About PBP

Towards Parts Based Programming
PBP cookbook playlist
Decision Tree Diagram Transmogrifier
State Machine Diagram Tool

FDD LLM - 5 Whys Tool - code repository
State Machine Tool - code repository
Decision Tree Tool - code repository
PBP all tools (PBP, T2T, das2json)

Stop Confusing Languages With Compilers

Paul Tarvydas — Fri, 17 Jul 2026 22:29:08 GMT

Most programmers treat “language” and “compiler” as the same thing. Say “I built a new language” and people hear “I built a new compiler” — parser, type checker, code generator, the works. Months of effort, before you’ve written a single line in the thing.

I don’t think that’s right, and untangling the two ideas changes what’s possible.

A language is just a notation. It’s a way of writing down a problem so you can think about it more clearly — nothing more mystical than that. A compiler is a separate piece of machinery: code that takes a notation and turns it into instructions a CPU can run. We’ve bundled them together for so long that it’s easy to forget they’re doing different jobs. One is about human thought. The other is about machine execution.

Once you pull them apart, a question follows naturally: can you build a new language in a fraction of the time it takes to build a language and a full compiler for it? I think the answer is yes, and it’s yes by a wide margin. There are a few ways to get there.

Markdown for code

The first way is to treat a new language the way markdown treats formatted text: a thin, readable notation that gets translated into something else, rather than compiled from scratch down to machine code. That’s what I was exploring in Separating Architecture From Code and Implementing The Experimental ST Meta-Syntax, using a tool called T2T. The new language isn’t compiled in the traditional sense — it’s transformed. You get the benefit of a purpose-built notation without paying the traditional cost of a purpose-built compiler.

There’s a second idea worth pulling out of that markdown comparison, beyond just “lightweight notation.” Markdown lets you nest headings — #, ##, ### — so a document can be collapsed down to its top-level outline or expanded to full detail, depending on what the reader needs. I think code notations can do the same thing: present a system in layers that can be elided or drilled into, rather than as one flat wall of implementation. That has real consequences for onboarding. Instead of a new team member reading an entire codebase to understand it, they could read the top layer to get the architecture, then descend a layer at a time into whatever part they actually need to touch. People could understand a given architecture and its implementation down to whatever level of detail they care to delve into, and no further.

Explain it to an LLM

The second way is more recent, and honestly a bit strange to say out loud: describe your new language to an LLM, in plain language, and have it generate code from any source written in that notation. No parser to write, no grammar to formalize up front, no code generator to hand-tune. You explain the rules the way you’d explain them to a new hire, and the model does the translation.

To my understanding, this is roughly what Steve Phillips did with Voltair, a new language he’s been designing. At least in the early stages, he had Voltair source transpiled into Go rather than building a traditional compiler for it first — letting the language’s design settle before investing in dedicated compiler machinery.

This is where the language/compiler split really pays off, and it pays off regardless of which route you take. Whether you’re using something like T2T to transform a notation into another form, or an LLM that’s been told how your notation works, the cost of inventing a new language drops from months to hours.

Nobody has to like the target language

Here’s the part that trips people up. A lot of programmers dislike JavaScript for the same reasons they dislike assembler or C — verbose, error-prone, full of sharp edges. That dislike is real, and it’s earned. But it stops mattering the moment a machine, not a human, is the one writing the JavaScript.

We tend to judge languages by a single standard: does it prevent and catch the kinds of bugs humans make? That’s exactly the right standard when a human is going to sit down and type the code. It’s close to irrelevant when a machine is generating it. A “good” target language for generated code has a completely different set of criteria: syntax that’s easy to generate mechanically, and enough semantic flexibility that you’re not fighting the language’s opinions — GOTOs included, if that’s what the generator needs to produce. That last point actually narrows the field: neither JavaScript nor WASM supports raw GOTOs, while C and assembler do, since both are built around structured control flow rather than arbitrary jumps. That’s a real constraint on which target language makes sense for a given generator. Sometimes the deciding factor is even more mundane: you need to hook into something that only speaks a specific language. OhmJS, for instance, requires its semantic actions to be written in JavaScript (WASM support has recently arrived). If your generated code needs to talk to OhmJS, JavaScript stops being a matter of taste and becomes a matter of plumbing.

Once you separate “language good for humans to write” from “language good for machines to generate,” the reflexive dislike of JS or C or assembler just stops being relevant to half the conversation.

Little languages, on purpose

Little languages exist to make it easier for humans to work out solutions to specific problems — that’s the whole point of a domain-specific notation. If we accept that generating a little language is now cheap, it opens the door to a different way of building software altogether.

I call these project-specific notations SCNs — Solution Specific Notations — and I think a single project can reasonably contain many of them, each shaped around a particular slice of the problem rather than one general-purpose language stretched to cover everything.

The usual objection is that designing and implementing a language is hard — genuinely, historically hard. But look at where that difficulty actually comes from. From the language-builder’s side, yes, compilers are complicated machines. But from the language-user’s side, the difficulty is different: it’s that learning a new, general-purpose language tends to mean learning something big and overly complicated, because general-purpose languages have to cover every use case anyone might ever have. If the languages we asked people to learn weren’t so sprawling and so generalized — if each one only had to cover the one small problem it was built for — we might be a lot more willing to pick up a new little language every time we needed one. That objection made complete sense as long as “new language” meant “new compiler” and “compiler” meant “months of general-purpose language design.” But if a plethora of small, specialized, low-cost languages is actually within reach — sketched out with something like T2T, or handed to an LLM with a short explanation — then the complexity argument stops being a wall and starts being a leftover assumption from a different era of tooling.

That’s the shift I’m interested in: not one language to rule a whole project, but as many small ones as the problem actually calls for, each one cheap enough that inventing it isn’t a decision you have to agonize over.

Appendix - T2T

T2T is one of the tools in the PBP toolkit — once you install PBP, you have access to T2T.

Appendix RWR

RWR is part of T2T. This is the specification for RWR

Appendix - PBP

PBP tools

Appendix - Further About PBP

Towards Parts Based Programming
PBP cookbook playlist
Decision Tree Diagram Transmogrifier
State Machine Diagram Tool

FDD LLM - 5 Whys Tool - code repository
State Machine Tool - code repository
Decision Tree Tool - code repository
PBP all tools (PBP, T2T, das2json)

Simplification and Two Kinds of Code

Paul Tarvydas — Thu, 16 Jul 2026 11:25:19 GMT

Simplification has its benefits. Sometimes it’s the whole point.

I built a little DSL — a Solution Centric Notation, or SCN, my name for a small language aimed at one specific problem rather than general-purpose programming. I called this one “RWR,” and I leaned on three simplifications to make it:

Make it easy to transpile to an existing language, like JavaScript, instead of writing a real compiler.
Use only strings as the data model — no arrays, no objects, no user-defined structures.
Lean on eval() during development, which gives you most of the benefit of a compiler with a fraction of the ceremony.

RWR solves one narrow problem. OhmJS, the parser generator I was using, expects you to write its “semantics” actions — the code that runs when a grammar rule matches — in JavaScript. We usually can’t see the forest for the trees. Rewriting text is a simple problem, but we’re tempted to reach for all the overkill a general-purpose language makes available anyway, just because it’s sitting right there.

The point here is that we’ve overcomplicated our own problems by trying to generalize, by trying to produce general-purpose languages. By thinking about only what’s needed to successfully generate SCNs, I discovered I only needed strings and a handful of simple string operations. Those operations are a subset of what’s available in most modern programming languages, so it was like cherry picking — choose the minimal subset of what would actually be useful, and ignore the rest of the complications that have accreted onto programming languages over time.

So RWR is a tiny notation for expressing rewrites as string operations — raw characters plus interpolation — and nothing else.

The trick is how it gets executed. A tool I called T2T calls OhmJS twice: once to transmogrify RWR source into JavaScript, and once to eval() that generated JavaScript into real semantics actions and run OhmJS again on the actual source. Two grammars, one eval(), bolted together. The whole T2T implementation came to about 26 lines plus 33 lines of supporting code, written in roughly an hour and a half.

That last detail is the part worth dwelling on, because it’s not really about RWR.

Code like this — quick, narrow, string-only, held together with eval() — is not production quality by any reasonable definition. But that’s the wrong yardstick. In the 21st century we have the luxury of writing at least two kinds of code:

Code for production release.
Code purely to speed up our own development workflow.

Different customers, different lifespans, different acceptable failure modes.

That wasn’t always an option. In the 20th century, CPU cycles and memory were expensive enough that almost all code had to justify itself against one yardstick: will this run efficiently and reliably for years. Under that constraint, “quick and disposable” wasn’t a real category. That economic pressure shaped what we assumed code had to be — including the assumption that all programming languages must operate synchronously and sequentially, like a CPU executing instructions one at a time. It’s so deep it barely feels like an assumption.

But it isn’t the only substrate, even historically. Prolog and relational programming lean on backtracking to search for solutions instead of dictating steps. Forth has its own calling convention built around an explicit stack. Atari’s Pong, in 1972, ran as discrete logic gates in massive asynchronous parallelism — no clock ticking through instructions, just circuits reacting to each other at once. “Synchronous and sequential” was always a choice, made for good reasons at the time, never the only option.

Once you accept that some code only has to serve you, for a short time, to save you effort, you stop needing that code to look like production code or run the way production code runs. RWR and T2T are a small example: a DSL held together with interpolation and eval(), built in ninety minutes, whose only job was to save me from writing JavaScript by hand. Bad way to build a shipped product. Exactly the right way to build a tool for myself, this week, for this problem. The tool was, indeed, built quickly, but I’ve been fruitfully using it for years.

The broader move is to notice how many other “assumed” constraints are leftover 20th-century economics, and ask what changes if you loosen them — not just for what you ship, but for the string-matching tools, ASTs, and little SCNs you build purely to make your own next project faster. We can afford better shovels now, and the shovels don’t have to be cathedrals.

Appendix - T2T

T2T is one of the tools in the PBP toolkit — once you install PBP, you have access to T2T.

Appendix RWR

RWR is part of T2T. This is the specification for RWR

Appendix - PBP

PBP tools

Appendix - Further About PBP

Towards Parts Based Programming
PBP cookbook playlist
Decision Tree Diagram Transmogrifier
State Machine Diagram Tool

FDD LLM - 5 Whys Tool - code repository
State Machine Tool - code repository
Decision Tree Tool - code repository
PBP all tools (PBP, T2T, das2json)

Implementing The Experimental ST Meta-Syntax

Paul Tarvydas — Tue, 14 Jul 2026 14:04:17 GMT

Creating a new language no longer implies that you have to write a full-blown compiler, too.

As a follow-on to a previous article on architectural comments, this 80-minute, Twitch-like video shows how easy it is to implement new meta-syntaxes over top of existing programming languages.

Starting with a fresh working directory, the PBP toolset is cloned (mostly for its inclusion of the T2T tools). The Ohm-editor is used to rough-in a grammar and to examine the resultant parse tree in a REPL-like manner. Then, the grammar and rewrite rules are iteratively improved until valid Python (and Javascript) are produced.

We strictly focus only on test.st. This allows the implementation process to proceed quickly and to leverage on the capabilities of existing compilers. If one concedes thattest.st represents an interesting view of a part of an architecture (the Tiny PBP kernel in this case), then this video shows how to map that meta-syntax into valid Python and Javascript while, hopefully, making the Design Intent (DI) of this portion of the kernel more clear to readers.

A highlight of this technique is that it is possible to use T2T and OhmJS to “skip” over code. With this trick, you don’t need to write grammar rules for every millimetre of a language. T2T (Ohm, PEG, recursive descent) parses in a top down manner, whereas LR tools like YACC work in a bottom-up manner. The bottom-up approach needs a scanner that tokenizes everything and the associated grammar must then handle every combination in an excruciatingly detailed manner that takes a lot of development effort. The top-down approach lets you skip over text that you don’t want to deal with. This makes it possible to write little “skins” to wrap around existing languages - you don’t have to parse all of the existing language bits - you can just skip over other-language code.

T2T (text to text transmogrification) works in two stages
1. parse
2. rewrite.

This means that the same grammar (step 1. parse, above) can be used to create different rewriters for multiple target languages. In fact, PBP encourages this multiple back end approach, as seen in this snippet from the PBP kernel directory:

whereas simply using shell scripts - as is done in the example herein - doesn’t encourage the multiple back end approach (it can still be done using scripts, but it doesn’t naturally suggest this kind of approach).

Unlike with REGEX, top-down parsing can be used to write recursive rules, so this trick can be used to drill down into nested languages (which, say, use brace brackets, etc.).

Most modern programming languages use a line-oriented syntax, whereas Lisp uses a recursive syntax. Top-down parsing makes it easier to write recursive grammar rules (as opposed to the eBNF and Kleene-star stuff that we’ve become used to) for handling Lisp. Maybe we can invent more recursive-syntax languages and notations? A notation only needs to map onto hardware CPUs, it does not necessarily need to mimic CPU operational characteristics, like most modern programming languages do today.

[disclaimer: test.st is only an isolated snippet of code and DI. It has not yet been bench-tested, hence, this example might contain errors. The point of this video is only to show a technique for implementing meta-syntaxes.]

Appendix

st meta-syntax github
PBP tools github repository (the PBP tools include T2T)
tinypbp (WIP)

Experiment - Separating Architecture From Code

Paul Tarvydas — Sun, 12 Jul 2026 15:56:25 GMT

Highlights

invention of a trivial architectural meta-syntax (DI - Design Intent)
dynamic scoping for text-based languages to eliminate some function parameters
@proc == proc () procedure call syntax, no arguments, probable side-effects
images in comments
architecture is for humans, code is for machines

Accompanying Video

video

Introduction

I think that software architecture is more important than code.

This is an experiment for a simple way to include architectural descriptions in code.

In essence, this is just a psychological trick. I split “comments” into two classes on the basis that a programmer/architect might be more inclined to explain why one is writing code to control a computer vs. how the written code is supposed to accomplish the purpose.

The two classes of comments are:
1. architectural comments
2. code comments

We already have code comments in all programming languages. Code comments tend to be used in an overloaded manner - sometimes they are comments about the architecture and sometimes they are about the code.

We can add architectural comments by layering a meta-syntax over top of existing languages with a layer of meta-code using T2T tools (text-to-text transmogrification: parse the meta-code text, then rewrite it into existing languages, i.e. by treating existing programming languages as “assembler”).

In addition, I think that it is important to present architecture in successive layers. We can do this by using something akin to a markdown syntax. I have chosen (arbitrarily) to use the unicode character “⋅” in the same way that markdown uses ASCII “#”. A top-level architectural comment is prefixed by a single “⋅”. The next most important comment is prefixed by “⋅⋅” (two markers). And so on.

I’ve chosen to use a markdown-like syntax for including images in architectural comments, such as ![punt][200](tpbp-punt.drawio.svg) where the [200]represents the width, on a per-image basis, of the displayed SVG image.

My choices for this architectural comment syntax is arbitrary. Others might wish to change and improve it.

For this experiment, I prompted Claude to create elisp functions to use with my emacs editor.

The resulting display of the meta-code in my editor can be seen in the below screenshots and in the video.

The repository, listed below, contains an elisp/ subdirectory containing the generated elisp code.

The code in the video - test.st - can be transmogrified into Python and Javascript using the PBP toolset (namely T2T). I hope to create a twitch-like video of how I do this. The working transmogrifier code is in a github repository (see appendix).

If it’s not obvious, this is just a beginning, some brainstorming. I hope that it inspires better ideas.

Below is the script for the video.

Script

title

This is an experiment on separating architecture from code. Comments and suggestions welcome.

In my mind, code is just a building material, system architecture is more interesting than code.

In this video, I’ll just show a simple technique for writing an architectural description and how to browse it in layers.

Then we can look at the code to see how it maps to the Design Intent (DI) of the architect.

I imagine that in the future we might invent several more precise languages to describe architecture with, like the Parts Based Programming (PBP) stuff I describe elsewhere, but, for this video we’ll just use English and some SVG pictures.

[show M-0 code only view of test.st]

What does this code do?

To figure that out, we have become used to reading the code and reverse-engineering why the architect wrote the code that way.

I’ve been trying to re-create the reference version of the Parts Based Programming (PBP) kernel.

I’m inventing a meta-language on the fly that is intended to emit Python code, and to emit code in other languages like Javascript, Odin, etc. The meta-language is like Python with braces along with a few keywords that begin with $ and @. You don’t need to understand the meta-language at this point. I only want to show how to use layers to describe an architecture by spiralling into it in a layered manner.

I’ve been writing comments in ASCII text to explain what’s going on, and what the meta-code is meant to accomplish, but it would be easier to explain in stages and to use diagrams.

I am drawing SVG diagrams using drawio and I’ve asked Claude to write elisp code to elide code and comments based on key bindings.

[display M-1 view] Here’s an interim snippet of meta code. The algorithm that I want to describe is calledcontainer-handler. It takes one parameter self that’s defined elsewhere.

[M-2]

At level 2, we describe the purpose of this function.

We are writing the algorithm for how to handle parts that are composed of other parts.

This is kind of like lisp lists that contain other lists.

[M-3]

At layer 3, I say more about the algorithm.

First we punt the incoming message down to children parts.

Then, we cycle and step the innards of this container until all internal events have subsided.

I use the word mevent here to mean an event which causes a reaction - a message event.

[M-4]

At level 4, I choose to show red arrows for how to punt mevents down to children.

The interesting point here is that one incoming mevent is copied twice and fanned out to two inner children.

I think that the diagram shows what is happening better than words.

[M-5]

At the next level, I say that the algorithm steps until quiescense

and show what I mean in the next level down

[M-6]

The diagram shows that the incoming mevent caused a reaction from two inner parts which then sent two more mevents which then generated two more mevents which got fanned into the output of the composite part.

Again, the diagram says this better than my words.

[M-0] [M-0]

Here, I’ve hit the key to show all architectural comments with code embedded within them.

[M-0]

And here, I hit the toggle key to turn off all architectural comments, showing only the code.

We already saw this code at the beginning of this presentation, but now we have a better idea of why the code was written this way.

If I wanted to study the code some more, I could continue to hit hot keys to turn on various architectural layers as needed.

Appendix - Code Repositories

st repository example test.st including code generators to Python and JS (see README.md) tiny pbp repository - WIP (work in progress) re-writing the PBP kernel in.stform

The st-mode elisp code used in this experiment is contained in the elisp/ subdirectory of the st repository. I included the generated elisp code in my init.el, and turn it on with M-x st-mode on a per-buffer basis.

Appendix - References and Further Reading

The Parts Based Programming (PBP) toolset contains T2T as one of the tools: PBP all tools (PBP, T2T, das2json)

The tools are already included in the st repository mentioned above.

Appendix - Dynamic Scoping

The generated code includes boilerplate code for creating several stack data structures - one stack for container objects and a separate stack for cause objects. The point of this example is to demonstrate techniques - you don’t need to understand what containersand causes are, to understand how to use these techniques. These objects are just constructs required for describing the full architecture from which test.st was copied (the “tiny pbp” architecture).

In most modern programming languages, we would use pass-through parameters instead of these stacks, i.e parameters that get passed into functions which only pass the same parameters, unused, through to other functions that get called. Pushing the data onto stacks is like wrapping a dynamic scope (“with-…”) around certain call chains. This stack-based technique can cause bugs in hand-written code, but is a useful and viable approach for use in generated code.

The “with-…” syntax and dynamic scoping is borrowed from the Lisp world and can be applied to newly-invented meta-syntaxes such as the st syntax shown in this example.

Appendix - Emacs Key Bindings

M-1 (meta-1) - display only lines that begin with a single unicode character “⋅”, hide all other lines M-2 - display lines that begin with one or two “⋅” M-3 - display lines that begin with one, two or three “⋅” M-4 - display lines that begin with one, two, three or four “⋅” M-5 - display lines that begin with one, two, three, four or five “⋅” M-6 - display lines that begin with one, two, three, four, five or six “⋅” M-0 - toggle between showing all lines and between showing only lines that are not prefixed by any “⋅”, i.e. show everything or show only the code

The elisp code, generated by Claude, inserted into my init.el

; this is code that I pasted into my ~/.emacs.d/init.el to install st-mode

;;; elision for .st files - invoke explicitly with M-x my-dsl-outline-mode
;;; -*- lexical-binding: t; -*-

(defvar st-al-char "⋅"
  "Character marking an architectural line (AL).")

(defvar st-default-image-width 400)

(defun st--line-al-level ()
  "AL level of the current line: count of leading ⋅ after whitespace, 0 if none."
  (save-excursion
    (beginning-of-line)
    (skip-chars-forward " \t")
    (let ((start (point)))
      (skip-chars-forward st-al-char)
      (- (point) start))))

;; --- images ---

(defun st-remove-images ()
  (interactive)
  (remove-overlays (point-min) (point-max) 'st-image t))

(defun st-display-images ()
  "Render ![alt][width](path) links as inline images."
  (interactive)
  (st-remove-images)
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward
            "!\\[\\([^]]*\\)\\]\\(?:\\[\\([0-9]+\\)\\]\\)?(\\([^)]+\\))"
            nil t)
      (let* ((width (if (match-string 2)
                         (string-to-number (match-string 2))
                       st-default-image-width))
             (path (match-string 3))
             (full-path (expand-file-name
                         path (file-name-directory (or buffer-file-name default-directory))))
             (beg (match-beginning 0))
             (end (match-end 0)))
        (when (and (file-exists-p full-path)
                   (image-type-available-p 'svg))
          (let* ((img (create-image full-path 'svg nil :max-width width))
                 (ov (make-overlay beg end)))
            (image-flush img)
            (overlay-put ov 'st-image t)
            (overlay-put ov 'display img)))))))

;; --- level-based line visibility (M-1..M-9, M-0) ---

(defvar st-level-invisible-symbol 'st-level-hidden)
(defvar-local st--non-al-only nil)

(defun st--hide-region (beg end)
  (let ((ov (make-overlay beg end)))
    (overlay-put ov 'st-level-overlay t)
    (overlay-put ov 'invisible st-level-invisible-symbol)))

(defun st-clear-level-overlays ()
  (remove-overlays (point-min) (point-max) 'st-level-overlay t))

(defun st-show-level (n)
  "Show only AL lines with level 1..N; hide deeper AL lines and all non-AL lines."
  (setq st--non-al-only nil)
  (add-to-invisibility-spec st-level-invisible-symbol)
  (st-clear-level-overlays)
  (save-excursion
    (goto-char (point-min))
    (while (not (eobp))
      (let ((level (st--line-al-level)))
        (unless (and (> level 0) (<= level n))
          (st--hide-region (line-beginning-position)
                            (min (point-max) (1+ (line-end-position))))))
      (forward-line 1))))

(defun st-show-everything ()
  (remove-from-invisibility-spec st-level-invisible-symbol)
  (st-clear-level-overlays))

(defun st-show-only-non-al ()
  (add-to-invisibility-spec st-level-invisible-symbol)
  (st-clear-level-overlays)
  (save-excursion
    (goto-char (point-min))
    (while (not (eobp))
      (when (> (st--line-al-level) 0)
        (st--hide-region (line-beginning-position)
                          (min (point-max) (1+ (line-end-position)))))
      (forward-line 1))))

(defun st-toggle-non-al ()
  "M-0: toggle between showing everything and showing only non-AL lines."
  (interactive)
  (if st--non-al-only
      (progn (st-show-everything) (setq st--non-al-only nil))
    (st-show-only-non-al)
    (setq st--non-al-only t)))

;; --- keymap & mode ---

(dotimes (i 9)
  (let ((n (1+ i)))
    (eval
     `(defun ,(intern (format "st-show-level-%d" n)) ()
        ,(format "Show only AL lines with level <= %d." n)
        (interactive)
        (st-show-level ,n)))))

(defvar st-mode-map
  (let ((map (make-sparse-keymap)))
    (dotimes (i 9)
      (let ((n (1+ i)))
        (define-key map (kbd (format "M-%d" n))
          (intern (format "st-show-level-%d" n)))))
    (define-key map (kbd "M-0") #'st-toggle-non-al)
    map)
  "Keymap for `st-mode'.")

(define-minor-mode st-mode
  "Minor mode for architecturally-annotated code with leveled folding."
  :lighter " ST"
  :keymap st-mode-map
  (when st-mode
    (setq-local outline-regexp (concat "[ \t]*" (regexp-quote st-al-char) "+"))
    (setq-local outline-level #'st--line-al-level)
    (outline-minor-mode 1)
    (st-display-images)))

Languages That Stretch Your DI Capabilities and Imagination

Paul Tarvydas — Sat, 11 Jul 2026 16:18:11 GMT

DI means Design Intent — what people usually call “software architecture,” the expression of intent rather than just code. I’ve come to believe you don’t become a good architect by getting really good at one paradigm. You become a good architect by studying many paradigms, deliberately, including the ones that feel foreign or obsolete.

Most of us today learn one paradigm deeply — the function-based / functional paradigm — and mistake fluency in it for architectural skill. But DI is bigger than functions and call stacks. Below is a list of books, papers, systems, and talks that pushed my own thinking outside that box. None of them are “productivity hacks.” They’re worldviews.

Smalltalk

Start with the Smalltalk Blue Book — specifically Section Four, which quietly disappeared from the more commonly circulated Purple Book. Smalltalk isn’t “objects with methods” the way most OOP languages borrowed the idea. It’s a complete environment where everything, including the language itself, is a live, inspectable object. Section Four is where that worldview is most exposed: it gives an implementation of Smalltalk in a subset of Smalltalk, including code for the virtual machine and the then-new generational garbage collector.

Parsing as a paradigm

Parsing Expression Grammars — Bryan Ford’s original concept and paper — reframe parsing as ordered choice rather than ambiguous grammar resolution. It’s a genuinely different way to think about structuring recognition and control flow. OhmJS is a modern, very approachable implementation of these ideas, and worth playing with directly rather than just reading about.

BNF, and its more common successor properly called eBNF, is itself a DSL for writing parsers. PEG and OhmJS use a syntax very much like eBNF’s. But the purpose differs from what came before: traditional compiler-compiler tools like YACC are meant for specifying languages, whereas OhmJS is better understood as a DSL for specifying parsers.

Before PEG, I used recursive descent, and S/SL. PEG just makes this so much easier — almost like discovering regexes after years of hand-rolled string matching. PEG’s greatest contribution is arguably the return of backtracking, which had been mostly banished during the 20th century out of a bias toward premature optimization. Backtracking makes it much easier to describe parsers, even where it costs you some raw performance.

One of the first things I wrote in OhmJS (which I think of as an improved PEG) was a DSL I call RWR. Using OhmJS plus RWR, I built a small tool called T2T, part of a larger toolkit called PBP. With T2T — and the Ohm-editor grammar REPL — I can crank out custom little languages in minutes or hours. At this point I transmogrify these little languages into running Python code, often as PBP components or as stand-alone Python. I’ve also generated JavaScript, Common Lisp, and Odin code from the same little-language definitions.

Statecharts

David Harel’s statecharts extend finite state machines with hierarchy, concurrency, and broadcast communication — and they express behavior as a first-class architectural artifact instead of burying it in conditionals. I made a video of my reading of the original paper: Statecharts — Papers We Love video.

Logic programming

The bare essence of Prolog is that you can write exhaustive search using very little code. In our current bevy of programming languages, you need to write tangled code that contains loops within loops and encourages bugs and incomplete search strategies. Prolog and its descendants invert the usual relationship between data and control: you state relations, and the engine searches for solutions. See my Prolog-related referencesroundup, and miniKanren for a minimal, embeddable take on the same idea — relational programming small enough to implement in an afternoon and deep enough to reshape how you think about search and backtracking.

Atari Pong (1972)

This one is the sharpest possible contrast to “software architecture” as we usually mean it. The original 1972 Pong hardware fits on one page, is built from asynchronous components, and has no code at all. It’s pure architecture — signal flow and timing — with none of the sequential, function-call baggage we now treat as unavoidable. If you want a jolt to your assumptions about what “a program” even is, look at this schematic.

Sketchpad

Ivan Sutherland’s Sketchpad (1963) predates almost everything we now consider modern in interactive and object-oriented computing — constraints, prototypes, real-time graphical manipulation. It’s worth understanding as the ancestor a lot of paradigms forgot they had. Sketchpad was written in assembler — Sutherland did not need automated type checking and all of the baubles we’ve since added to create useful software.

The Big OOPs

Casey Muratori’s talk The Big OOPs argues that mainstream language design — OOP in particular — took a wrong turn for a huge class of real-world problems, game programming among them. Whether or not you agree with his conclusions, it’s a useful antagonist to sit with: it forces you to defend or abandon assumptions you probably never examined.

Unix V1 and the C that almost wasn’t

Research Unix is usually remembered as “written in C,” but V1 was assembler, and only V4 was ported to K&R C. K&R C and ANSI C are not the same language in spirit: K&R C is unapologetically tied to the utility of a specific machine (the PDP-7), while ANSI C is built around portability and type-checking across many architectures. Reading Unix history with that distinction in mind changes how you read the code — it’s a different set of design pressures than the C we write today.

Small-C

Small-C, also published in Dr. Dobb’s Journal, is where I learned what a compiler actually does — by implementing it on a V7 Unix system running on a PDP-11. Everything compilers have added since then is, in a real sense, just improvements on this basic idea. The Dragon Book is largely a way to make this same idea more efficient.

Holt’s Concurrent Euclid, the UNIX System, and TUNIS

Richard Holt’s book, Concurrent Euclid, The UNIX System, and TUNIS, especially Chapter 10, “Implementing a Kernel,” is a masterclass in expressing concurrent system design with a language built specifically for it, rather than bolting concurrency onto a sequential language after the fact.

S/SL

S/SL (Syntax/Semantic Language) is dataless — control flow only. It’s arguably the epitome of OOP and modularity, stripped of everything except the control structure that OOP is supposedly about. Seeing that idea in its purest form is clarifying in a way that “real” OOP languages, cluttered with data and syntax, rarely are. The code repository contains the S/SL specification, a version of S/SL written for C, and a full-blown compiler (PT Pascal) written in a Pascal version of S/SL.

Cordy’s Orthogonal Code Generator

James Cordy’s Ph.D. thesis work on orthogonal code generation — published with Richard Holt as Code Generation Using an Orthogonal Model (Software—Practice and Experience, 1990) — is worth reading right alongside S/SL, since it comes out of the same Toronto compiler lineage. In it, Cordy touches on techniques that look strikingly modern today: ideas that rhyme with Justine Tunney’s work on Binary Lambda Calculus, with Holt’s own Data Descriptors paper, and with a small DSL Cordy built for generating portable code using decision trees, which he called MISTs. Data descriptors in particular show how normalization — treating machine-level addressing as data to be normalized rather than handled as ad hoc special cases — can make code generation dramatically simpler to write.

Tiny BASIC

Tiny BASIC is a minimal BASIC interpreter designed to fit in a few kilobytes of memory on early microcomputers. The canonical source is in Volume 1 of Dr. Dobb’s Journal — short enough to read whole, in one sitting, rather than in disconnected fragments.

Frits van der Wateren’s Lisp

Frits van der Wateren’s Lisp is another small, complete implementation worth reading end-to-end — the kind of codebase small enough to hold entirely in your head at once, which is exactly the point of studying it.

SectorLisp

SectorLisp is a Lisp interpreter that fits in a 512-byte boot sector. It’s tiny — purer than pure functional programming, in the sense that there’s no room left for anything but the essence of the idea. A good antidote to the notion that expressive power requires size.

Prolog Control in 6 Slides

Nils Holm’s Prolog Control in 6 Slides distills the control mechanism of Prolog — unification, backtracking, the resolution loop — into something you can hold in your head in one sitting. Short, dense, and worth re-reading more than once.

Forth

Thinking Forth by Leo Brodie isn’t really about the Forth language — it’s about a design philosophy: factoring problems into small, composable words, thinking bottom-up, and treating the language itself as something you extend to fit the problem rather than the other way around.

Rebol and Altscript

Rebol, designed by Carl Sassenrath — also the architect of the Amiga OS kernel — is one of the first languages to have PEG-style parsing built directly into the language itself. The result is that Sassenrath was able to build very powerful libraries using a surprisingly small amount of code. (See also the official Rebol site.)

Sassenrath’s successor project, Altscript, proposes a very interesting and very rich set of fundamental data types — around fifty lexically recognized “atoms” built directly into the language.

Video presentations

Two talks that belong in this list even though they’re not papers or code:

Alan Kay, The Computer Revolution Hasn’t Happened Yet — a reminder that most of what we call “modern” computing is still a fairly narrow, accidental slice of what was actually envisioned.
Capt. Grace Hopper on Future Possibilities — my own writeup of her talk, which is startlingly prescient about where computing was headed.

Why this matters for DI

None of these are “better” than the functional paradigm. That’s not the point. Each one makes a different set of tradeoffs visible — between data and control, between synchronous and asynchronous, between portability and machine-specific utility, between huge and minimal. If you’ve only ever thought in one paradigm, you don’t know which of your assumptions are fundamental and which are just habits picked up from the tools you happened to learn first.

Studying paradigms outside your comfort zone is how you build the vocabulary to express Design Intent clearly — not just to write code that runs, but to build systems whose architecture says what it means.

Five Whys for Software Component Isolation

Paul Tarvydas — Sun, 05 Jul 2026 09:05:35 GMT

Q: Why can’t we plug software modules together like LEGO® blocks?
A: Because software is too complicated.
Q: Why is software too complicated?
A: Because we can’t plug software modules together like LEGO® blocks.
Q: Why can’t we plug software modules together?
A: Because the interfaces are too complicated.
Q: Why are interfaces too complicated?
A: Because libraries and APIs have hidden dependencies.
Q: Why do libraries and APIs have hidden dependencies?
A: Because we use programming languages that hide dependencies.
Q: What kind of dependencies are hidden by languages?
A: CALL / RETURN leaves breadcrumbs on stacks, forming dynamic dependency chains.
Q: Why does CALL/RETURN leave breadcrumbs on the stack?
A: RETURN needs to follow the breadcrumbs back to the caller.
Q: What happens when a CALLed routine calls another routine?
A: The callee becomes the caller and leaves another breadcrumb on the stack.
Q: Why is a stack used? Why not just use a register?
A: Stacks are used so that previously laid breadcrumbs are not over-written. If we didn’t have an automatic stack mechanism to save our breadcrumbs, we’d have to save them manually in some sort of list.
Q: Is the stack of breadcrumbs a dynamic data structure?
A: Yes.
Q: Is the stack of breadcrumbs a dependency chain?
A: Yes:
Q: Is the stack not just a list?
A: Yes, but it is an optimized list.
Q: Why is it necessary to optimize lists to make stacks?
A: Because we need to optimize memory usage.
Q: Why do we need to optimize memory usage?
A: Because memory is expensive
Q: Why is memory expensive?
A: Memory used to be expensive in the 20th century.
Q: Is memory still expensive in the 21st century?
A: No.
Q: Why do we use techniques to optimize memory usage, when memory is no longer expensive?
A: Uh, because we’ve always done it that way.
Q: Did we notice that the ground truth has shifted? Memory used to be expensive, but is no longer expensive?
A: Uh, no, we didn’t notice.
Q: Why didn’t we notice?
A: Uh, because we believe in building on the shoulders of giants.
Q: Why don’t we simply use many CPUs each with private memory, each containing single thread?
A: Because CPUs were expensive.
Q: Are CPUs still expensive in the 21st century?
A: No.
Q: Why do we share memory between cores instead of using completely isolated CPUs?
A: Because using shared memory can be faster for some applications, like graphics.
Q: Does the use of shared memory lead to needing extra software and complication?
A: Yes. We call that “thread safety”.
Q: Could we simplify programs and programming languages by removing all of the extra code needed to solve thread safety issues?
A: Yes. Massively. Isolated CPUs can’t share memory, hence, do not have thread safety issues.
Q: Why do we keep relying on shared memory models for programming?
A: Uh, because we’ve always done it this way.
Q: Is there a good reason not to switch to a message-passing model for programming in the 21st century?
A: Not really.
Q: Then, why do we keep hanging on to an old-fashioned, inefficient and complicated model?
A: Uh, because we’ve always done it this way.
Q: Could we develop faster workflows for program development?
A: Yes.
Q: Why haven’t we done that?
A: Uh, because we’ve always done it the old-fashioned way.
Q: Are we in the weeds?
A: Yes.

Other Issues

Other issues, not discussed here, include…

Topology Blindness

Reasoning about a component without regard for what it’s wired into.

Single, Strict Routing Policy

Our use of functions in software implies the use of a single, strict routing policy.

When a function CALLs another function, there is a requirement that the callee returns - routes - a value back to the caller.

The callee is strongly discouraged from having “side effects” such as sending values, messages and events to other receivers.

The Parts Based Programming Kernel

Paul Tarvydas — Thu, 02 Jul 2026 08:50:36 GMT

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.

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.

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.

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).

When a PBP system starts up, it does three things in sequence:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 structures, memory barriers. Enormous bodies of engineering work devoted to managing a problem manufactured by 1960s economics. Race conditions are particularly nasty because they aren’t just hard to reproduce — they’re hard to reason about. The program’s behavior depends on timing relationships that aren’t visible in the code.

The cleaner model: a zillion totally isolated CPUs, each with its own private memory, each running exactly one thread, communicating only by passing messages. No scheduling. No shared memory. No thread safety. No shared-memory race conditions — and when ordering matters, it’s visible in the diagram, not buried in hardware timing. The complexity evaporates — not because of clever engineering, but because the source of the complexity was never necessary in the first place.

CPUs used to cost as much as a house. So we built six decades of software around the assumption that we’d only ever have one.

What PBP Is About

That assumption no longer holds.

CPUs are cheap. The economics that forced the shared-memory, time-sliced model onto us have reversed. And yet we keep writing software as if we’re still rationing a single VAX.

PBP is not about managing cores or squeezing performance out of on-chip cache coherency hardware. It’s a way to think about multi-processing using the simplest possible model: multiple full-blown, totally isolated CPUs with private memory, passing messages between them. On a development machine, the PBP kernel simulates this with coroutining. In production, you can deploy the same architecture across genuinely separate machines, because the model never assumed anything else.

The kernel is simple because the model is simple. A registry, and coroutining. That’s all you need to build things that reflect how you actually think about them — rather than how a 1960s time-sharing system happened to organize them.

We didn’t have to make software this complicated. We can stop.

Examples

Simplest Hello World That Guarantees Mevent Order

Test Jig

Kernel Code Generator

The PBP kernel is generated from a layered diagram containing some 40 parts. This is but one of the layers.

Raw Notes

The above was cowritten with Claude. My initial concise notes are below:

initial notes
comments regarding first draft

Further

Towards Parts Based Programming
PBP cookbook playlist
Decision Tree Diagram Transmogrifier
State Machine Diagram Tool

FDD LLM - 5 Whys Tool - code repository
State Machine Tool - code repository
Decision Tree Tool - code repository
PBP all tools (PBP, T2T, das2json)

The Spherical Cows of Programming
The Wrong Spherical Cow - First Principles of Parts Based Programming
The Case For Composable Notations (1 / 5) - The Spherical Cow We Forgot We Were Riding
The Case For Composable Notations (2 / 5) - The Restrictions That Came With The Cow
The Case For Composable Notations (3 / 5) - State Isn’t The Enemy
The Case For Composable Notations (4 / 5) - Ease of Expression Is the Whole Point
The Case For Composable Notations (5 / 5) - UNIX Already Showed Us the Way
The Case For Composable Notations (6 / 5) - WIP - Notations in Progress

Separating Architecture From Implementation

Paul Tarvydas — Fri, 26 Jun 2026 12:52:26 GMT

With our current programming languages it is difficult to separate architecture from implementation.

The reason for this is just a minor detail: functions are implemented on hardware using the CALL/RETURN instruction.

The implementation is that the CALLer suspends (blocks) until the callee returns something. This minor detail winds deep dependencies throughout code and makes it difficult to reason about what is going on.

The best way to break the dependency is to separate - control-flow wise - the caller from the callee, i.e. by using pure message sending (instead of impure message passing, as is implemented by CALL/RETURN and calling conventions). I built this into Parts Based Programming (PBP) through instinct.

Hardware ICs work this way, too. If actions need to be synchronized, the are explicitly, externally synchronized by the architect, not vagaries of the hardware such as CALL/RETURN (and cache coherency).

Concurrency (Part 2 of 2)

Paul Tarvydas — Wed, 24 Jun 2026 13:56:58 GMT

“Concurrency” is a concept tuned for allowing multiple functions to operate independently in the synchronous, sequential paradigm. It essentially uses a “trick” to allow this to happen - it assumes that the multiple functions are internally synchronized and it makes them run in a sequential manner.

This “trick” is useful for allowing us to think in terms of computation, but it doesn’t address asynchronous systems. Hence, it only addresses about 5% of reality (this number is pulled out of thin air and is not measured, yet, I base it on the fact that cosmology is based on the functional paradigm which pushes aside 95% of the problem that can’t be addressed in functional form, and calls it “dark matter”)

only simulates parallelism, is not full parallelism
teaching this has obscured the fact that concurrency is not true parallelism - people think that they are getting parallelism when using “thread libraries”, but they are only getting time-slicing, i.e. multiple functions running on a single computer in a synchronous - not asynchronous - manner.
micro-managed sharing of memory at the cell level instead of message-passing between isolated components
upper-level, explicit message-passing vs. lower-level, implicit memory sharing
the simplest, most efficient system would be a computer that is running exactly one program and not time-sharing the same computer with other programs
- this would remove the need for a lot of internal complexity, i.e. “thread safety”, since the single program does not share memory with any other program, hence, the compiler and the programming language could be massively simplified
If we imagine multiple such devices running single programs, but not sharing memory, then the best way for them to communicate and synchronize would be to pass message packets to one another
- This is what PBP does - it creates “parts” that are self-contained and do not share memory with other parts, it uses send(...) to explicitly send message packets (“mevents”) between parts.
- You are forced to write code that contains explicit message passing, instead of writing code that relies on implicit memory sharing. This maps to asynchronous reality better. # See Also

Paid subscriptions are a voluntary way to support this work.

Concurrency (Part 1 of 2)

Paul Tarvydas — Wed, 24 Jun 2026 13:55:57 GMT

Simplified sketches that show the difference between concurrency and pure message passing.

Computer With Concurrency

A simplified sketch. Note that functions (A-I) might be one function or a tightly coupled thread of functions calling functions (which is really just one big function).

Not shown: all sorts of complicated extra code that belongs to the dispatcher and operating system.

Threads run more slowly than they could due to time-slicing and due to operating system overhead.

This only simulates parallelism using a mechanism that is unrealistic for geographically distributed systems, i.e. memory sharing. In addition, the simulation assumes that the processes are automagically synchronized (via memory sharing and cache coherency and extra hardware).

Each program (functions A-I) is actually a state machine. Programmers do not get to easily control and architect this behaviour. Context switching is performed by algorithms buried in the operating systems.

System With Pure Message Passing

Not shown: code that polls (or reacts to) incoming messages on input ports.

This can be simulated on a single development system by ensuring that programs cannot share memory.

Each program gets almost 100% of each separate CPU, hence, runs more quickly than on time-shared machines. # See Also

Paid subscriptions are a voluntary way to support this work.

Repeating Architectural Patterns

Paul Tarvydas — Wed, 24 Jun 2026 13:53:55 GMT

As we build a PBP version that mimics the original Atari Pong schematic, I doubt that we will actually see strictly repeating high-level patterns emerge. I think that the strictly repeating patterns are embodied in the ICs used in the original circuit. Combinations of ICs on the schematic are used to create architectural chunks that don’t repeat verbatim.

The design of ICs is about as far as we can take the idea of strict, repeatable patterns. The design of the Pong schematic uses low-level repeatable patterns to build up higher-level chunks of architecture.

PBP is an attempt to allow expressing such chunks in a readable manner. We should be able to reuse low-level parts to build up customizable medium-level parts that are used to build up specific parts for a specific project.

Seasoned “architects” may recognize such high-level patterns and reuse them as customizable ideas that can be used (in a modified way) in other architectures.

We already see this kind of thing happening in electronics and other fields of engineering, e.g. civil engineering and bridge design - not all bridges are designed the same way, but sometimes general architectural features are reused.

When I showed the Pong schematic to someone versed in electronics design, they “immediately” saw architectural patterns in the design, but with tweaks. For example, a comment was that BCD score was being rasterized for display on a then-standard cathode ray tube (CRT). The person saw that some low-level ICs were used in an idiomatic manner.

I guess one might say that PBP is a way to build up custom Designs using very low level patterns, while leaving the high-level Design readable. Currently, electronics schematics are filled with implementation details that obfuscate the design to anyone but seasoned architected.

Likewise with the way we write code. The code consists of a bunch of details that don’t tend to reveal the over-lying Design, unless the programmer(s) was careful to use common idioms and unless the reader is a seasoned programmer who rapidly recognizes the use of such idioms.

The colourized version of the Pong schematic was probably done by a seasoned electronics person. The person recognized areas within the circuit that were aimed at solving specific sub-problems, then grouped such areas together by colouring them. People who aren’t versed in reading schematics can understand the colourized groups without needing to understand the actual details of the electronics inside each group.

Resources

Articles

Videos

Examples

PBP Kernel Portability
Larson scanner written in PBP
Pong in PBP (very WIP)
Reasoning About Ordering
Exploring Techniques and Notations for Augmenting DX (Demo for FoP)
ASON sample tokenizer
early code repo for ė (eh) ancestor of PBP (contains basics for PBP/0D reasoning)
thinking Prolog: small sample of reasoning in Prolog
Nils Holm’s Prolog in Scheme code ported to Common Lisp
sample of creating “verbatims” in little language
- verbatims enable staged computation
- if a pass converts code to final code, it wraps the generated code in a “verbatim” and subsequent passes just ignore it and don’t try to parse it
example of using “applySyntactic<…>” in Ohm
using OhmJS to convert markdown to structured (bracketed) form
example of converting textual behaviour trees to JSON then to C++
Ohm In Small Steps (diary of converting some Scheme code to Javascript)
PT Pascal and S/SL
Call Return Spaghetti (essay)

AI Is No Code

Paul Tarvydas — Wed, 24 Jun 2026 12:37:46 GMT

AI is No Code for one specific architectural pattern. The one I call “function-based”, which is synchronous and sequential.

You can build other architectural patterns on top of that one architectural pattern, but the substrate function-based pattern restricts your architectural thinking (“Design”). For example, you cannot build Forth on top of that substrate. Forth doesn’t use the function-based “calling convention”. The best you can do is to build a fake Forth that adheres to a prematurely-supplied calling convention. Nor, can you build something that is asynchronous and fully parallel on top of that substrate, since the substrate has already eliminated asynchrony from any design you put on top of it. The best you can do is to define synchronous “reactors” and then plumb them together by hand in a manner analogous to writing assembler.

I’ve built many Designs using a different substrate architectural pattern - asynchronous, electronic IC based. From that experience, I conclude that the function-based pattern is too restrictive and bloatful and that we need to break free of it. AI won’t help with that.

Anti Assimilation

Paul Tarvydas — Fri, 19 Jun 2026 11:39:44 GMT

Anti Assimilation

2026-06-19

The way we build software - time-shared and centralized - is no longer appropriate for the problem domains of the 21st century, regardless of how convenient the synchronous, sequential, centralized paradigm seems.

Any code sitting atop Linux (or other even more bloated operating systems) has a base tax of about 30,000,000 lines of code on top of CPU ICs that use many more transistors than what was needed to build Sketchpad, Visicalc, Turbo Pascal, Unix V1 (UNIX was originally written in assembler, not K&R C), etc. We can do a lot better.

Continuing to build software the same way over and over again, expecting different results is a death march based on unwillingness to accurately assess the cost of doing so and based on the belief that there is only one purpose for “computers” (a better name might be RM - Reprogrammable Machines).

Pure functional programming - modern Sector Lisp - costs about 354 lines of assembler. Most other programming languages pay a huge tax for stretching and generalizing the functional programming model.

We need to think outside of the box of the synchronous, sequential, centralized model. Machine code and ICs can support many more kinds of models than just functional programming (K&R C may have been a convenient abstraction, but, subsequently, C has been distorted into a functional programming language (albeit flawed) replete with function-based calling conventions).

Progress should result in less code. I don’t believe that this is happening.

Our current programming model makes us believe that issues - e.g. assignment, synchronous concurrency, asynchronous parallelism, thread safety, control flow - falling outside of the functional, synchronous, sequential model can be ignored or simply assimilated. Yet, Harel came up with a better notation for one of those issues some 40 years ago (Statecharts for reactive control flow). I think that we should be using models for programming that allow us to compose solutions using many paradigms, each with laser-focused languages to support them - specialization instead of generalization and the kitchen sink approach. Decentralization instead of centralization and assimilation. Eliminating problems instead of laboriously assimilating solutions to them.

Switching to a decentralized model could eliminate the issue of thread safety. Simply eliminating thread safety concerns would noticeably reduce the size and complexity of programming languages. Since the main role of operating systems is to act as scaffolding to support the functional model, can something be done about that issue?

Everything we’ve accomplished in the past 50 years fits inside just one of the bubbles on my diagram labelled “app” in a previous article. We haven’t really addressed the rest of the stuff, other than by applying notation worship to assimilate each new gotcha, in a whack-a-mole manner, into the ball of stuff that we already have. Grace Hopper warned against this approach.

Functions and math-like notation (mangled by 500 year-old Gutenberg technology) aren’t the only way to program the things we call “computers”.

It is entirely reasonable to specialize and drill down onto a thin slice of programming. But, it must be remembered that this is not programming, it is just a thin slice of programming. Looking at all problems through a single lens has a cost.

Programming Simplicity

TDPL, BUPL, and the Trade-Off We Never Revisited

References

See Also

Experiment — Projectional Viewer

Purpose

Method

Observations

Conclusions

Further ideas: composing many little languages instead of one paradigm

Appendix — Generated pellide-view.el Code

Appendix — T2T Grammar pelide.ohm

Appendix — T2T Rewrite Rules pelide.rwr

See Also

Simplicity Is in the Eye of the Beholder

What Is Simplicity?

Examples of Simplicity

Examples of Anti-Simplicity

How Do You Teach Simplicity?

References

See Also

Macros With OhmJS

grammar

test

ohm-editor

Appendix - T2T

Appendix RWR

Appendix - PBP

Appendix - Further About PBP

Skipping With OhmJS

grammar

test

ohm-editor

See Also

Preventing the Collapse of Civilization

See Also

Opinions About Compiler Building

Appendix - T2T

Appendix RWR

Appendix - PBP

Appendix - Further About PBP

See Also

Stop Confusing Languages With Compilers

Markdown for code

Explain it to an LLM

Nobody has to like the target language

Little languages, on purpose

Appendix - T2T

Appendix RWR

Appendix - PBP

Appendix - Further About PBP

See Also

Simplification and Two Kinds of Code

Appendix - T2T

Appendix RWR

Appendix - PBP

Appendix - Further About PBP

See Also

Implementing The Experimental ST Meta-Syntax

Appendix

See Also

Experiment - Separating Architecture From Code

Highlights

Accompanying Video

Introduction

Script

Appendix - Code Repositories

Appendix - References and Further Reading

Appendix - Dynamic Scoping

Appendix - Emacs Key Bindings

See Also

Languages That Stretch Your DI Capabilities and Imagination

Smalltalk

Parsing as a paradigm

Statecharts

Logic programming

Atari Pong (1972)

Sketchpad

The Big OOPs

Unix V1 and the C that almost wasn’t

Appendix — Generated `pellide-view.el` Code

Appendix — T2T Grammar `pelide.ohm`

Appendix — T2T Rewrite Rules `pelide.rwr`