Programming Simplicity

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Some Thoughts About The Computing Historian Recovering Ideas We Threw Away

Paul Tarvydas — Tue, 14 Apr 2026 14:18:39 GMT

TL;DR

Some Thoughts About The Computing Historian: Recovering Ideas We Threw Away

The internet is asynchronous multi-tasking. We already solved it in hardware. Software academia re-complicated it.
Design recovery is archaeology — and we need a meta-language for the dig.

L;R

We Finally Have It

The internet is asynchronous multi-tasking. Many independent machines, running at their own speeds, communicating when they choose to.

This is not a new idea. Hardware has always been asynchronous. Every chip on a PCB runs at its own speed. Every peripheral operates independently. Hardware engineers have been composing asynchronous components for decades. It works.

Software did not inherit this. Software multi-tasking is a rotary switch — a scheduler cycling through tasks, one at a time, pretending to be simultaneous. The OS is a software implementation of something a hardware switch does cheaper, faster, and without a growing list of security vulnerabilities.

L1 caches are beginning to make CPU cores genuinely independent. But this is an overly complicated path to something you can achieve by buying several Arduinos.

The Concurrency Illusion

Software inherited “concurrency” problems from shared memory. Shared memory is a local decision that became a global constraint. The internet does not share memory. Machines share data — they send messages, they do not hand off pointers. This is not a coincidence. It is the correct design.

Every “concurrency” problem on the internet is simpler than the equivalent problem in a multi-threaded process, for exactly this reason. The difficulty has been re-introduced artificially by building internet services that internally revert to shared-memory designs.

The wheel was invented. Then reinvented with a flat side.

What Academia Optimized For

Modern computing has been shaped by academic concerns, not UX concerns. The abstractions that dominate — type systems, garbage collection, monads, effect systems — are refinements of notation for humans writing programs. They are not refinements of how machines work.

Casey Muratori’s The Big OOPS makes this precise: the abstractions that evolved are measurably inefficient for real reprogrammable machines. The gap between the abstraction and the machine has grown to the point where performance requires heroic effort to recover what was given away for free at the start.

Sketchpad was written in machine code. No type checker. No GC. It worked. It still impresses. The intellectual content was not in the language — it was in the design. We didn’t really need 50+ years of incremental complications added to programming languages to use CPUs as building materials.

Programming vs. Re-Programming

The fundamental invention of computer science is not “programming” itself. The fundamental invention is that of “re-programming” — the study of how to use reprogrammable machines effectively.

This distinction matters. A reprogrammable machine has GOTO. Removing GOTO from the notation does not remove it from the machine. It removes it from a specific paradigm for thinking about programs. That paradigm — functional, structured, referentially transparent — makes re-programming easier within its assumptions. It does not describe reality. It describes a useful fiction layered over reality.

The fiction has costs. The costs compound — and today we speak in terms of giga-bytes instead of kilo-bytes.

Design Recovery

Old software contains designs. The code that implements them is written for machines that no longer exist, in notations that no longer compile, under assumptions that were never written down.

Design recovery is the act of lifting a design out of its implementation — finding the decisions, the structure, the intent — and re-expressing it for a new machine.

This is archaeology. The artifact is not the pottery shard. The pottery shard encodes the artifact. The design is what you are after.

What notation captures a design without committing it to an implementation? Factbases of triples are a candidate — subject, predicate, object, nothing assumed about execution order or machine model. A design expressed as a factbase is substrate-neutral. It can be queried, transformed, re-emitted into any target notation.

This is what design recovery requires: a representation that sits above the code, below the marketing diagram, and carries enough structure to reconstruct intent.

We threw this away when we decided that code was the design.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Y2K: When Code Became Archaeology

Paul Tarvydas — Tue, 14 Apr 2026 12:36:26 GMT

TL;DR

Canadian banks in the late 1990s faced a deadline: fix 20+ million lines of COBOL before January 1, 2000, or risk systemic failure. Traditional software methods couldn’t meet the timeline. We used design recovery and transitive-closure factbases to hot-spot the problem. LLMs could have helped.

L;R

Around 1995, the Y2K problem stopped being theoretical.

The five major Canadian banks ran on COBOL. Much of that code had been written in an era when memory was expensive and every byte counted. Programmers stored years as two digits — 95 instead of 1995. Sensible optimization at the time. Time bomb in retrospect.

The question was not whether the code was broken. The question was where.

One bank we worked with had 22,000,000 lines of COBOL. Their staff of 200 COBOL programmers could handle, at best, 5% of the codebase per year. Manual inspection of the full codebase was not a viable path to January 2000.

Re-testing compounded the problem. Banks needed to run month-end simulations. A full re-test of the affected systems would have taken years — longer than the time remaining. And the banks had to stay live. Five days a week, the systems ran production. Three Saturdays per month were reserved for maintenance windows. Sundays were reserved for rollback — if a Saturday fix broke something, Sunday was the recovery day. That left one Saturday per month for Y2K remediation attempts. One.

Traditional methods were a non-starter.

Design recovery

Our companies — DRI and Legasys — approached the problem differently. We unparsed the COBOL code and constructed factbases: structured repositories of facts about the semantics of the code. Variables, their types, their assignments, their flows through the system. We then ran transitive closures over those factbases to trace how date-like values propagated across the entire banking system.

The goal was hot-spotting: not to examine everything, but to identify the code that needed examination. Triage by analysis rather than by guesswork.

It was not clean work. One persistent obstacle: variable naming. Not all variables named like dates were dates. Some variables that matched our date heuristics had been given female names by the original programmers and had nothing to do with calendar values. The factbase picked them up anyway. Every false positive cost time.

The reverse was also true and harder to detect: date values traveling through variables named for something else entirely.

What LLMs could have done

We were doing, essentially, semantic inference from code. We had automated tools, but the tools required human judgment at many points — deciding whether a variable was semantically a date, whether a computation path warranted investigation, whether a flagged routine was genuinely handling calendar arithmetic or something superficially similar.

LLMs are good at exactly this kind of disambiguation. Given a block of COBOL with a suspicious variable, an LLM can reason about what the variable likely represents based on its usage context, the surrounding arithmetic, and the names of adjacent variables. It can do this at a scale that human reviewers cannot.

Our transitive closure gave us a graph. An LLM could have pruned that graph — classifying nodes, filtering false positives, ranking which paths warranted human attention. The combination of automated structural analysis and language-model semantic reasoning would have been sharper than either alone.

We didn’t have that option in 1995. The tools that existed were the tools we used.

The problem got solved. The banks stayed live. January 1, 2000 passed without systemic failure.

But the experience left a clear lesson about software at scale: you cannot read what you cannot find, and finding requires inference, not inspection.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

LLMs as Design Recovery Engines

Paul Tarvydas — Tue, 14 Apr 2026 12:19:30 GMT

TL;DR — Old code is dying. The code isn’t the problem. The business rules embedded in it are. LLMs can extract those rules into a factbase. A factbase can be rewritten into any target language. This is Design Recovery, and it is the right job for LLMs.

L;R

Paul Rony, in the interview “The Computing Historian Recovering Ideas We Threw Away,” raises an alarm: old code stops running on new machines. The surface-level fix is emulation or virtualization. But that isn’t the real problem. The real problem is that the logic inside the code — the business rules, the domain knowledge, the decisions baked into conditionals and data shapes — is entombed in a language or runtime that is becoming inaccessible.

This is a portability problem. Compilers have grappled with portability for decades. The standard hack is #ifdef and conditional compilation. It works at the syntax level. It does not work at the semantic level. #ifdef lets you swap one system call for another. It does not let you understand why the original code made the choices it did.

Understanding why is Design Recovery.

Design Recovery is a field. It is underutilized. Its goal is to extract the abstract logic from a concrete implementation — to move from code upward to intent, from mechanism upward to policy. The resulting artifact is not another program. It is a description of what the program does, expressed in terms that are independent of any particular language or machine.

I have watched LLMs read code and summarize it. That is the first step. But a summary is not a factbase. A factbase is structured. It can be queried. It can be reasoned over. It is what you need if you want to rewrite the logic, not just describe it.

The pipeline I have in mind is:

old code → LLM (Design Recovery) → factbase(s) → LLM (code generation) → new code

The first LLM pass reads the old code and externalizes the business rules into a relational form. Prolog is a natural target for this. Barliman is interesting. Any system that lets you assert facts and query their consequences will do. The factbase is the intermediate representation. It is language-agnostic. It captures what the system does without committing to how.

The second LLM pass reads the factbase and generates new code in the target language or languages. At that point the portability problem is solved — not by running the old code, but by reconstituting its logic in a new form.

The key insight is that business rules are the scarce resource. Code is not scarce. Code is reproducible. A senior developer can write a sorting routine in any language you name. What cannot be reproduced from thin air is the accumulated domain knowledge that explains which things to sort, when, and what to do with the results. That knowledge is what is lost when old code becomes unrunnable. That knowledge is exactly what Design Recovery is designed to extract.

The question is whether LLMs are good enough at the extraction step. My reading of current LLM capabilities says: almost, but not yet reliably. LLMs can tell you what a codebase contains. They are less reliable at telling you what a codebase implies — the dependencies between decisions, the invariants that are never stated but always assumed, the edge cases handled by code that looks like error handling but is actually domain logic.

This is where relational representation becomes useful beyond just storage. If the factbase is Prolog-like, you can run queries against it. You can ask whether the extracted rules are consistent. You can ask whether a proposed rewrite satisfies all the original constraints. Meta-programming over the factbase becomes a verification tool. The LLM extracts; the relational engine checks.

Barliman is particularly interesting in this role because it works bidirectionally — given constraints on a program’s behavior, it can synthesize a program that satisfies them. If the factbase encodes the behavior constraints recovered from the old code, Barliman is a natural candidate for the synthesis step.

