That's what I would call the "Forth challenge", that is to grow out of stack juggling.
When you look at the Forth code of a beginner, yes it's full of stack juggling, of "@" and of "!". When you look at code from more experienced Forth programmers, there's much less of it.
The challenge is to build your way out. There's no fixed way to do this, because the best path to do so is generally dependent on the task at hand.
Needless to say, most programmers fail this challenge.
This challenge comes with rewards. Forth has superpowers that can't be found elsewhere.
But its definitely not for everyone. I'd say that the status quo of Forth being an obscur niche is fine, just fine. If you need convincing, if you aren't spontaneously curious about Forth, then it's likely not for you.
I'm in favor of everyone having fun however they want, and you have piqued my interest a bit that it might be fun.
But if even the proponents of the language say that ("needless to say"!) most programmers will be incapable of the challenge of writing good code in it... definitely doesn't sound like anything I'd want in anything I wanted to be maintainable or long-lasting. If this is the outcome you desire, then your, uh, anti-evangelism is working!
I've never written Forth as part of a team. I suppose it's difficult with an average team. But then I try to imagine what a small team of good Forth programmers could do and I'm thinking it would be a quite powerful team.
Factoring is good way to reduce the complexity but writing math is painfull experience.
To be fair, the infix version of Forth exists as an extension library.
Disagree, there is no types in Forth, only cells. User is acting as a compiler. Comparing to C, imagine that every keyword like for/while/break is implemented as a macros using setjmp/longjmp. And this is a strong part of the language, flexibility but without any guarantees.
When you look at the Forth code of a beginner, yes it's full of stack juggling, of "@" and of "!". When you look at code from more experienced Forth programmers, there's much less of it.
The challenge is to build your way out. There's no fixed way to do this, because the best path to do so is generally dependent on the task at hand.
Needless to say, most programmers fail this challenge.