I hate Forth

Stack languages present a troublesome problem for documentation. Forth in particular is untyped, but my own experience was with a small compiler/interpreter I wrote over a dynamic language(haXe). The language was easy to implement, and it solved one domain problem very well(in-game dialogue) and another not so well(choreographing two-dimensional movement patterns). I've filed it away as "cool experiment." My implementation allowed the same syntax to be used with different semantics - a batch compiled word, or words sliced up into lists of function calls, which made them usable in continuation-passing style - very useful for my in-game dialogue.

The debugging I encountered mostly revolved around correcting stack manipulations so that things lined up with the right parameters. The brevity of these languages comes from the stack allowing implicit parametrization; just list your data and then the word you want to use. The downside comes from this property also allowing the stack to leak when under or over-parametrized - enabling mystery behavior or crashes that you wouldn't see with C-style calling conventions.

On the other hand, a major plus: Working with the stack lets you avoid littering your code with named variables. This is what enables Forth words to have extremely high density and readability, and I've incorporated more of this style into my coding elsewhere, so that in the most extreme case, I might go ahead and set up a stack in(for example) an object, and then list out method calls like a high-level Forth operation:

obj.wordA(); obj.wordB(); obj.wordC();

Blending this with more imperative or functional constructs, I can get the best of both worlds: something compact and readable but also self-documenting, with decent type and parameter safeness.

> The biggest documentation failure I typically have seen in Forth is a failure to document the word's parameters, i.e. the stack contents going into and returning from words.

This is one reason that the Forth-like Factor language makes documentation of a word's stack-effect a required part of the syntax of defining a word. I believe these days Factor checks for stack-overflow and -underflow at compile-time, based on the stack-effect declarations.

The real problem is that to understand a statement like "And that's why I hate cats", you have to realize that it's asserting a relationship between the speaker (the "I") and cats, and that the justifications given must therefore contain facts about both the speaker, cats, and the two together, not simply facts about cats alone.

In other words—cats (and Forth) are generally well-known. You aren't. If you're going to tell us why you hate Forth, you should be giving us less facts about Forth, and more facts about yourself.

I like cats, but I am really allergic to them, and thus hate being around them.

What is the similar situation for a programming language?

I have seen FORTH used successfully in a few embedded systems. It's also a great language for doing initial hardware bringup (really easy to write functions that frob register-level stuff).

In my experience it does not appear to scale very well to medium-sized projects (2-3 engineers for 3+ months).

The best FORTH programmers I knew were pretty pragmatic about the language, and were frank about its limitations. The worst FORTH programmers thought it was totally wonderful for absolutely everything, which is of course a recipe for disaster with any language.

It's used as a shell interface in Open Firmware. So, it's in more places than most realize.

BTW, the phrase "personal life at work" is amusing.

Forth is the Unabomber of programming languages.

Most people who admire it (or him) don't say so in public.