The remaining engineering problem is granularity. LLMs summarize at the wrong granularity for reliable rewriting. A summary that is accurate enough to describe the system to a human is not detailed enough to regenerate the system for a machine. The extraction step needs to be pushed further — toward a factbase granular enough that a second LLM, reading only the factbase, can reproduce the observable behavior of the original code without having seen the original code at all.

That is the hard part. It is also the interesting part.

The pipeline above is not science fiction. All the components exist. The LLM side improves monthly. The Design Recovery and relational reasoning sides have decades of theory behind them. What is missing is a toolchain that connects them. That toolchain is worth building.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Jail-Breaking Parser Technology (A Slight Return)

Paul Tarvydas — Mon, 13 Apr 2026 02:40:39 GMT

My view on parsers:

parsers are just string pattern matchers, i.e. the “easiest” parts of compilers
“regular expressions” used to be a compiler-only technology (e.g. LEX), then made the leap into other uses, appearing in places like UNIX tools (grep, sed, etc.), perl, javascript, python, etc. It is time for “parsing” to make that leap, too, but, 50 years after the release of YACC, this hasn’t really happened yet.

IMO, laborious CFG techniques discourage the thought processes for making this kind of leap whereas PEG techniques enable this kind of leap.

Making the leap into non-traditional compiler realms opens new doors and new views on programming techniques and even opens new doors on what we currently call “programming languages”.

IMO, current “programming languages” (GPLs - General Purpose Languages) are just variants of assembler. If we could simply stretch little syntactic skins over these assembler variants we could build new languages without needing to build more compilers from scratch, i.e. language design for the 21st century (IMO: SPL (Special Purpose Languages) not GPL, not-necessarily-Turing-complete, etc.) [ask me for my examples of little languages stretched over existing languages, if interested]

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Flow

Paul Tarvydas — Mon, 13 Apr 2026 02:06:30 GMT

TL;DR

Switching between thought streams wastes brain power. It is the cognitive equivalent of OS thrashing. Keeping your mind locked on one problem — “flow” — is a requirement for deep thought, for continuity, and for self-consistency of design. Breaking flow wastes time in thrashing, or, worse, makes you lose the thread of where the thought was leading.

L;R

The Core Dump Era

When programmers debugged in assembler, they examined core dumps.

A core dump is a raw snapshot of memory at the moment a program crashed. Finding the bug meant reading hexadecimal numbers and mapping them, manually, to program state. This was not just slow — it usually meant a full interruption. You had to hold the entire machine state in your head, reconstruct what the program was trying to do, and reason backwards to the fault.

Concentration was not optional. A single distraction usually meant starting over.

What IDEs Actually Did

We invented debuggers and IDEs. The common narrative is that they let us inspect program state more easily. That is true but incomplete.

What they really did was maintain flow.

Before a debugger, the feedback loop was: write code → compile → run → crash → decode dump → hypothesize → repeat. The core dump step was an enormous cognitive break. You left the problem domain entirely and entered a forensic domain. It was not that you entered a different mode of thought — it was that you lost continuity of the main mode. The thread you were holding snapped.

A debugger collapsed that loop. You stayed in the problem. You could watch values change in real time, set breakpoints near your hypothesis, confirm or refute quickly. The interruption was eliminated, or at least drastically reduced.

This is why IDEs let us build bigger programs. Not because they made any individual operation faster. Because they stopped the thrashing.

Thrashing

Operating systems thrash when they spend more time swapping pages than executing instructions. The work-to-overhead ratio inverts. The machine gets busier and busier while accomplishing less and less.

The brain does the same thing.

Every time you switch thought streams — from the problem you are solving to a niggly detail that interrupted you, and then back — you pay a re-entry cost. Reloading context. Reconstructing where you were. Remembering which threads matter and which do not. For complex problems, this cost is not seconds. It is minutes. And sometimes the thread is simply gone.

If the interruptions are frequent enough, you never get back to full depth. You skim the surface of each thought stream and switch again before you have accomplished anything meaningful.

Flow Is Not Mystical

Flow gets discussed as if it were a psychological luxury — something athletes and artists chase but engineers should feel slightly embarrassed about wanting.

That framing is wrong.

Flow is the state in which you are holding the problem, and only the problem, in working memory. It is a necessary condition for solving hard problems. It is not a bonus.

Gallwey named it in the context of sport, Csikszentmihalyi studied it formally. What all domains have in common is that the problems are complex enough that partial attention produces poor results. A basketball player in flow is not thinking about their feet. A programmer in flow is not thinking about syntax. They have both pushed the mechanics below conscious attention and freed their processing for the actual problem.

The mechanics have to be automated enough — or supported well enough by tooling — that they do not demand attention at all.

Flow is hard to measure. That is precisely why it tends not to be taught in school and tends not to appear in design requirements. But we need to be very cognizant of any feature, workflow, or tool choice that affects it.

What Breaks Flow

The obvious ones first. Notifications interrupt flow. Menus interrupt flow — even simple ones, because choosing requires shifting attention from the problem to the interface. Modal dialogs interrupt flow. Slow builds interrupt flow because they create a gap long enough that you wonder whether to do something else, and sometimes you do.

Saving a file is a small example worth noticing. Apple Notes and Obsidian save documents transparently, without any user action required. Emacs requires you to remember to save. That is an old-fashioned requirement from the 20th century — a demand that you appease the editor before you can trust your own work exists. Every “did I save?” moment is a micro-interruption, a small withdrawal from the concentration budget.

Two larger ones deserve their own treatment.

Strong typing. Type checkers, even after fifty years of development, are not perfect. They require you to stop and appease the type checker. When the type checker disagrees with you, you are snapped onto a different thought path — one dedicated not to the actual problem, but to satisfying a tool’s static analysis. This is not an argument against type checking. It is an argument for being honest about what it costs.

Changing your mind. As a project evolves, you learn new aspects of it — new nuances, new constraints, new understanding of what the design should be. Changing your mind about the design is easy. Going back and changing existing code, existing tests, existing assumptions, is an interruption. In compiler construction, for instance, if you change your mind about what the parser needs to do, you may need to divert your thoughts to whether the scanner needs to change too. Every dependent piece pulls you away from the idea that prompted the change in the first place.

The Waterfall method, ironically, was an attempt to preserve flow on a single vector — decide everything up front and never revisit it. That preserves a certain kind of continuity but breaks the ability to learn from the work as it develops. What we actually need are tools that make design changes instantaneous — so you can update your thinking without stopping to manage the consequences across a codebase.

Notation Is a Flow Tool

A notation that matches the problem domain keeps you in the problem. A notation that requires translation — from what you are thinking to what the language can express — is a context switch tax on every line.

This is why domain-specific notations matter. Not because general-purpose languages are wrong, but because a notation that does not match your problem forces you to think in two domains simultaneously. That is not flow. That is thrashing.

The deeper point is that no single language can satisfy flow concerns across the full range of problems, because every non-trivial problem involves multiple paradigms. What is actually needed is a workflow — or an IDE, or a composition tool — that allows the programmer to work with multiple notations simultaneously: little languages, sketches, diagrams, each appropriate to the aspect of the problem it addresses. The unit of composition is not the language. It is the thought.

The Sports Analogy Is Not a Metaphor

In competitive sports, staying in the zone is a performance variable coaches actively manage. Pre-game rituals, routine warm-ups, elimination of distractions — all of it exists to reach and sustain flow before and during performance.

Programming is not different. The stakes are just less visible because bugs do not score points for the other team.

If we took flow as seriously in programming as coaches take it in sports — if we designed tools, workspaces, and workflows around preserving concentration — we would build better software. Not incrementally better. Significantly better.

The Practical Consequence

Every tool decision is a flow decision.

Does this tool require me to understand it before I can understand my problem? Does this abstraction require me to think at two levels simultaneously? Does this workflow interrupt me at the moments I am going deepest?

These are not comfort questions. They are engineering questions. The answer affects throughput, defect rate, and the size and complexity of problems we can attempt at all.

The core dump was not just slow. It was a flow killer. The IDE was not just convenient. It was a flow restorer. That is why it changed everything.

Flow Is a Design Requirement

We treat flow as a side effect — something that happens when everything else goes right.

It should be a first-class requirement. Listed alongside correctness, performance, and maintainability. Evaluated deliberately.

When designing a new tool, the question is not only “does it work?” The question is also: does it keep the programmer in the problem, or does it pull them out of it?

Languages. A language that requires you to appease the compiler before you can express your idea is a flow tax. Boilerplate, type annotation ceremonies, incantations that satisfy the toolchain but communicate nothing about the problem — these are mandatory context switches, paid on every line. But further: a single language cannot satisfy flow across the full problem space. The shape of the solution should determine the notation, not the other way around. Flow-preserving tooling makes it possible to compose multiple notations — each a good fit for its subdomain — rather than forcing every thought into a single syntax.

Compilers. Error messages that describe the compiler’s internal confusion instead of the programmer’s likely mistake force a translation step. You decode what the compiler means and map it back to what you did. Python is a clear example — a single exception fills the screen with backtrace details, making you wade through the tool’s internal machinery to find what went wrong in your problem. Every decoding step is a micro-interruption. A compiler designed for flow gives you the error in terms of your problem, not its implementation.

IDEs. A “programming language” is, in one light, a simple caveman IDE — an interface for expressing intent as machine code. GPLs are one variant of that interface, not the only one. The original IDE insight was correct: collapse the feedback loop, stay in the problem. But IDEs have since accumulated their own surface area — plugin ecosystems, configuration panels, preference trees. An IDE that requires you to understand the IDE is partially defeating its own purpose. An IDE designed for flow disappears. And in the 21st century, where problem spaces span paradigms that no single language covers, the IDE needs to go further: it needs to let you compose multiple notations without leaving the environment or breaking your thought.

