Some statements spawn long and heated discussions where the participants repeat their positions and ignore the arguments of the other side (flame wars). You may want to avoid such statements.
Here, I present some regularly appearing flame baits and the positions you will read (so you don't have to start a flame war to learn them).
"You get what you pay for. With a commercial Forth you get commercial documentation and support. We need commercial Forth systems or Forth will die."
"I have had good experiences with free Forths. I cannot afford a commercial Forth system. I want source code (some commercial vendors don't provide it for the whole system). Examples of bad support from commercial software vendors. Without free Forth systems Forth will die."
"Anyone can write a bad Forth and give it away without documentation or support; after trying such a system, nobody wants to work with Forth anymore. Free Forths give Forth a bad name. Free Forths take business away from the vendors."
"Many people learned Forth with fig-Forth. There are good free Forths. Most successful languages started with (and still have) free implementations. Languages without free implementations (like Ada, Eiffel and Miranda) are not very popular [There are free Ada and Eiffel implementations now]."
The discussions on this topic are much cooler since Mike Haas has dropped from comp.lang.forth.
"Everyone is using files and all third-party tools are designed for files. Files waste less space. Blocks lead to horizontal, unreadable code. Blocks make Forth ridiculous."
"We are not always working under an operating system, so on some machines we don't have files. We have very nice block editors and other tools and coding standards for working with blocks (e.g., shadow screens)."
Everyone who mentions using LOCALS| gets the following flame
from me:
LOCALS| is bad because the locals are ordered contrary to
the stack comment convention. I.e.:
: foo ( you can read this -- ... ) LOCALS| this read can you | ... ;
The following locals syntax is better and widely used:
: foo { you can read this -- ... }
... ;
You can find an implementation of this syntax in ANS Forth at http://www.complang.tuwien.ac.at/forth/anslocal.fs
"Static type checking allows catching bugs early. Overloading makes code more readable. Many other languages use type-checking and overloading to various extents."
"Type errors are caught early in testing even without type
checking; they are not a problem in practice. Type-checking may
seduce the programmer to do less testing. Type-checking sometimes
gets in the way. Overloading makes code harder to read, and
especially harder to debug. Overloading is error-prone, because it is
easy to read the code differently than the compiler. Overloading
sometimes gets in the way. Typechecking and overloading require more
complexity in the compiler, with various other negative consequences.
Forth offers facilities like execute and run-time code
generation and it allows building your own object-oriented system
(etc.); these features would be hard or impossible to achieve with
static type checking. Dynamic type-checking costs run-time."