Latest issue
Forth's Stack Wasn't a Shortcut. It Was a Refusal to Let the Machine Lie to You.
10/28/2026
There's a webcomic that gets Forth's grammar right in a way most explainers don't bother with. In one strip, a car has a bumper sticker that should read "I ❤️ FORTH" but instead reads "I FORTH ❤️" — because in Forth, operators come after their arguments, not between them, so a sy…
Recent posts
Andrew Kelley didn't set out to write a programming language. He was building a digital audio workstation and kept running into walls: JavaScript couldn't touch the hardware he nee…
Ask a working programmer where the IDE came from and you'll probably hear about Visual Studio or Eclipse, something bolted onto a language after the fact to make editing less miser…
I've written before about how APL's glyphs encode a philosophy, not just a shorthand (April 15, April 22). What I hadn't fully reckoned with is how much of that philosophy was down…
Ask a Prolog programmer what makes the language different and you'll usually get "backtracking" or "it's declarative." Both true, both incomplete. The real trick is quieter: unific…
Lesson 26: What a 50-year-old mathematical idea teaches us about memory For five decades, systems programmers lived with a deal that felt non-negotiable: you could have control ove…
Lesson 25: Why Haskell's design forces a different theory of computation There's a moment every programmer hits when learning Haskell where something feels genuinely wrong. You wri…
Lesson 25: What Erlang's origin story reveals about the difference between designing for failure and designing around it --- The actor model is commonly described as "Erlang's conc…
Lesson 24: What Clojure's persistent data structures reveal about the real cost of shared mutable state --- There's a moment every programmer hits when they first encounter functio…
Lesson 24: What Polonius teaches us about the original design bet --- There's a specific kind of frustration that Rust programmers know well: the compiler rejecting code that you k…
Lesson 23: What prohibition-as-design teaches us about correctness --- I covered Haskell's type system back in Lesson 17 — specifically how it encodes what you know rather than jus…
Lesson 22: What Erlang's scaling limits reveal about the difference between a good abstraction and a complete one --- In a previous issue, I wrote about the hidden assumption baked…
Lesson 21: What Elixir's approach to branching reveals about how we think about data --- Most programmers learn control flow as a sequence of questions: Is this value equal to X? I…
Lesson 20: What Rust's compile-time resource model teaches every programmer, regardless of language --- Most programmers encounter Rust's ownership system and immediately frame it…
Lesson 18: What the BEAM's design philosophy actually promises — and where it stops --- When WhatsApp was acquired by Facebook in 2014, the number that made engineers sit up wasn't…
Lesson 18: What the HAMT debate reveals about the gap between design philosophy and performance reality --- When I wrote about immutability in Clojure last month, I focused on the…
Lesson 17: Why pure functional programming is a design philosophy, not a restriction --- There's a moment in Simon Peyton Jones's recent interview on The Developing Dev where he ex…
Lesson 16: What Rust's ownership model reveals about the hidden cost of "letting the runtime handle it" --- A note before we start: I covered Rust's borrow checker in Lesson 13 fro…
Lesson 15: What Erlang's actor model teaches us about building systems that expect to fail --- A telephone switch that handles 30–40 million calls per week cannot afford a maintena…
Lesson 14: What Clojure's persistent data structures reveal about the nature of change --- There's a moment every developer hits when working with shared mutable state: you're debu…