Debuggers. Many early languages worked in a REPL-like manner — the language and the debugger were the same thing, expressed in the same notation. You built the system and interrogated it using identical syntax. You never left the language. That unity is what made it a flow tool: there was no context switch between “building” and “inspecting.” That unity was abandoned in favour of the edit-compile-run cycle, and the debugger became a separate instrument with its own interface to learn and operate.

Modern programmers use the word REPL but the point has been largely lost. The original insight was not “evaluate expressions interactively.” It was “never make the programmer change mental gears to examine what they just built.”

A modern version of this concept goes further, because the problem has grown. Traditional REPL-based languages enforced a single notation — which meant the programmer stayed in flow by staying in one syntax, but was also trapped in one paradigm. Every problem had to be expressed through that paradigm’s eye of the needle, whether it fit or not. State-machine control flow expressed in a functional language. Asynchronous concurrency forced into synchronous sequential notation. Each mismatch is a flow tax: you spend time and attention translating what you actually mean into what the language can accept.

A REPL designed for flow in the 21st century would let the programmer stay in the problem across paradigm boundaries — composing multiple notations, each a natural fit for its subdomain, interrogating any of them using the same environment. The goal is the same as the original REPL: no gear change between thinking and building. The difference is that modern problem spaces are too large and too varied to be squeezed into any single paradigm without breakage.

The key structural move here is: first honour what the original REPL got right (same-notation unity = flow), then name what it got wrong (single paradigm = hidden flow tax), then project forward to what the modern version would actually need to be.

Workflows. Slow build pipelines, review processes that fragment deep work into hour-long slots, notification systems that fire on someone else’s schedule — these are organisational flow killers. A workflow designed for flow protects concentration as a resource. Slow builds get fixed. Interrupts get batched. Deep work gets time that is actually unbroken.

The principle is simple. Every mandatory context switch costs concentration. Every tool that demands attention for itself steals attention from the problem. The goal of tool design is to reduce that theft to zero.

We do not build tools so programmers can use tools. We build tools so programmers can think.

Flow is what thinking looks like when nothing is getting in the way.

Further Reading

Alan Kay, “Doing With Images Makes Symbols.” At the 57:42 mark, Kay shows a video of Timothy Gallwey teaching a woman named Molly — who has never played tennis — to play competently in twenty minutes, by keeping her analytical mind out of the way and letting her body learn. The point is about flow in learning, and it applies directly to tool design: a tool that forces the user to think about the tool prevents the user from entering the state where real learning and real work happen. Watch from that moment here.

W. Timothy Gallwey, The Inner Game of Tennis (1974). The book behind the Molly episode. Gallwey’s framework — that performance is blocked by the internal interference of the analytical mind — maps directly onto the programmer’s experience of being pulled out of deep work by tooling concerns. The inner game is the one you play against your own distraction. The outer game is the code.

Jef Raskin, The Humane Interface (2000). Raskin attempts to describe, in explicit engineering terms, the aspects of computer interface design that interrupt concentration — and those that preserve it. Where most interface design literature stays qualitative, Raskin tries to quantify the cost of mode switches, attention captures, and interface elements that demand cognitive engagement at the wrong moment. Directly relevant to anyone designing tools with flow in mind.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Paid subscriptions are a voluntary way to support this work.

Structured Software Architecture

Paul Tarvydas — Thu, 09 Apr 2026 13:46:34 GMT

There are 3 Parts on this diagram. The Container part has kind (type) “P”. It contains 2 child parts, one of kind “A” and another of kind “B”. The Container “P”, also, contains one wire, drawn as an arrow between ports “x” and “y”.

Container Part “P” sees

Part of kind A and its port A.x
Part of kind B and its port B.y
wire [“across”, A.x, B.y]

Container “P” cannot see

A.a, A.b, A.c, A.d, A.e, A.f (any of the entities inside of A)
B.s, B.t, B.u, B.v (any of the entities inside of B)

Part A does not see part B, nor B.y, nor any of the named entities inside of B

Part B does not see Part A, nor A.X, nor any of the named entities inside of A

Parts P, A, B have one (and only one) input queue, each

Parts P, A, B have one (and only one) output queue, each

Sending an Output Message (Mevent)

1. A sends message “Hello” to its own port “x”. (N.B. to its own output port, not to B’s y port).

2. The Mevent send consists of mapping the output mevent of A into an input mevent for B. P performs this mapping then enqueues the new message onto B’s input queue

Discussion

Expressing the following rules in English makes them appear to be more complicated than necessary. The basic idea is essentially “do not colour outside of the lines” - an idea that is taught to children at an early age in pre-school.

Parts are essentially “black boxes”.

Parts are nested and layered and isolated from one another. Parts cannot reach in across the boundaries of other parts and access their internals. Wires (arrows) can only connect ports (note the spelling, port not part) to other ports. Wires cannot cross edges of parts (nor ports).

Wires (arrows) are entirely contained within container parts. Wires are owned by container parts, not children of the containers. A child cannot refer sideways to any other sibling part. A child cannot refer upwards to a parent part.

A child part can be either a Container part or a Leaf part. The parent cannot know how the child is implemented and whether the child is a Container or a Leaf. If a child is implemented as a Container, it can only refer to its own, direct children and its own wires.

This (recursive) nesting hides internal namespaces. A Container part can only see its children’s kinds (types) and the external-facing ports provided by each child [akin to “pins” on hardware ICs]. Since each part, whether Container or Leaf, is otherwise opaque, children’s names do not leak out of Container parts.

Namespacing issues are restricted in scope. Internal names do not leak out to enclosing parts. Each layer sees only a small number of names.

Parts, themselves, do not have explicit names (the “compiler” tracks each part individually using graphical coordinates).

There are no “name clashes” due to part kinds. A container can contain many parts of the same kind (P, A, B in the above example), since the underlying system differentiates parts by position instead of by name or kind.

There are no “name clashes” due to port names, since wires carry output to input mapping information. [Actually, source to sink mapping - I choose to skip over this nuance here].

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Forth Haiku playlist on YouTube

Little Language Case Study - Generating Code for Simple State Machines

Paul Tarvydas — Wed, 08 Apr 2026 12:55:52 GMT

There’s a moment every programmer knows: you’re staring at a blob of nested if statements and callback hell, and you think — I know exactly what this is supposed to do, I just can’t see it anymore.

State machines are one of the classic cures. They’re one of computing’s oldest and cleanest ideas: a system exists in one of a finite number of states, and transitions between them are triggered by events or conditions. Compilers use them. Network protocols are built on them. Game AI runs on them. Traffic lights run on them.

And yet, when we go to implement a state machine in a general-purpose language, something unfortunate happens.

The Diagram vs. The Code

Consider a simple looping state machine — the kind you might use to track a value bouncing between two bounds. Here’s the design, expressed as a diagram:

(three states — idle, wait for w recrossing, wait for zero recrossing — with guarded transitions between them)

The logic is immediately legible:

From idle: if x > w, call reverse() and move to wait for w recrossing. If x < 0, call reverse() and move to wait for zero recrossing.
From wait for w recrossing: if x < w, return to idle.
From wait for zero recrossing: if x > 0, return to idle.

That’s the whole machine. You could explain it to a non-programmer in two minutes.

A practical note: the code annotating each transition (the guards and actions) is written in raw Python. The state machine runtime expects an object — called e — through which the surrounding code exposes variables and functions like x, w, and reverse(). This is a deliberate separation: the diagram owns the control flow, and the host code owns the domain logic.

Now look at the Python that implements it — over 50 lines generated from that exact diagram:

It’s correct. It works. And it’s a completely opaque rendering of something that was obvious in the diagram while the Python code buries the intended control flow under a layer of low-level detail, forcing a functional representation onto something that is fundamentally a control flow structure.

The control flow architecture has been obscured. The states are still there if you squint, but the shape of the machine — the gestalt that makes state machines so powerful for reasoning — has been smeared across a class definition.

The Pattern Hidden in the Boilerplate

The generated code reveals a consistent pattern. Every state is represented by exactly three functions:

enter_ — called once when entering the state
step_ — called repeatedly; evaluates guards and fires transitions
exit_ — called once when leaving the state

A transition from one state to the next follows a fixed multi-step ritual inside the current state’s step function:

Evaluate the guard (e.g. if x > w)
If true: call exit from the current state
Call any transition action (e.g. reverse())
Call enter into the next state

The machine itself is a class with a state variable and a dispatch table that routes step() calls to the right function for the current state.

This is all perfectly mechanical. There’s no creativity in writing it. It’s transcription work — and that’s exactly what code generation is for.

Little Languages, Big Leverage

The diagram isn’t just documentation. It is the program — expressed in what I call a DPL (Diagrammatic Programming Language).

DPLs are “little languages.” They make no pretense of Turing completeness. They don’t try to solve every possible problem. They solve one problem — in this case, expressing state-machine control flow — and they solve it well.

The key insight is that a DPL doesn’t replace your general-purpose language. It generates snippets for it. The Python code above is intended to be embedded inside a larger project, like a component you’d pull off a shelf. The diagram specifies the control flow skeleton; the surrounding Python code supplies the domain logic (reverse(), the bounds checking, whatever the machine needs to operate).

This is a genuinely useful division of labour:

The diagram expresses what states exist and when to transition between them.
The surrounding code expresses what to do on entry, exit, and transition.

Neither half needs to know too much about the other.

Treating Python Like Assembly

Here’s the provocative framing: once you have a code generator, your general-purpose programming language becomes an assembly language for your project.

