So elegant. Always loved Forth in a platonic kind of way, just couldn't ever stand the stack shuffling myself.
I love this turn of phrase and will definitely steal it. In my hobby electronics stuff (esp mc68k) I always think 'I need some software and this is exactly the kind of thing Forth should be good for', and while I have managed to write a Forth once or twice, I always noped right out of making it a place I'd want to spend all my (computing) time.
Fast forward to the 21st century and I still think Forth is cool, but I don't have any actual urge to use it.
(I believe Moore has a small, fixed-size stack on his chips; go too deep and you start reusing stack slots. Somewhere I've seen code that rolled over a fixed stack on purpose but I can no longer recall if it was in a ColorForth or in an x86 math coprocessor)
...which the code in this blog post avoids by defining words that compare dx with dy and return pointers to the "short" and "long" coordinate? You could do the same in C or most other languages.
The problem is that in other languages, a Sufficiently Advanced Optimizer™ could at least in theory analyze the source code, and then emit those nearly-identical code blocks, whereas Forth is more like a platform-independent macroassembler: there is no zero-cost abstraction, every word you write in the source code will result in some predetermined machine instructions being executed (and usually with extra interpreter overhead).
Actual assembly code seems less confining, since at least you have a few different registers and addressing modes to play with, rather than just a stack.
I still kind of like the idea of Forth, but pretty much agree with this article: http://yosefk.com/blog/my-history-with-forth-stack-machines....
Not strictly.. I wrote a partially optimizing Forth compiler that could combine compiled words when building new words that used them from the interpreter, analyze the generated assembly for unnecessary stack movement of arguments, and eliminate the stack movement and if necessary emit MOV instructions to fixup the output results into the correct input registers.
This was not terribly difficult. The harder part was susequently decoding the concatenated x86 instruction streams to do this type of analysis, but once the PUSH and POP trains were spotted, they were super easy to just eliminate.
With careful coding of the assembly words, you could guarantee that common expressions never needed any MOV fixups and could just pass results that were sitting directly in the registers.
I like how they called them desk-sized not because they were the right size to sit on a desk, but because they took as much floor space as a desk: https://www.masswerk.at/nowgobang/images/lgp-30-features.jpg