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 symbol-for-symbol translation of "I love Forth" has to rearrange itself into something that looks backwards to everyone except a Forth programmer (explainxkcd). The joke works because the joke is also the whole design argument. In Forth you write 8 5 + instead of 8 + 5: push 8, push 5, then let + reach back and take the two most recent things off the stack (explainxkcd). There's no operator precedence table hiding in a parser somewhere. There's no expression tree the compiler builds for you behind your back. There's a stack, and there's a sequence of words that touch it, and that's the entire execution model laid bare.
That bareness is the point, and it's the thread worth pulling on this week, because two very different pieces of evidence — a decades-old BBC Micro disk sitting in a museum archive and a brand-new implementation release — both land on the same truth about why this design has refused to die.
A Language With Nowhere to Hide
Most languages give you abstraction as a gift: the compiler manages memory layout, the runtime manages the call stack, the type checker manages what can touch what. Forth's stack-based model gives you almost none of that insulation. Every word you define either consumes stack items or produces them, and the only contract between caller and callee is "how many things go in, how many things come out." Acornsoft shipped a Forth implementation for the BBC Micro back in the 1980s as part of its own language lineup, sitting alongside BASIC and other environments on a machine built for a classroom, not a mainframe (Computing History/)). That's not an accident of packaging. On memory-starved 8-bit hardware, a language where the entire runtime is a dictionary of named stack operations and a threading mechanism was genuinely one of the few ways to get an interactive, extensible programming environment into a few kilobytes.
You can see the same calculation still happening today, just with a more eccentric client. A hobbyist building a clone of the Sega SG-1000 — a machine whose BASIC turned out to be too limited to build a real development environment on top of — went looking for something he could put in ROM without licensing headaches, something lightweight enough for an interactive system to live directly on the target hardware (Leaded Solder). Forth was the answer, for the same reason it was the answer forty years earlier: a stack machine with a word dictionary is small enough to fit in places where almost nothing else fits, and it's self-hosting enough that a "real computer," as he puts it, should be able to build programs on and for itself (Leaded Solder).
Minimalism Doesn't Mean Frozen
What's striking about Forth's current moment is that the minimalism hasn't calcified into a museum piece. Gforth, one of the most actively maintained Forth implementations, recently shipped a 1.0 release that adds a recognizer mechanism for handling more literal types, IDE-style tooling for locating and browsing word definitions from inside the interpreter itself, and genuine multi-core multitasking — tasks, mutexes, atomic memory operations, message queues modeled on the actor pattern (daily.dev). None of that breaks the original contract. You still push, you still pop, you still define new words in terms of old ones. The concurrency primitives are just more stack-manipulating words added to the dictionary, which is exactly how Forth was always meant to grow. The release notes claim performance in the neighborhood of SwiftForth, a commercial implementation known for speed, though no benchmark numbers back that up directly (daily.dev). Community reaction, by most accounts, was warm and a little nostalgic — people showing up specifically to praise the minimalism, not in spite of it (daily.dev).
That's the real lesson sitting underneath both of these stories. A language that refuses to abstract away its execution model doesn't just survive on constrained hardware — it stays legible enough, decades later, for someone to extend it without having to unlearn anything first. Most languages accumulate complexity by layering new abstractions over old ones until nobody fully understands the stack of abstractions anymore. Forth accumulates complexity by adding more words to a dictionary that still does exactly what it looks like it does. If you're hunting for a mental model of what "no hidden state" actually buys you, an SG-1000 clone running a homemade Forth port is as clean a demonstration as you'll find.