This isn’t an insult to Python. Assembly languages are precise, powerful, and absolutely essential. But nobody argues that you should write your entire project in assembly — you want to work at a higher level of abstraction, and compile down to assembly for execution.

The same logic applies here. When your project has components that are naturally expressed as state machines (and many do), you should be able to draw those components and compile down to Python — not transcribe them by hand.

The code generator at github.com/guitarvydas/sm does exactly this. Drop a .drawio diagram of your state machine into the repo and run @make. Out comes the boilerplate Python. You supply the guards and actions; the tool supplies the structure.

[See README.md for the exact recipe.]

The Workbench We Should Want

There’s a bigger argument lurking here.

We’ve spent decades building programming languages that try to do everything — general-purpose, Turing-complete, expressive, fast, safe, concurrent. And those languages are remarkable achievements.

But the ambition to make one language handle every problem has a shadow side: it makes us reach for that one language even when a smaller, more targeted tool would serve us better. We hand-write state machine boilerplate when we could draw diagrams. We build elaborate data transformation pipelines in imperative code when a declarative notation would be cleaner. We implement parsers by hand when a grammar DSL would be more readable and more maintainable.

The alternative is a programming workbench: a composition of tools, each doing one thing well, connected by code generation and interoperability. You draw where drawing is clearest. You write where writing is clearest. The workbench stitches it together.

That’s not a new idea — it’s the Unix philosophy applied to the act of programming itself. Small tools. Sharp edges. Composable outputs.

The state machine generator is a small demonstration of what that workbench could feel like. The diagram is unambiguous. The generated code is mechanical. The human writes only the interesting parts.

Try It

The tool is at github.com/guitarvydas/sm. It’s lightly tested — consider this early-stage and experimental — but the concept is solid and the generated code for a diagram like the one above works as expected.

If you’re reaching for nested conditionals to track some mode in your program, draw the states first. You might find the diagram says everything you need — and that the code writes itself.

What would your programming workflow look like if you could compose it from little languages, each suited to its part of the problem? I’d love to hear what you’d reach for first.

Further: Ideas and Observations

Ideas and observations about other little languages might be of interest:

What I’ve Learned from Forth Haiku Thus Far and other related Forth Haiku articles on my substack.

Sector Lisp

SCN playlist

Decision Tree DPL playlist

Ohm-JS playlist

Experiments with Text to Text Transpilation - along with articles on my substack containing the keyword ‘T2T’

PBP Part Basics - along with articles containing the keywords ‘PBP’, ‘Parts Based Programming’, ‘0D’

PBP Cookbook playlist

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

