A Confession

8 Nov 2025

I have a bit of a confession to make. I don’t get Forth. It’s a language I’ve admired from afar, and its approach is genuinely novel and intuitively appealing. However, every time I try to dig deeper, I just… don’t get it.

It’s not that I don’t like different languages; on the contrary, I’m fascinated by them. You’re unlikely to come across Forth these days if you’re not. Nor is my experience limited to mainstream C-alikes; I’m familiar with Lisp and Scheme, ML and Haskell, assembler and SQL. I’ve played with SmallTalk and Prolog and TeX and Scratch. My last job revolved around Verilog and TCL.

I mention that to emphasise the fact that I come to Forth with an open mind. More than that, I come with eager anticipation, as there are a lot of aspects that look good. I like the lack of extraneous syntax — I don’t think I’ve seen a language with less boilerplate and ceremony than Forth — and the use of the stack takes this further by making the flow of data largely implicit. It reminds me of the point-free style in Haskell, putting the focus on what you’re trying to achieve rather than the mechanism by which you’re achieving it. I’m also a fan of the way it erases the barrier between runtime and compile time, and offers an interactive, malleable environment without the overhead that usually entails.

Forth has a reputation of offering both low-level performance and high-level structure, and this is where I run into problems. It certainly has the former, but the more I dig into the details the less convinced I am of the latter. Perhaps this was true when it was conceived. It’s certainly more structured than assembler or BASIC (at least the basic versions), and less rigid that earlier languages like FORTRAN and COBOL. However, even at the time of Forth’s inception in late 60s these weren’t the only options. Its near-contemporary C offers a similar combination of flexibility and performance, with somewhat different tradeoffs, and Lisp was hitting many of the same bullet points almost a decade earlier.

Both of those languages were both useful at the time of their invention, but their core concepts were solid and flexible enough to grow and spawn entire families of progeny and imitators, going far beyond their original scope. Forth, in contrast, seems to have stayed largely in its lane of writing efficient, close-to-the-metal code on a small scale. From what I’ve seen so far, as you move to more complex applications — in particular, more dynamic ones that operate on less uniform data — it feels like Forth’s flexibility and minimalism are working against it.

I’m not giving up, though — enough smart people have extolled the virtues of Forth that I remain convinced that there’s something there. I’m just not getting it. To try and get into the mindset of its heydey, I’ve been exploring Acornsoft FORTH on the Electron, aided by Richard De Grandis-Harrison’s extensive book FORTH on the BBC Microcomputer. Maybe it will click, and even if it doesn’t it’s definitely something different.

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at rob@rho.org.uk, and I'm @robhague@mas.to on Mastodon and robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light (© 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License). BBC BASIC code is set in FontStruction “Acorn Mode 1” by “p1.mark” (licensed under a Creative Commons Attribution Share Alike license).

All content © Rob Hague 2002-2025, except where otherwise noted.