You can bring it up quickly on a new platform, be it exotic hardware or a self-styled VM. Small Forths can be totally understood by the programmer (perhaps jus

You can bring it up quickly on a new platform, be it exotic hardware or a self-styled VM. Small Forths can be totally understood by the programmer (perhaps just a few pages of code for their kernel), but still be expressive enough to actually use. Applications written in Forth are typically deeply entangled with the interpreter. You can't separate a "program" from the environment. It's more like a collection of ideas and design principles than one singular language. Most Forth programmers write their own implementation, or several. You can decide what indulgences you want. (I like having "quotations"- inline anonymous word definitions like Retro has- and special-cased string literals. I also have my own style of looping words that aren't quite like ANS Forth.) This also means Forth code can never be dropped into another project and directly re-used: you can only take ideas. Starting from a blank page every time, carrying with you ideas and writing code afresh is a good way to travel light. Self-reliance. Building human-scale programs. No one would write a web browser, or an Oracle-compatible SQL engine, in Forth, because a Forth programmer wouldn't have much of a use for those things. Solve only the problems you really have, with as little code as you can manage.