[https://github.com/guitarvydas/frish/tree/main]
[https://github.com/guitarvydas/frish/tree/debugdefsynonym]

The Case for Composable Notations (6 of 5) - WIP - Notations in Progress

Paul Tarvydas — Tue, 31 Mar 2026 02:25:16 GMT

The series ends here. The work doesn’t.

What follows is a brief appendix describing notation experiments currently in progress. Collaborators and kibitzers are welcome. More discussion of these ideas happens on the Programming Simplicity Discord server. The repos contain WIP code “as is”.

dtree

dtree is a DaS notation — Diagrams as Syntax. It uses three primitives: rhombus (decision), yes/no arrows, and process boxes. Turing completeness is not a goal. The notation is useful precisely because it is narrow — easy to imagine, easy to build, easy to read. The simplicity is the feature.

Repo: [https://github.com/guitarvydas/dtree]

sm is also DaS. It expresses state machines directly as diagrams. A state in sm is not a case statement or a single closure — each state requires three functions, which makes it cumbersome to express in FP notation and therefore routinely side-stepped. sm makes it natural.

Repo: [https://github.com/guitarvydas/sm]

Frish

Frish — FoRth-ISH — is TaS (Text as Syntax). The Frish language is text-based; its compiler is DaS. Forth’s core idea — extremely small, composable operations — without Forth’s historical baggage.

Repos:

0d.rt

0d.rt is TaS. It implements UNIX-like processes in Python using message passing via Python’s dequeue class. It currently emits Common Lisp and JavaScript in addition to Python — other targets are possible but I ran out of road.

A few design decisions worth noting:

The original implementation used various complicated data structures. It was eventually upgraded to use only strings, parsed on demand using OhmJS/PEG. This seems wildly inefficient by 20th-century standards. It probably isn’t — most programming languages are, at their core, parsers for data expressed as text, preened ahead of time. JIT compilation is likely the right model here, not pre-declared structure.

The deeper principle: systems must not be built around fixed, centralised data structure definitions — no central authority should dictate communication protocols. Parts must be free to negotiate, on the fly, what they can and cannot accept. Strings, with known formats, make this tractable. Complex shared .h-style headers make it brittle.

Repo: [https://github.com/guitarvydas/pbp-dev/blob/main/kernel/0d.rt]

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

The Case for Composable Notations (5 of 5) UNIX Already Showed Us the Way

Paul Tarvydas — Tue, 31 Mar 2026 02:21:39 GMT

TL;DR

UNIX demonstrated that programs composed from small, single-purpose tools connected by pipelines are more flexible than monolithic programs that try to do everything. The same principle applies to programming notations. We don’t need to start over. We need to start composing.

L;R

The previous articles in this series have been largely critical. FP imposes restrictions. State has been hidden rather than expressed. Ease of expression has been sacrificed for notational monoculture. The natural question is: what do we do instead?

The answer is not to push the big red button and start over. The answer is already partially in front of us. UNIX demonstrated it fifty years ago. We just haven’t finished reading the lesson.

What UNIX actually showed us.

The UNIX philosophy was built around a small number of powerful ideas. Programs should do one thing well. Programs should produce output that can become the input of another program. Programs should be composable.

The mechanism was text. UNIX chose plain text as the universal interface between programs. Not because text is the best possible representation for every kind of data — it isn’t — but because text is the one representation that every tool can read and write without negotiation. Text is the lowest common denominator that makes composition possible.

The result was pipelines. A sequence of small programs, each transforming text in one specific way, connected so that the output of one becomes the input of the next. No single program in the pipeline needs to know what the others do. Each program sees text in, produces text out, and minds its own business.

This is not just a technique for manipulating documents. It is a model for composing notations.

Source code is text.

Source code is text. This is obvious but underexploited. If source code is text, then the UNIX pipeline model applies directly: a program that reads source code in one notation and produces source code in another notation is a text-to-text transmogrifier — a t2t tool. Chain enough of them together and you have a pipeline that accepts source in one notation and delivers executable behaviour, passing through whatever intermediate notations are useful along the way.

This is not a new idea. It is how most compilers work internally — a sequence of transformations from source text through intermediate representations to machine code. The insight is to make the intermediate stages explicit, accessible, and composable at the level of the programming workflow rather than buried inside a single tool.

When you do that, each stage in the pipeline can use a different notation. A diagram tool produces a structured description of component topology. A t2t transmogrifier converts that description into a skeleton in a general-purpose language. Another transmogrifier fills in behaviour from a domain-specific notation. Another checks the result against constraints expressed in a relational notation. The final stage produces code in whatever target language the runtime expects.

No single notation does everything. Each notation does one thing, in its sweet spot, and hands off to the next.

Little languages over GPLs.

General-purpose programming languages are an answer to the question: what if we had to pick one notation for everything? The answer is inevitably a compromise. A GPL must be expressive enough to handle every problem domain, which means it cannot be optimally expressive for any particular one.

Little languages — small, purpose-built notations for specific problem domains — make the opposite trade. A little language for describing component connections does not need to handle string manipulation or arithmetic. A little language for expressing state transitions does not need to handle network I/O. Each little language is narrow, and narrow is what makes it clear.

BNF is a little language for describing grammars. It has been enormously productive precisely because it is narrow — it does one thing and does it with a clarity that no GPL-based alternative matches. The programmer says what the grammar is, not how to parse it. The notation carries the intent directly.

The objection is usually: little languages are expensive to build. This was true when language tools were scarce and difficult to use. It is much less true now. Parser generators, PEG libraries, macro systems, and pattern-matching tools have made the construction of small, purpose-built notations a realistic part of a programming workflow rather than a research project. The cost argument has not kept pace with the tooling.

Existing languages as assembly languages.

We do not need to abandon the languages we have. We need to change their role.

A general-purpose language — Python, JavaScript, Rust, whatever the current choice is — can serve as an assembly language for a higher-level notation. The higher-level notation expresses the problem in its natural terms. The t2t transmogrifier converts that expression into the GPL. The GPL handles the runtime details. The programmer works at the higher level and does not need to think about the GPL except when debugging the transmogrifier.

This is not theoretical. It is how most templating systems work. It is how CSS preprocessors work. It is how build systems with declarative configuration work. The pattern is familiar. The step that remains is to generalise it — to treat the composition of notations as a first-class part of programming practice rather than a specialised technique used in specific tool-building contexts.

Composing paradigms.

The functional paradigm has a sweet spot. The relational paradigm has a sweet spot. State machine notations have a sweet spot. Diagrammatic notations have a sweet spot. None of these sweet spots covers the full range of problems that real software systems contain.

A system composed from multiple notations, each handling the part of the problem it fits best, connected by t2t transmogrifiers into a coherent pipeline, is not more complex than a system forced into a single notation. It is less complex — because the notation at each stage is close to the problem at that stage, and proximity between notation and problem is where complexity goes to die.

The composition layer — the pipeline — does not need to be sophisticated. UNIX demonstrated that plain text and simple conventions are sufficient. The sophistication lives in the individual tools, where it belongs, not in the connection mechanism.

PBP as a current experiment.

Parts Based Programming — PBP — is an ongoing experiment in this direction. The core idea is that software components should be isolated, asynchronous by default, and connected by explicit routing rather than direct function calls — modelled on how hardware components behave rather than how mathematical functions compose.

The toolchain is a pipeline of t2t transmogrifiers. Diagrams produced in draw.io describe component topology. A transmogrifier converts those diagrams to a structured representation. Further transmogrifiers convert that representation into runnable code. Each stage uses the notation appropriate to its task.

The experiment is not finished. It is not a product. It is a demonstration that the pipeline model works for composing notations in a software development workflow, using tools that exist today, without requiring a new runtime or a new theory of computation.

The path forward does not require abandoning what we have. It requires treating what we have as a set of components — each with its own sweet spot, each expressible in a notation suited to it — and learning to compose those components as deliberately as UNIX learned to compose programs.

The pipes are already there. We just need to start using them.

End of series.

This is article 5 of 5 in “The Case for Composable Notations.” A Part 6 of 5 follows — an appendix describing notation experiments currently in progress, with pointers to repos and an open invitation to collaborate.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

The Case for Composable Notations (4 of 5) Ease of Expression Is the Whole Point

Paul Tarvydas — Tue, 31 Mar 2026 02:18:54 GMT

TL;DR

“You can express it in FP” is not good enough. If expressibility were sufficient, we’d still be programming in transistors. Notation shapes what gets built, what gets attempted, and what gets imagined.

L;R

There is a standard defence of any dominant notation when its limitations are raised: yes, but you can express that in it. You can express concurrency in a functional language. You can express state machines in a functional language. You can express asynchronous behaviour in a functional language. It takes more work, but it can be done.

This defence misses the point entirely.

The transistor argument.

We do not program in transistors. We could — every computation that runs on modern hardware is, at the lowest level, a pattern of transistors switching states. The transistor is expressive enough, in principle, to encode any program we have ever written or will ever write.

We do not program in transistors because the distance between transistors and human problems is too large. The notation does not fit the problem. Bridging that distance costs more than it is worth when better notations exist.

We do not describe programs in terms of molecules either, or atoms, or semiconductor physics. Each of those notations is, in principle, expressive enough. None of them are useful for programming, because usefulness is not about expressive sufficiency. It is about ease of expression.

This is why programming languages were invented. Not because transistors couldn’t express the computation, but because transistors made the computation too hard to express, reason about, modify, and communicate to other programmers. The notation mattered.

The same argument applies above the level of transistors. If a notation makes a class of problems hard to express, that is not a minor inconvenience to be overcome by sufficiently skilled programmers. It is a signal that the notation does not fit the problem domain.

What hard expression costs.

When a notation fights the problem, the cost is not just programmer time — though that cost is real and large. The cost is also in what does not get built.

A notation that makes concurrent systems hard to express produces fewer well-designed concurrent systems. Not because programmers are incapable, but because the overhead of expressing concurrency clearly in an ill-fitting notation consumes the budget that would have gone into design. The workaround ships. The design doesn’t.

A notation that makes state transitions hard to express produces programs where state transitions are implicit, scattered, and invisible. Not because programmers don’t understand state machines, but because the notation gives them no clean place to put one. The switch statement inside the loop ships instead.

A notation that makes multiple output channels awkward produces programs that smuggle outputs through exceptions and side channels. Not because programmers don’t know better, but because the notation makes “better” expensive.

The notation shapes the solution space. Not by preventing solutions, but by making some solutions cheap and others costly. Programmers, like water, take the path of least resistance. The notation defines which path that is.

Decades of baubles.

We have spent decades adding to the functional notation rather than supplementing it with alternatives. Monads for managing effects. Continuations for managing control flow. Async/await for managing the synchrony mismatch. Effect systems for managing side effects. Evaluation order rules for managing the cases where order matters.

Each addition makes the notation more capable of expressing something it was not originally designed to express. Each addition also makes the notation more complex, more demanding to learn, and further from the original idea that gave it its elegance.

The result is that the sweet spot of FP — the class of problems it expresses cleanly and cheaply — has not grown. The notation has grown around it. New programmers must now learn not just functional thinking but the accumulated stack of workarounds that make functional thinking usable outside its sweet spot. The beginner’s path into the notation runs directly through the complexity that the workarounds created.

This is not progress. This is a notation being stretched past its natural boundary because the alternative — acknowledging that different problems need different notations — has been treated as defeat.

Ease of expression is an engineering requirement.

In engineering, the right tool for the job is not a style preference. Using the wrong tool produces weaker results, at greater cost, with more risk of failure. A notation is a tool. A notation that does not fit the problem is the wrong tool.

The solution is not to make the wrong tool more elaborate. The solution is to have more tools and to know when to switch.

This is not a radical idea. Hardware designers use it routinely. A circuit schematic, a timing diagram, a state machine diagram, a truth table — these are different notations for different aspects of the same system. No hardware designer would insist on expressing everything in a single notation. The problem domain is too varied. Different aspects of the system have different natural notations.

Software has largely insisted on the opposite. One language, or a small family of languages sharing the same fundamental assumptions, for every problem. The notation is the craft. Questioning the notation is questioning the identity of the field.

That needs to change.

What ease of expression actually requires.

It requires that when we find a useful notation — function-based thinking, relational thinking, state-machine thinking, diagram-based thinking — we stop trying to make that notation do everything. We stop enbaubling it. We ask instead: what is this notation’s sweet spot, and how do we connect it to other notations for the parts of the problem it doesn’t fit?

The question is not “can this notation express the problem?” The question is “does this notation make the problem easy to express, easy to reason about, easy to modify, and easy to communicate?”

If the answer is no, the notation is the wrong tool. We are allowed to use a different one.

Next: UNIX Already Showed Us the Way.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

The Case for Composable Notations (3 of 5) State Isn’t The Enemy

Paul Tarvydas — Tue, 31 Mar 2026 02:13:27 GMT

TL;DR

FP didn’t eliminate state. It hid it. The field spent decades learning to avoid expressing state rather than learning to express it well. Those are opposite skills.

L;R

Programming courses teach state avoidance as a virtue. The word “state” has acquired a faint smell — something to be minimized, hidden, apologized for. Stateless is clean. Stateful is dangerous. Pure functions are safe. Mutation is where bugs live.

This is a notation bias dressed up as wisdom.

What state actually is.

State is the current condition of a system at a point in time. Every useful program has it. A program that accepts input, produces output, and changes nothing in between is not a program — it is a mathematical function. Useful for certain problems. Not a general model of computation.

CPUs mutate registers. Memory is written and rewritten. Device drivers track hardware conditions. User interfaces respond to sequences of events. Network protocols maintain connection state across time. Embedded controllers react to signals from the physical world. Every one of these domains is stateful by nature. The state does not go away because the notation ignores it.

Where FP put the state.

FP pushed state into the operating system. The call stack is state. The heap is state. The scheduler’s bookkeeping — which process is running, which is waiting, what it was doing when it was interrupted — is state. This is not a small amount of state. It is the complete runtime state of every active process, maintained by the OS on the programmer’s behalf.

The programmer did not make it disappear. The programmer handed it to the OS and agreed not to look at it directly. The OS shapes that state according to its own model — threads, processes, protected memory regions — and the programmer inherits that shape whether or not it fits the problem.

When it fits, the arrangement is invisible and cheap. When it doesn’t fit — when the problem has a state structure the OS model doesn’t express cleanly — the programmer pays. The payment is indirection, workarounds, and a persistent translation layer between the problem’s natural structure and the structure the runtime imposes.

The vocabulary we didn’t develop.

State machines are one way to name state explicitly: here are the states a system can be in, here are the conditions that cause transitions between them. The notation is direct. The structure is visible. The programmer controls it.

Harel’s Statecharts extended state machines to handle hierarchy and concurrency — evidence that the notation can be developed further. They are not the final word. They are one existence proof that expressing state clearly is possible and has been explored.

There may be better approaches. We don’t know, because the field largely stopped looking. Instead of developing richer notations for state expression, the field developed richer techniques for state avoidance. These are opposite research programmes. One asks: how do we express state clearly? The other asks: how do we avoid having to?

The avoidance programme won. State machines are taught, if at all, as a niche technique for embedded systems or compiler design — not as a general tool for expressing the stateful behaviour that most programs actually contain. Most programmers implement what are effectively state machines as switch statements inside loops, without the notation to see that is what they are doing.

The cost of the avoidance programme.

When state is hidden, debugging means reconstructing it. When state lives in the OS, you observe it indirectly — through stack traces, memory dumps, log files, debugger watches. The tools for reconstructing hidden state are sophisticated because the need for them is constant.

When state is expressed directly, you can see it. You can name the states your system can be in. You can describe the transitions explicitly. You can ask, at any point: what state is this system in, and why? The question is answerable without reconstruction.

Hidden state is not safe state. It is state that is harder to reason about, harder to test, and harder to modify. The sense of safety that FP’s state restrictions provide is real but narrow. It applies to the class of problems where the OS’s model of state happens to fit. For everything else, the safety is an illusion maintained at the cost of visibility.

What ease of expression requires here.

The transistor argument applies directly. We do not describe programs in terms of transistors because the notation is too far from the problem. We do not describe concurrent, reactive, long-lived systems in terms of pure functions for the same reason — the notation is too far from the problem. The distance between notation and problem is not a style preference. It is where bugs live, where complexity accumulates, and where programmer hours disappear.

Expressing state well means having notations in which states are named, transitions are explicit, and the current condition of the system is visible. We have glimpses of what that looks like. We have not pursued it seriously, because the dominant notation taught us that state was the enemy.

It isn’t. Invisible state is.

Next: Ease of Expression Is the Whole Point.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

The Case for Composable Notations (2 of 5) The Restrictions That Came With the Cow

Paul Tarvydas — Tue, 31 Mar 2026 02:09:00 GMT

TL;DR

Functional programming imposes a specific set of restrictions. Each one is a notation choice. None of them are laws of nature.

L;R

Every notation has a sweet spot — a class of problems it expresses clearly and cheaply. Outside that sweet spot, the notation fights you. The restrictions are not bugs; they are the shape of the cow. Understanding them precisely is the first step toward knowing when to put the cow down.

Here is what FP imposes.

Single-thread thinking.

FP is fundamentally sequential. What we call “multi-tasking” today is time-sharing — a technique invented to fake concurrency by splitting a single thread into separate state machines, saving their state in hidden data structures, and switching between them at boundaries the software architect does not control. The operating system manages the illusion. The programmer works inside it. Real concurrency — multiple things happening independently, with no shared thread — is not expressible in the functional notation without leaving it.

One in, one out.

A function takes arguments and returns a value. One bundle in, one bundle out. stderr is a workaround for the cases where you need a second output channel. Exceptions are a workaround for the cases where returning a value is the wrong response to a situation. Both are bolt-on mechanisms grafted onto a notation that does not natively support multiple outputs. The workarounds work — but they are workarounds, and their seams show.

Elision of mutation.

FP treats assignment as suspect. Mutation is discouraged, hidden behind monads or immutable data structures, or banned outright. This is useful for a certain class of problems. It is not a description of how computers actually work. CPUs mutate state. Memory is mutable. Pretending otherwise requires the runtime to maintain an increasingly elaborate fiction — and pushes the mutation somewhere the programmer cannot see or control it.

Fixed control flow.

FP offers one control flow structure: top to bottom, left to right, as inherited from the printing press. Conditionals and recursion are permitted variations within that structure. Anything else — event-driven flow, concurrent flow, flow driven by external signals — requires leaving the notation or bolting something onto it. The notation does not make other control flows easy to express. It makes them feel unnatural, because the notation itself has no vocabulary for them.

Routing.

In a functional program, routing is sequential by default. Data moves from caller to callee and back. Expressing any other routing topology — broadcast, fan-out, selective dispatch, feedback — requires constructing it manually from the available primitives. The notation does not help. Every non-sequential routing pattern is an exercise in working around a notation that was not designed to express it.

Synchrony.

Every function call is synchronous. The caller suspends. The callee runs. The caller resumes when the callee returns. This is a specific, narrow model of coordination — useful for calculator-like computation, costly for anything else. Event-driven systems, device drivers, network protocols, user interfaces, robotics — these domains are asynchronous by nature. Forcing them into a synchronous notation produces the bolt-ons: callbacks, promises, async/await, reactive frameworks. The notation keeps winning. The domain keeps losing.

Evaluation order as a hidden assumption.

FP inherits a specific evaluation model and mostly keeps it invisible. Some languages make it explicit — Clojure, for instance, specifies evaluation behaviour in certain contexts — but the mechanism for doing so is itself a notation-level workaround rather than a first-class tool. When you need to control the order in which things are evaluated, you should be able to say so clearly. Instead, you learn which incantations coerce the runtime into the order you need.

What this adds up to.

Each of these restrictions was a reasonable choice in 1960. CPUs were expensive, memory was scarce, and mathematical function application was a clean, verifiable model for a narrow class of computation. The restrictions made the cow spherical on purpose.

The problem is not the restrictions. The problem is that we have spent decades adding baubles — monads, continuations, effect systems, async layers, evaluation order rules — to stretch the notation past its sweet spot, rather than acknowledging that different problems need different notations.

We don’t still describe computers in terms of transistors. We invented higher-level notations because ease of expression matters. The same logic applies here.

Next: State Isn’t the Enemy.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Working on Rewriting the Preoptimizer Preopt.ohm

Paul Tarvydas — Mon, 30 Mar 2026 01:09:04 GMT

I don’t want to deal with Substack’s inferior formatting capabilities for program code, so I’ve converted this article into PDF form and am providing it as a downloadable file.

TL;DR

This article is about my ongoing work on the Frish project - namely fixing the pre-optimizer stage. At this point, I need to throw the existing code away and start again. This article contains a justification for discarding the code, and, how I make it “easy” for me to use this option. The point of designing a program is to discover the details of the problem space in an iterative manner, not to create production-ready code (yet). I discuss my thought process and the tools that I use to help me iterate and toss code away. I only discard code, but retain what I’ve learned. The goal is to use tools that make it easy for me to spend more time thinking and learning rather than polishing code - all the time knowing that I can throw all of the code away, since it hasn’t cost me much effort to create. This approach is different than that of using a strongly typed programming language. First, I want to figure out what I want the code to do, then I can re-cast it into stone using tools and compilers meant for Production Engineering.

L;R

…

What I’ve learned, thus far

…

Refreshed Approach

…

Repository

The WIP code is on github https://github.com/guitarvydas/frish/tree/debugdefsynonym.

An accompanying twitch-like (long) video.

I will write new code. I find it difficult to write prose about what I’m thinking or to talk into a camera while I think. If you want to follow along, see the code in the repository and/or visit the “programming simplicity” discord and poke questions at me.

PDF

Working On Rewriting The Preoptimizer Preopt

180KB ∙ PDF file

Download

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

The Wrong Spherical Cow - First Principles of Parts Based Programming

Paul Tarvydas — Sun, 29 Mar 2026 02:10:06 GMT

TL;DR — Function-based programming borrowed the wrong metaphor from mathematics. Erlang and Go improve on it but don’t finish the job. A simple change of point-of-view — not a rewrite — gets you the rest of the way.

L;R

The Metaphor We Didn’t Notice We Chose

Mathematical functions describe timeless relationships. When you write f(x) = x² there is no time in that statement. No waiting. No concurrency. The function returns instantly, always, to exactly one caller.

This is fine for mathematics. Relations between numbers don’t happen in time.

When we built computers we modeled computation on mathematical functions — and silently imported the metaphysics along with the notation. CALL/RETURN encodes assumptions that feel like logic but are actually choices:

A function always returns
It returns to its caller
It returns synchronously
Only one thing runs at a time

These aren’t laws of nature. They’re a notation’s hidden opinions about time.

The Damage

CALL/RETURN couples caller and callee through a shared data structure — the stack. The caller is suspended while the callee runs. They share execution time, not just data. What looks like encapsulation is actually intimate coupling wearing a clean interface.

This is fine for computing things. It is the wrong foundation for systems — collections of independent components that react to events, run concurrently, and communicate across boundaries.

The real world doesn’t use CALL/RETURN. Your heart doesn’t wait for your lungs to finish. A web server shouldn’t pause all users while one request completes. Hardware interrupts don’t politely wait for your loop to yield.

Asynchrony isn’t a special case. It’s the default state of the universe. Synchrony is something you impose when you need it.

Erlang and Go Got Closer

Both recognised the problem. Both moved toward lightweight async components — goroutines in Go, processes in Erlang — without the heavy cost of OS-level threads and MMUs. Real progress.

But neither finished the job.

Go still allows shared memory. The async boundary is optional, not architectural. You can — and most codebases do — reach back across it.

Erlang is cleaner. Lightweight processes, message passing, no shared memory. Genuinely async by default. But an Erlang process knows its neighbours. The routing — who sends to whom — lives inside the process code as explicit PIDs and sends. The component and the wiring are fused together.

To understand an Erlang system’s architecture you have to read all the code and reconstruct the topology in your head. There is no schematic. The design is implicit.

The EE’s Secret

Electrical engineers build complex asynchronous systems reliably. They don’t solve Maxwell’s equations by hand for every circuit. They use a notation — the schematic — that makes asynchrony invisible as a problem because it’s already the default.

In a schematic every component reacts. Nothing waits for permission. Voltage appears, current flows, simultaneously, everywhere. There is no caller. The notation makes concurrency the background, not the foreground.

The key property: components are topology-blind. A resistor doesn’t know what it’s connected to. You can drop it into any circuit without modifying it. The schematic — not the component — encodes the design.

This is the piece Erlang and Go are missing.

PBP: Change the Point of View

Parts Based Programming (PBP) adds one principle to what Erlang got right:

Components don’t know their neighbours. Only the parent container knows the wiring.

Each component has named input ports and named output ports. It receives messages, does work, sends to named outputs. Who wired those outputs — and where the messages actually go — is not its concern.

This makes the schematic a first-class artifact. The architecture is explicit, separate from the implementation, readable and modifiable without touching any component.

It also means existing synchronous code doesn’t need to be rewritten. A synchronous function becomes a leaf component. The async composition layer wraps it. The resistor doesn’t change — the circuit diagram changes.

You don’t need a new language. You don’t need new hardware. You need a different place to stand.

The function-based approach isn’t wrong because it’s synchronous. It’s wrong because it made synchrony invisible as an assumption — and then made asynchrony invisible as a possibility.

PBP makes the wiring visible. That turns out to be enough.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

The Case for Composable Notations (1 of 5) The Spherical Cow We Forgot We Were Riding

Paul Tarvydas — Sun, 29 Mar 2026 01:34:22 GMT

TL;DR

McCarthy invented functional programming as a notation convenience — a spherical cow. The programming community forgot it was a cow. Decades of workarounds followed.

L;R

Physics has a tradition of inventing simplified notations to make hard problems tractable. A spherical cow is a deliberate lie — a simplification that strips away inconvenient reality so you can think clearly. The rule is: remember it’s a lie.

McCarthy invented Lisp 1.5 under the same spirit. CPUs and memory were expensive. A notation that treated computation as pure mathematical function application — no side effects, no time, no messiness — was a useful fiction. It let you reason cleanly about certain classes of problems.

The rule applies: remember it’s a fiction.

The programming community forgot.

C smudged the boundary.

Before C, the distinction was explicit: subroutines and functions were different things. A subroutine can have side effects. A function — by definition — cannot. A function with zero arguments that returns a value must return the same value every time, or it isn’t a function; it’s a subroutine wearing a function’s clothing.

After C, everything became a “function.” The word lost its meaning. Today most programmers treat a zero-argument procedure with side effects as a function. It isn’t. The confusion isn’t cosmetic — it shapes how an entire generation thinks about what programs are.

What got lost.

McCarthy’s original eval/apply engine was small and tight. That engine made sense for its era and its cost constraints. CPUs were expensive. Memory was expensive. The fiction paid for itself.

CPUs and memory are now effectively free. The original justification evaporated. What remained was the notation, now mistaken for ground truth.

The cost of maintaining the fiction has compounded. To allow “functions” to interact with the real world — which is irreducibly stateful and asynchronous — the community has had to invent a growing stack of workarounds: monads, continuations, effect systems, callback protocols, async/await layers, and more. Each workaround is a patch over the mismatch between the spherical cow and reality. Each patch makes the next patch harder to avoid.

The deeper confusion: data flow vs. control flow.

Functional programming is often described as “data flow.” It isn’t.

When a caller passes data to a callee in a functional call, two things happen simultaneously: data moves, and control transfers. The caller suspends. It waits. The callee must process the data immediately and return before the caller can proceed. That is synchronous control flow with data attached — not data flow.

Real data flow is asynchronous. You send data to a receiver. The receiver processes it in its own time. The sender does not wait. The sender does not care when processing happens. The sender does not even need to know that processing happened.

Functional programming cannot express this without leaving the paradigm. The workarounds (callbacks, futures, reactive streams) are all ways of bolting asynchrony onto a fundamentally synchronous notation. The bolt-on is visible everywhere — callback hell being only the most obvious symptom.

The notation is not the only notation.

BNF exists. It describes what to parse without specifying how to parse it. Most programmers, though, would rather write low-level parsing code in a functional style than reach for BNF, even when BNF is clearer, shorter, and more correct. The functional notation has become so dominant that alternatives feel exotic.

Prolog exists. Its relational engine is genuinely different — it lets you query a factbase in a notation suited to relational problems. Most programmers never reach for it, even when the problem is relational. Instead, they twist a functional language to approximate what Prolog does natively, at greater length and with more bugs.

Harel’s Statecharts exist. They describe stateful, reactive, hierarchical behaviour in a notation built for that purpose. Most programmers implement state machines as switch statements in a functional language instead.

The alternatives did not lose on merit. They lost because the functional notation achieved cultural dominance and crowded out the vocabulary needed to even ask whether a different notation might fit better.

The actual problem.

Most programmers now believe that programming is writing machine code for a CPU. Not designing systems. Not composing components. Not choosing a notation suited to a problem domain. Writing CPU instructions — with a functional veneer on top.

This is the wrong spherical cow. It was never meant to be the whole of programming. It was a notation for a particular class of problems, invented under particular cost constraints, in a particular era.

The constraints are gone. The notation stayed. The forgetting was the mistake.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Multiple Notations In A Single Project

Paul Tarvydas — Sat, 28 Mar 2026 15:46:24 GMT

I favour using many - terse - notations within a single project. One notation for each kind of issue within the project.

It’s about focusing in on a specific issue. Terseness allows you to focus better. Terseness allows you to write down what you think and to try it out. If you don’t like it or learn something new, terseness makes it thinkable to just erase what you wrote and to write something new. Too much detail, too early, discourages retrying, since you’ve already invested too much effort in the code. Making the notation terse rebalances the equation - you can spend more time thinking (and trying out) instead of spending time worrying about dotting all the i’s and crossing the t’s.

If you think that you don’t need to retry, you are engaging in Waterfall development.

A terse notation is more expressive,,, but only for that specific issue. You need a different notation when you switch to thinking about some other issue.

Example

I wanted to think about how to compile diagrams to code.

I could suck in diagrams in .graphML form or .svg form - so that wasn’t much of an issue.

At one point, though, I needed to fill in “semantic” information that was in the diagram but scattered about and not conveniently arranged how I would like. That is an “inferencing” problem.

Prolog notation is much, much better for dealing with inferencing than anything else I’ve found, e.g. loops within loops, recursive functions, etc. So, I expressed the pattern matching relationships in a way that made sense to me. I let a Prolog engine chew through the relationships and produce the semantic info in a way that I wanted.

For example, ‘this pill-shaped figure is a “port” that belongs to that rectangular figure (a “part”). And, this port is an output port because the tail end of an arrow is attached to it. Repeat for every pill-shaped figure and create facts that relate each port to each part and facts that say in a convenient way which direction each port is (in, out).

Later, though, I just wanted to write this stuff out into a text file (fyi: I’m using JSON, because it’s easy and ubiquitous) and fool around more with the text. Prolog makes it difficult to deal with strings. JavaScript (!) is easier for this kind of thing.

For me, Prolog was the syntax of choice for the inferencing stuff, but JS (Python, etc. - (fyi: in fact, I’m using OhmJS and my T2T tools)) was the syntax of choice for the rest of the text-manipulation stuff. If I had to choose only one language for this, I would have had to struggle with either Prolog or with JS. I wanted to use both (this is but a simple example, I actually use lots of languages).

In my view, a GPL - General Purpose Language - like Rust, Python, Haskell, C++ can’t express everything I need to think about without causing me extra work. You can see GPL design heading towards either milquetoast unions of a variety of features, or, too much emphasis on only one kind of feature (e.g. type checking, user-defined structs, etc.).

GPLs are good for optimizing and for creating production-ready code, but not so good for thinking about problems and their solutions. The way I see it, creating a program consists of (at least) two major activities:

Thinking about the problem and verifying that my intended solution works well enough (Design Engineering)
Creating a production-ready version of the final, chosen design. Using automated tools to help me find loopholes (Production Engineering)

(I’m consciously skipping over other issues, like release, maintenance, security, etc.).

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Drafting Rules for Node-and-Wire Diagrams

Paul Tarvydas — Thu, 26 Mar 2026 15:44:30 GMT

TL;DR

Several rules for readable node-and-wire DPL diagrams. The underlying constraint: diagrams earn their place only where text fails.

L;R

DPL

DPL stands for Diagrammatic Programming Language.

Use diagrams where text fails, and vice versa

Diagrams and text are complementary, not competing. Use diagrams for topology — what connects to what. Use text for logic and annotation. Neither is universal; both are necessary.

It is worth noting that SVG, for instance, treats rectangular figures and figures containing text as peers at the same structural level — the underlying representation does not privilege one over the other, which is exactly the right default.

No diagram should look complicated at first glance

Complexity hides in layers. Each layer must be independently legible without forcing the reader to confront detail they haven’t asked for — while still providing that detail elsewhere, so that the complete system loses nothing overall. The reader pulls detail on demand; the diagram does not push it. This requires async, message-passing architecture: synchronous/sequential languages cannot produce genuinely independent layers without incurring extra work. Implicit layering in a synchronous system is a polite fiction.

Components may have multiple input ports and multiple output ports

A node is not limited to one wire in and one wire out. Ports are named and positioned on the edges of a box. Multiple inputs arrive independently; multiple outputs depart independently.

Fan-out

Fan-out — one output port wired to multiple downstream components — is natural in a node-and-wire diagram. The functional programming paradigm discourages it, because in software, fan-out requires copying values and subsequent garbage collection. In a message-passing system, the cost is explicit and the copies are intentional.

Fan-in

Fan-in — multiple upstream components wired to one input port — looks the same in both paradigms but behaves very differently. In a message-passing system, each arriving message drops into the receiver’s input queue in order of arrival; the receiver processes them in turn, and senders do not wait. In a function-call system, multiple callers sharing a single callee only look like fan-in: it is actually serialized, synchronous access — each caller blocks until the callee finishes before the next caller can proceed.

Feedback is a first-class citizen

A wire that loops back — from a downstream component to an upstream one — is not a special case. It is a normal connection, drawn with the same right-angle routing as any other wire. Feedback is how systems remember, regulate, and adapt.

Feedback is not the same as recursion, and the difference matters. Imagine a line of people waiting at a ticket window. Feedback sends a person to the back of the line — they wait their turn. Recursion sends a person to the front, cutting in ahead of everyone else. In software terms: feedback drops a message into a queue and returns immediately; recursion suspends the current call and demands an answer before continuing. One is async and non-blocking; the other is sync and stack-consuming.

Let the compiler determine meaning from context — minimize symbol decoration

The IEC eventually replaced the zigzag resistor symbol with a plain rectangle. The zigzag was a pictogram of the physical component’s wound-wire construction — a piece of historical baggage baked into the notation. A labeled rectangle is cleaner, and the label carries all the semantic weight needed.

The same principle applies to software diagrams. In most popular programming languages, an identifier carries no visible decoration indicating whether it names a variable, a parameter, a function, a type, or something else — the compiler resolves that from context. A node-and-wire diagram can work the same way: use the smallest possible set of shapes, and let position, port names, and wiring topology convey meaning. Every additional symbol variant — every special shape that encodes a semantic distinction — is a vocabulary item the reader must memorize. Prefer one symbol with annotations over two symbols with implicit meanings.

Lines do not cross box boundaries

A line crossing a box boundary is two lines with a hidden junction at the edge. Make that explicit: ports are visible marks on a box’s edges. Crossing a boundary without a named port silently destroys layer independence.

Right-angle lines only; no crossings

Rounded right-angle bends. No crossing lines. No free-form curves. The diagram compiler only needs to know which port connects to which port — it does not care where on a box’s edge a port sits. So: move ports freely along edges to eliminate crossings. The result is visually cleaner, and the semantics are identical.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Architectural Portability

Paul Tarvydas — Sat, 21 Mar 2026 19:52:05 GMT

TL;DR

The most re-usable architecture is the smallest one.

Write a problem-specific notation that emits code in several languages. It doesn’t need to be Turing complete. It just needs to capture the problem structure. You now own the semantic level above any particular target language.

Going from tight to loose is easy. The other direction is the disassembler problem — semantic information has been dropped and you have to re-infer it. Keep the high-level description alive. Emit from it.

Working code is working code, whether written by a human, a generator, or an LLM. Test it either way. When you take code from a repo, freeze it — copy the source, cut the live dependency. Start from repos. Don’t end there.

You can get through alpha several ways: type-checked languages, LLM-generated code, or a REPL-based dynamic language that keeps the program alive while you’re writing it. Programming languages are stone-age IDEs. The REPL is a fundamentally different relationship with the running system. Use it.

Compilation is an optimization, not a methodology. It belongs after beta. And compiled code needs to be tested again before production — it’s a different artifact from what you tested. Develop dynamically → beta test → compile → gamma test → ship.

Type safety is not the finish line. Shipping software that does what users need is.

L;R

The most re-usable architecture is the smallest one.

This sounds obvious until you watch someone spend six months building a framework that can do everything, and then spend the next six months explaining why it can’t quite do this particular thing.

Small and simple isn’t a concession. It’s the goal. A small architecture fits in your head. It composes. It gets out of the way. And critically — you can pick it up and drop it into a new context without dragging half your previous project along for the ride.

The Meta-Language Move

Here’s a technique that pays off disproportionately: instead of writing your solution directly in one programming language, write a problem-specific notation that emits code in several languages.

A word on the “new language is confusing” objection. If you write your logic in a standard GPL — Python, Rust, whatever — a maintainer (possibly yourself, six months from now) still has to decipher what you intended. That work doesn’t disappear just because the language is familiar. And if you write it in a language from Mars, they still have to learn the syntax. But syntax is the easy part. The hard part is always the same: understanding the architecture, the DI — Design Intent.

Current GPLs are not much better than assembler in this regard. They specify the details of operation in ways so excruciatingly detailed that only a machine could love them. That’s the opposite of what a high-level language is supposed to do. The point of abstraction is to summarize what — the DI — not to drown you in how.

If the language from Mars describes your DI in human terms better than the equivalent GPL code, the maintainer pays a small one-time cost to learn the Martian syntax, then spends less time total figuring out what the software is actually doing. The how — the excruciating details — should remain available. But it shouldn’t be the only way in, or the first way in.

Your notation doesn’t need to be Turing complete. It doesn’t need a type system, a module system, or a five-year standardization process. It just needs to be good enough to capture the problem structure and emit reasonable code in Python, JavaScript, whatever you need this week.

This is not a new idea — it’s the idea behind every successful DSL, every template engine, every macro system worth using. What’s new is that the tooling to build these things has gotten embarrassingly cheap. OhmJS, PEG parsers, even a few hundred lines of Python with regex — you can have a working transpiler in an afternoon.

The payoff: you now own the semantic level above the target language. Want to emit Rust next year instead of C? The translation lives in one place. Your problem description hasn’t changed.

Tighter to Looser, Not the Other Way

There’s an asymmetry here that’s worth naming. Going from a tighter, more constrained language to a looser one is easy. Going the other direction is hard — it’s the disassembler problem.

When you compile down, semantic information evaporates. Variable names become offsets. Intent becomes instruction sequences. Structure becomes flat. And if you later need to go back up — to recover that intent, to work at the problem level again — you have to re-infer what was thrown away. That inference is never complete. You’re always guessing.

This is why architecture matters at the source level. Don’t throw away the structure prematurely. Keep the high-level description alive. Emit from it, don’t abandon it.

Should You Let an LLM Write the Code?

Sure. Why not?

Working code is working code. It doesn’t matter whether a human typed it, a generator emitted it, or an LLM hallucinated it into existence on the third attempt. What matters is whether it passes the tests.

The anxiety about LLM-generated code usually confuses authorship with correctness. These are orthogonal. You’ve always needed to test code written by other humans. You test code written by yourself. Testing LLM output is the same discipline, applied to a new source.

One practical note: when you take code from a repo — whether written by a human or generated — freeze it. Copy the source. Don’t maintain a live dependency on something you don’t control. Debug it until it works, then protect it from future upstream changes. The goal is a product that works, not a product that works today but silently breaks when some package maintainer makes a different choice next month.

Start from repos. Don’t end there.

What LLMs Actually Reveal About Type Checking

LLMs have made something visible that was always true but easy to ignore: you can produce working software without type-checking your way to apparent correctness.

This doesn’t mean type checking is useless. It means type checking is one tool, not the destination.

The actual goal is getting to beta testing as fast as possible. Beta is where real feedback lives. Alpha is where you’re still arguing with yourself about the shape of the problem.

There are several reasonable paths through alpha.

You can use a tight, strongly-typed language and let the type checker catch structural mistakes early. Or you can use LLM-generated code and move fast on the assumption that tests will catch mistakes instead. Or — and this one gets underrated — you can use a REPL-based dynamic language and develop interactively, tightening the loop between idea and running code to almost nothing. This is what “RAD” actually means when it’s working.

Programming languages, when you squint at them, are stone-age IDEs. They were designed in an era when you submitted a deck of cards and came back the next morning. Dynamic languages broke from that model: the program is alive while you’re writing it. You poke it. It answers. You adjust. The REPL isn’t a toy feature — it’s a fundamentally different relationship between the programmer and the running system.

AOT-compiled languages trade that interactivity away. Which is fine, eventually. But compilation is an optimization, not a development methodology. It belongs at the end of the process, not woven into every iteration. You compile after beta. Not before.

Compiled code also needs to be tested again before it goes to production. The compilation step is a transformation. Transformations can introduce problems — optimizer bugs, platform differences, linking surprises. If beta was your dynamic version, you haven’t actually tested the compiled artifact. Call it gamma testing if you want a name for it. The point is: the compiled binary is a different thing from the program you tested, and treating it as automatically identical is wishful thinking.

The sequence should be: develop dynamically → beta test → compile → gamma test → ship. Not: refuse to run the program until the types check out.

What’s not reasonable is treating type safety as the end-state — the proof that the software is done. Software is done when it does what users need it to do. That’s a test. Go run it.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html

Who Am I and Why Should You Care?

Paul Tarvydas — Sat, 21 Mar 2026 19:07:02 GMT

A quick note on some changes here: I’m keeping all content free, but I’m turning on voluntary paid subscriptions. If the work is useful to you, a paid subscription is appreciated but never required.

I’m also still learning Substack’s features, so you may see incremental changes in how posts are delivered over time — the goal is to reduce email noise without restricting access to anything. Suggestions are welcome.

Who Am I and Why Should You Care?

I’m a retired electrical engineer who ran a software consultancy for over 25 years. Embedded systems (credit card terminals, the kind of hardware that has to work every single time), Y2K renovation of COBOL codebases using advanced parsing and backtracking tools and design recovery, tax platforms, business strategy tools — I’ve built the unglamorous stuff that actually runs the world. None of it was glamorous. All of it taught me something.

What it taught me, mostly, is that software is far more complicated than it needs to be.

Hardware designers work with schematics and ICs — reliable, composable, and honest about time. Software designers inherited notation from the 15th century printing press, then the 19th century QWERTY typewriter, and never stopped to ask whether those tools were the right fit for a fundamentally different medium.

They aren’t.

There’s a trap worth naming early: casting deep thinking into mathematical form is a one-way operation, not two-way. Once you understand something, you can express it in math — but the math doesn’t contain everything you understood. Whatever was elided to make the expression concise is gone. The map is not the territory, and the equation is not the insight. I try to keep that distinction front of mind in everything I write here.

The core thesis

Real life is asynchronous. Software pretends it isn’t. That pretense is the source of most of the accidental complexity we spend our careers managing — callback hell, promises, mutex locks, race conditions, the whole zoo.

I’ve spent years asking one question: why are hardware designs more robust than software designs? Hardware is fundamentally asynchronous — components react to signals, they don’t wait their turn. If we expressed software the same way, would reliability go up? I think yes. And I don’t think the current answers — threads, promises, async/await — are the right path. Bolting asynchrony onto a synchronous foundation feels fundamentally backwards. What we’re doing today is like writing assembler. We need better notations for expressing compositions of asynchronous components. Can we just start from asynchrony instead? I’m now convinced the answer is yes, and that doing so leads to something almost embarrassingly simple. If you know how to build a queue, you’re most of the way there.

What I publish

I’ve put out hundreds of articles on GitHub Pages and Substack, and hundreds of videos on YouTube. Most of it is free. I believe in partial marks — publish the unpolished thought, not just the finished paper. A lot of what I write reads more like a working diary than a journal article, and I think that’s a feature, not a bug.

The topics look scattered from the outside. Diagrams as code. Prolog. Forth. Functional programming’s hidden assumptions.

They’re connected. The connecting thread is always the same question: what is being elided, and what does that cost us?

What I’m driving at

We are still using 2D notation — text, math symbols, sequential syntax — to describe programs that run on hardware that lets us think in four dimensions. x, y, z, and time. We have the technology to express programs in 4D. We just haven’t built the habit.

Functional programming elides time and ordering. That’s fine for ballistics computations. It is not fine for systems that need to respond to the world as it actually is — concurrent, event-driven, asynchronous by nature.

I’m not arguing that functions are wrong. I’m arguing that functions are not enough, and that treating them as the only legitimate notation is what got us into this mess.

The path out involves asynchronous-by-default design, diagram-based notations, staged computation, and the willingness to admit that no single notation covers all bases. Software is catching up slowly.

I’m trying to help it catch up faster.

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html