A while back I wrote a Forth interpreter and ended up posting a bit of a rant here about what I'd learnt from the experience, which I won't repeat; but after so

A while back I wrote a Forth interpreter and ended up posting a bit of a rant here about what I'd learnt from the experience, which I won't repeat; but after some more thought, I think Forth is best described as a kind of interactive super assembly language. Writing Forth requires the same level of attention to detail and obsession with minutiae that assembly does. There's no runtime safety whatsoever. There's no syntactical safety whatsoever. It will do exactly what you tell it, even if what you tell it makes no sense. (I found myself thinking of the interpreter as the worst kind of passive-agressive cow orker. "I just assumed you had a reason for writing that floating point number to the program counter! I'm not a mind reader, you know!" "But if you wanted that loop closed at the end of the word definition, why didn't you close it yourself?" "It's not my job to remember whether that word left a float or an int on the stack. Don't you know?") But this also gets coupled to the Forth programmer mindset, which is the ultimate YAGNI. Forth programmers don't just avoid abstraction, they consider it evil. I found a good example from Chuck Moore's website, where he compares the Linux IDE driver (thousands of lines of code) with an equivalent Forth one (two lines). ...except, of course, the Linux driver is a command scheduler to the VFS block layer. The Forth driver's just a couple of words which read and write bytes from an IDE channel. They are in no way equivalent, except that in Chuck Moore's eyes they are. The same philosphy permeates the entire language. Good Forth programmers appear to solve hard problems by ruthlessly stripping away everything irrelevant from the problem to end up with an easy one. So, a traditional Forth system has no file system; it's easier to just remember which disk blocks you put your data in. Code portability's unimportant --- each program runs in its own customised Forth environment; avoiding platform-specific features is a waste of time. (Most Forthers I've talked to hold the ANS Forth spec in active contempt.) There's very little reusable code because each Forth solution is so tightly tied to the problem it's solving to be useless for any other problem. Where it really excels is in an environment where you don't want any abstractions between you and the hardware --- it's brilliant on tiny, embedded devices. I don't know any other environment which can do so much in so little; being able to connect a serial terminal to a embedded processor with 2kB RAM and run commands on it is so, so useful. I'd strongly recommend learning at least the basics of it, even if you're never going to use it. There's that wonderful Aha! moment as your mind reconfigures itself.