Forth is awesome. Simple as that. But it's important for people (especially those just being exposed to it) to completely understand why, and what it's done for everyone.<p>The indirect threading model was absolutely brilliant. Almost every bytecode VM in existence today owes Forth (and Moore) a giant "thank you." If you never write a lick of Forth code ever, you'll be a better programmer just by researching how its put together.<p>Forth also pushed for simplicity before it was fashionable. Most "modern" languages pride themselves on their landing-page code samples:<p>sum = fold (+) 0<p>But, again, this is old hat for Forth programmers. Languages today use a lot of great, new ideas to accomplish this: FP, pattern matching, closures, etc. But Forth was pushing - back in 1970 - for all functions to "do one thing" succinctly. If it can't be done in one line, you needed to factor the code some more. And, it's not just that the result is one line, it's that _anyone_ can look at it and know what it does instantly. Remember, this was back when BASIC and FORTRAN ruled with GOTO.<p>Finally, I feel that Forth programmers learn - early on - something I don't see many (very good) programmers learning today: instead of constantly abstracting and obfuscating to try and "simplify" a solution, take a step back and try and simplify the _problem_ so the solution is obvious. For example, this is what I feel the Rust team has done with memory management. Instead of just throwing more brain cells and cycles at trying to improve old-hat solutions, turn the problem upside-down and - in essence - remove it entirely.