Next Previous Contents

4. Flame baits

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).

4.1 Commercial vs. free Forth systems

"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."

4.2 Free Forth systems are bad for Forth.

"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]."

4.3 Blocks vs. files

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

4.5 Type-checking and Overloading

"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."

Next Previous Contents