|
|
|
|
|
|
by ninefathom
1300 days ago
|
|
|
My introduction to Forth was tinkering first with Sun SPARC machines in the late 90s and then PowerMacs in the early 00s. At the time, I had no idea that it was a discrete programming language; it only registered in my mind as part of the OpenBoot/OpenFirmware environments. Then I ran into the FreeBSD bootloader and things finally clicked. "Aha," I thought, "this is an actual programming language." But what made it so popular for the early boot process, and where else was it used? The modularity was stunning. It was easy- almost absurdly so- to build complex code up from a series of tiny individual functions. That, coupled with the minuscule interpreters and simple stack-based approach, made perfect sense for situations where developers need to perform complex tasks with minimum of storage overhead, and with portability as a first class citizen. |
|
|
Probably simplicity. You can get a very basic Forth system going in a few dozen assembly instructions. Then, you write some Forth "primitives", words written in assembly, to do things like basic arithmetic, branching, stack manipulation, and memory manipulation. There are endless debates about how many primitives you really need, but in general a couple of dozen primitives ought to get you started.
Then the rest of Forth is just written in Forth! You might not really have recognisable Forth source at this stage but more complex words can be written out as lists of the addresses of primitives. Think of it as like rolling your own macro assembler. The "inner interpreter" reads these lists of addresses and either jumps directly to the machine code in a primitive, or into a command that starts the inner interpreter chewing on a new word, pushing the one you've just come from onto the return stack.
It seems really really complex until at some point as you stare at it, it'll just snap into focus and you see it's actually a very simple thing that does a very clever trick.