[crq-yml]

I believe Lisp is relatively more understood than Forth these days, in that most of the "big ideas" that have been built in it have also been borrowed and turned into language features elsewhere. We have a lot of languages with garbage collection, dynamic types, emphasis on a single container type, some kind of macro system, closures, self-hosting, etc. These things aren't presented with so much syntactical clarity outside of Lisp, but they also benefit from additional engineering that makes them "easy to hold and use".

Lisp appeals to a hierarchical approach, in essence. It constrains some of the principal stuff that "keeps the machine in mind" by automating it away, so that all that's left is your abstraction and how it's coupled to the rest of the stack. It's great for academic purpose since it can add a lot of features that isolate well. Everyone likes grabbing hierarchy as a way to scale their code to their problems, even though its proliferation is tied to current software crises. Hierarchical scaling provides an immediate benefit(automation everywhere) and a consequent downside(automation everywhere, defined and enforced by the voting preferences of the market).

Forth, on the other hand, is a heavily complected thing that doesn't convert into a bag of discrete "runtime features" - in the elementary bootstrapped Forth, every word collaborates with the others to build the system. The features it does have are implementation details elevated into something the user may exploit, so they aren't engineered to be "first class", polished, easy to debug. It remains concerned about the machine, and its ability to support hierarchy is less smoothly paved since you can modify the runtime at such a deep level. That makes it look flawed or irrelevant(from a Lisp-ish perspective).

But that doesn't mean it can't scale, exactly. It means that the typical enabled abstraction is to build additional machines that handle larger chunks of your problem, but the overall program structure remains flat and "aware" of each machine you're building, where its memory is located, the runtime performance envelope, and so on. It doesn't provide the bulldozers that let you relocate everything in memory, build a deep callstack, call into third-party modules, and so on. You can build those, but you have to decide that that's actually necessary instead of grabbing it in anger because the runtime already does it. This makes it a good language for "purposeful machines", where everything is really tightly specified. It has appealing aspects for real-time code, artistic integrity, verification and long-term operation. Those are things that the market largely doesn't care about, but there is a hint of the complected nature of Forth in every system that aims for those things.