I've always thought that writing a threaded interpretive language (TIL) is a good experience for every programmer. It really changes the way you think. It is also possibly one of those things that might come back into fashion. Since it is easy to fit a FORTH kernel in a few kilobytes, one can imagine sticking the entire kernel into cache. Higher level functions are simply jumps to things that are already in the cache. Along with favouring stack allocation to heap allocation, this goes a long way to creating an environment friendly to multi-processing.
I have trouble imagining a comeback because Forth's unique value is in staking out the tiny-and-simple end of the efficiency frontier. But Lisp is almost as simple if you can spare more resources, while if you're OK with complexity there are compilers that optimize better.
It'd be nice to be wrong, since I'd love to work in a system where every bit is handcrafted and known to me. I didn't quite get there back in the 80s in my summer job at FORTH, Inc. but it did teach me a bunch and I enjoyed scrounging out a few bytes here and there.
> It is also possibly one of those things that might come back into fashion.
Not going to happen. People these days are interested in how to make things work, rather than how things works. They want easy memory management, they want easy concurrency, they want easy safety.
Despite the standardization efforts, Forth has always been about figuring out and design things yourself. It's meant to be your a personal tool that you make and shape for yourself. It means that if Forth is your thing, you won't write just one interpreter and be done with it; you'll write a bunch of them depending on your needs (fully standalone for embedded systems, C-based under Linux/Windows, as a scripting language embedded in an application, etc.)
That's why it has to be tiny and simple. That's why standards and popularity are irrelevant in this case.
