I hate Forth(embedded.com)
embedded.com
I hate Forth
http://www.embedded.com/story/OEG20010731S0028
9 comments
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 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.
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.
Reminds me of cats. Ask someone who hates cats to describe cats, and cat lovers will agree with the description. Cat hater ends with something like, "And that's why I hate cats," while cat lover ends with, "And that's why I love cats." Both to the same description.
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.
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?
What is the similar situation for a programming language?
I have had people assert that they are allergic to parentheses, causing them to hate Lisp.
Of course, offering to make them a read macro to let them use any two other characters in place of parentheses didn't help, but such is life.
Of course, offering to make them a read macro to let them use any two other characters in place of parentheses didn't help, but such is life.
What a strange article. He's upset because it's easy to experiment and test with Forth? OH NOES, TEH TERRIBLES!!
If you don't like interactive development, then just type everything into a file, compile it, and run. The choice is yours.
If there's something to complain about with respect to Forth it's the flakiness of concatenative programming. I'd rather write a program in terms of function application or sending messages than in stack transforms. That's why I don't like Forth, and is probably the only real reason to dislike it. Everything the author dislikes is in his coworkers, not in the language.
If you don't like interactive development, then just type everything into a file, compile it, and run. The choice is yours.
If there's something to complain about with respect to Forth it's the flakiness of concatenative programming. I'd rather write a program in terms of function application or sending messages than in stack transforms. That's why I don't like Forth, and is probably the only real reason to dislike it. Everything the author dislikes is in his coworkers, not in the language.
He mentioned everything I like about Forth. Peek and poke machine registers. Quick check out of hardware. Forth should be in the toolkit of any one bringing up new hardware. What is there to hate about it ? Every tool has it's limitations and should be judiciously applied to each task.
[deleted]
Note the article was written in 2001.
"Well, now when this all is over, I want to tell you that thisarticle definitely was a joke. ... But why people did not take this article as a joke? Because one has to know Forth to understand this joke. Given that most people do not know Forth, distribution of such articles is anti-education."
The article was satire?
The article was satire?
Are any HN users using forth in your personal life at work? I haven't seen it mentioned here much.
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.
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.
Forth is the Unabomber of programming languages.
Most people who admire it (or him) don't say so in public.
Most people who admire it (or him) don't say so in public.
This seems to be a rant about the limitations of certain language tools, not the language itself.
This is great if you were the one that wrote the DSL and thus understand it intimately (having a prodigious ability to memorize is pretty important too). On the other hand, it sucks if you didn't write the DSL and have to understand how to use it or fix bugs in it because you first have to reverse-engineer the DSL. Reverse-engineering the DSL may take as long as writing it in the first case.
[1] 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 aggravated by the stack manipulation operations duping, swapping, etc. that look more like a game of "15 squares" http://en.wikipedia.org/wiki/Fifteen_puzzle than an algorithm.