Languages That Stretch Your DI Capabilities and Imagination
Programming Simplicity
SubscribeSign in
Languages That Stretch Your DI Capabilities and Imagination<br>2026-07-11
Paul Tarvydas<br>Jul 11, 2026
Share
DI means Design Intent — what people usually call “software architecture,” the expression of intent rather than just code. I’ve come to believe you don’t become a good architect by getting really good at one paradigm. You become a good architect by studying many paradigms, deliberately, including the ones that feel foreign or obsolete.<br>Most of us today learn one paradigm deeply — the function-based / functional paradigm — and mistake fluency in it for architectural skill. But DI is bigger than functions and call stacks. Below is a list of books, papers, systems, and talks that pushed my own thinking outside that box. None of them are “productivity hacks.” They’re worldviews.<br>Smalltalk
Start with the Smalltalk Blue Book — specifically Section Four , which quietly disappeared from the more commonly circulated Purple Book. Smalltalk isn’t “objects with methods” the way most OOP languages borrowed the idea. It’s a complete environment where everything, including the language itself, is a live, inspectable object. Section Four is where that worldview is most exposed: it gives an implementation of Smalltalk in a subset of Smalltalk, including code for the virtual machine and the then-new generational garbage collector.<br>Parsing as a paradigm
Parsing Expression Grammars — Bryan Ford’s original concept and paper — reframe parsing as ordered choice rather than ambiguous grammar resolution. It’s a genuinely different way to think about structuring recognition and control flow. OhmJS is a modern, very approachable implementation of these ideas, and worth playing with directly rather than just reading about.<br>BNF, and its more common successor properly called eBNF, is itself a DSL for writing parsers. PEG and OhmJS use a syntax very much like eBNF’s. But the purpose differs from what came before: traditional compiler-compiler tools like YACC are meant for specifying languages, whereas OhmJS is better understood as a DSL for specifying parsers.<br>Before PEG, I used recursive descent, and S/SL. PEG just makes this so much easier — almost like discovering regexes after years of hand-rolled string matching. PEG’s greatest contribution is arguably the return of backtracking, which had been mostly banished during the 20th century out of a bias toward premature optimization. Backtracking makes it much easier to describe parsers, even where it costs you some raw performance.<br>One of the first things I wrote in OhmJS (which I think of as an improved PEG) was a DSL I call RWR. Using OhmJS plus RWR, I built a small tool called T2T, part of a larger toolkit called PBP. With T2T — and the Ohm-editor grammar REPL — I can crank out custom little languages in minutes or hours. At this point I transmogrify these little languages into running Python code, often as PBP components or as stand-alone Python. I’ve also generated JavaScript, Common Lisp, and Odin code from the same little-language definitions.<br>Statecharts
David Harel’s statecharts extend finite state machines with hierarchy, concurrency, and broadcast communication — and they express behavior as a first-class architectural artifact instead of burying it in conditionals. I made a video of my reading of the original paper: Statecharts — Papers We Love video.<br>Logic programming
The bare essence of Prolog is that you can write exhaustive search using very little code. In our current bevy of programming languages, you need to write tangled code that contains loops within loops and encourages bugs and incomplete search strategies. Prolog and its descendants invert the usual relationship between data and control: you state relations, and the engine searches for solutions. See my Prolog-related referencesroundup, and miniKanren for a minimal, embeddable take on the same idea — relational programming small enough to implement in an afternoon and deep enough to reshape how you think about search and backtracking.<br>Atari Pong (1972)
This one is the sharpest possible contrast to “software architecture” as we usually mean it. The original 1972 Pong hardware fits on one page, is built from asynchronous components, and has no code at all . It’s pure architecture — signal flow and timing — with none of the sequential, function-call baggage we now treat as unavoidable. If you want a jolt to your assumptions about what “a program” even is, look at this schematic.<br>Sketchpad
Ivan Sutherland’s Sketchpad (1963) predates almost everything we now consider modern in interactive and object-oriented computing — constraints, prototypes, real-time graphical manipulation. It’s worth understanding as the ancestor a lot of paradigms forgot they had. Sketchpad was written in assembler — Sutherland did not need automated type checking and all of the baubles we’ve since added to create useful...