Climbing the abstraction ladder does not lead to Heaven. Rather to Noah's ark, according to the law of leaky abstractions. Java has this reputation of being a

Climbing the abstraction ladder does not lead to Heaven. Rather to Noah's ark, according to the law of leaky abstractions. Java has this reputation of being a lot of boilerplate code, and indeed when you compare it to Forth code this is striking. For instance this is the code to square the top of stack: : square dup * ; I don't know much about Java, but I guess it something like: Stack apply(Stack s) { int tos=s.pop(); s.push(tos*tos); return s; } Of course this is not fair at all because Forth has no type checking, no OO and gets its terseness from the point-free style that stack-orientation allows. But this example is symbolic of one thing: Java needs a lot of baggage to be viable. A state-of-the-art GC. A state-of-the-art JIT. A complex lexer/parser. A mildly efficient Forth interpreter/compiler can be written by one teenager. If your job is to get some sort of interpreter running on a brand new hardware, then Forth is probably the fastest way to get that job done. Chuck Moore, the creator of Forth, has funded a company on this - company that is now more than forty years old. This extends to more common use cases. As most processors come on the market with a C compiler, if you have a Forth interpreter written in C, you can have it running right away. Even before you have an OS for it. But you can benefit from the OS and the large number of C libraries too. Writing library bindings for a Forth system is often trivial; the hardest part is to decide how the API should look like on the Forth side (often library APIs are too rich and you want to only expose the useful subset for you). So "stack-oriented programming" leads to simple interpreters and compilers, which in turns gives a lot of flexibility, which is very valuable to get things done.