Why not use Forth?

There are also reasons not to use Forth. One of the most important reason is that Forth is said to be an amplifier. A good programmer programs better in Forth (and he learns to program better in other languages, too, when he masters Forth); a bad programmer programs worse in Forth, and he's spoiled when working with other programming languages, then. The sad fact is that too many programmers must be considered "bad".

I haven't believed this for quite a long time. I found quite a range of programming skills in the Forth community, and certainly I could give them labels such as "excellent", "average", and "bad". The sad thing to say is that this was all relative. Most of these programmers, whatever rank I gave them, had done a lot of very clever things, including those with the label "bad". Those which were average programmers hadn't coded anything in Forth, and therefore hadn't a label.

The Forth approach of layered programming is inherently difficult to grasp. People tend to think linear, and on the same logical level. You don't get anything done with a linear approach, since you won't have the tools you are used to. There aren't much libaries in Forth, as Forthers like it more to reinvent the wheel instead of designing one and make this one reusable. Special purpose wheels tend to be written much faster, use lesser resources, and fit to the applications. And it's easy to get a state-of-the-art wheel this way.

So IMHO Forth is an elitary language, designed and written for the best, or gifted, not for the masses.

It should be noted that the layered approach of writing programs is acknowledged elsewhere, too. However, it's usually considered that one programmer should work in one layer, i.e. write a library, an application or a user interface. A Forth programmer has to move between the layers, as a Forth program consists of several layers, even if it uses an already written library, and someone else writes the user interface.

Forth strongly encourages the hacker's paradigm of "plan one to throw away". It is often cheaper to rewrite a program once you understood what you really wanted instead of living with something that is broken by design. The assumption that it just needs someone clever enough to do the design right in the first place usually is void - noone can look into the future, and without the experience of using the beast, nobody really knows what to put in.