In this talk, Chuck Moore (the creator of Forth) makes some very bold, sweeping claims, such as:
- “Every application that I have seen that I didn’t code has ten times as much code in it as it needs”
- “About a thousand instructions seems about right to me to do about anything”
- “If you are writing code that needs [local variables] you are writing non-optimal code. Don’t use local variables.”
I’m trying to figure out whether Mr. Moore is a) an absolutely brilliant genius or b) a crackpot. But that’s a subjective question, and I’m not looking for the answer to that question here. What I am looking for are examples of complex, real-world problems which can be solved in “1000 instructions or less” using Forth, and source code demonstrating how to do so. An example showing just one non-trivial piece of a real-world system would be fine, but no “toy” code samples which could be duplicated in 5 or 10 lines of another high-level language, please.
If you have written real-world systems in Forth, using just a small amount of source code, but aren’t at liberty to show the source (because it is proprietary), I’d still like to hear about it.
You need to understand that Chuck Moore is a little different than you and me. He was trained in an era when mainframe computers consisted of 16 KB or its equivalent in core memory, and he was able to do quite a lot of things with the computers of the time. Perhaps the biggest success for Forth, outside of his OKAD-II chip design package (that’s not a typo), was a multi-user multi-tasking Forth system responsible for concurrently controlling data acquisition instruments and data analysis/visualization software at NRAO on a fairly modestly sized computer barely able to compile Fortran source code on its own.
What he calls an “application”, we might consider to be a “component” of a larger, more nebulous thing called an application. More generally, it’s good to keep in mind that one Moore “application” is more or less equivalent to one “view” in an MVC triad today. To keep memory consumption small, he relies heavily on overlays and just-in-time compilation techniques. When switching from one program interface to another, it typically involves recompiling the entire application/view from source. This happens so fast you don’t know it’s happening. Kind of like how Android recompiles Dalvik code to native ARM code when you activate an application every time today.
At any given time, OKAD-II has no more than about 2.5 KB of its code loaded into memory and running. However, the on-disk source for OKAD-II is considerably larger than 2.5 KB. Though, it is still significantly more compact than its nearest competitor, SPICE.
I’m often curious about Chuck Moore’s views and find his never-ending strive for simplicity fascinating. So, in MythBusters fashion, I put his claims to the test by trying to design my own system as minimally as I could make it. I’m happy to report he’s very nearly spot-on in his claims, on both hardware and software issues. Case in point, during last September’s Silicon Valley Forth Interest Group (SVFIG) meeting, I used my Kestrel-2 itself to generate video for the slide deck. This required I wrote a slide presentation program for it, which took up 4 KB of memory for the code, and 4 KB for the slide deck data structures. With an average space of six bytes per Forth word (for reasons I won’t go into here), the estimate of “about 1000 (Forth) instructions” for the application is just about spot on to what Chuck Moore estimates his own “applications” to be.
If you’re interested in speaking to real-world Forth coders (or who have done so in the past, as it increasingly seems to be), and you happen to be in the Bay Area, the Silicon Valley Forth Interest Group still meets every fourth Saturday of the month, except for November and December, which is the third Saturday. If you’re interested in attending a meeting, even if only to interview Forth coders and get a taste of what “real-world” Forth is like, check us out on meetup.com and tag along. We also new stream our meetings on YouTube, but we’re not very good at it. We’re abusing inappropriate hardware and software to do our bidding, since we have a budget of zero for this sort of thing. 🙂