"Why forth is bad"

To be fair, and not only advocate that what is my way.

I mean, "What forth is bad at".  Forth is bad at solving problems that
are very entangled. Or better: Forth is bad at encoding SOLUTIONS that
are very entangled. If you write a dependency graph of solutions, and
there is no way to draw it without a lot of crossings, then it's going
to be hard in forth. The reason is that you need to do all this
crossing and de-tangling manually using combinator operations (dup
swap ...)

If you have parameter abstraction (naming things) then this
disentangling becomes trivial, because the mapping is encoded using
the endpoints only, meaning the names, at the cost of increasing the
code size significantly.

It can be argued that explicit names make a program easier to
understand. This is really a matter of taste. If i can find a highly
factored solution which can be written in Forth without a lot of
combinator logic, i KNOW i have a good solution that is easy to
understand.

The interesting thing is that most problems that occur naturally can
usually be formulated in a way that minimizes the use of combinators.
this seems to be what "learning Forth" is about: learning how to
disentangles the web of dependencies between elements of a
solution. This is the same as saying: factoring is important in
Forth. Maybe that's an understatement: it is vital to write readable
and working code.

So programming in Forth will force you to factor. It will force you to
think harder, but will usually bring you to a better solution because
it requires you to understand the problem better. It requires you to
understand the problem before you write down a solution.

This is both good an bad. Sometimes you just want to get something
done without thinking about it too much, which in Forth inadvertedly
leads to pretty bad code.

One problem i ran into that is hard to solve is language translation
and optimization, because those are really expression rewriting
systems which are completely randomly structured and a royal pain to
encode in forth without random access to subpatterns. I wrote the
original BROOD project in CAT, which is a functional compositional
stack language. This lead to bad code. The reason was that i didn't
solve it on a high enough abstraction level. To solve language
translation, you need tools like pattern matching. The right solution
would have been to write a pattern matcher first, and then to solve
the problem using that pattern matcher.

Eventually I realised this, but only after using the pattern matching
abstraction in scheme. So now BROOD's core is written in scheme for
the practical reason that i don't need to write my own pattern
matching code.

The moral of the story:

* Forth is concise: a solution comprising a lot of small words is 'right'.
* If it is not, it means your solution is too convoluted, or your
  abstraction level is not high enough.

These things are really universal, and occur in all programming
languages. The only difference is that Forth's scale is bigger: from
really concise to really convoluted. Maybe that's why they say "Forth
is a programmer amplifyer". I'd say it's more like a measuring device
that will display the wrongness of your solution amplified.