The comparison to Lisp is most accurate in the sense that learning Forth will change the way you code- it's wonderful to get a completely different perspective every now and then.
Never tried Forth? Do yourself a favor and start now with jsforth[1] or install the "gforth" package. Read Starting Forth[2] for a gentle introduction to the language and Thinking Forth[3] for an in-depth examination of the idioms and patterns of Forth programming.
Interesting that in the previous Lisp vs Python discussion [1], the original article noted that (f x) could mean a lot of things, to which at least one comment retorted that in real code you always have a context, so there really isn't any ambiguity. Yet in this discussion there's a Lisper arguing that with A B C in Forth, you have no idea how many items have been left on the stack. (I presume this is based on a lack of experience, as Canonical Forth style suggests each word starts with a comment detailing beginning and ending stack states.) I find myself wondering, A B C would be surrounded by contextual code, so in real code the meaning would be clear, no?
I think that sociologically Lisp and Forth users are more alike than not, but the camps rarely seem talk to each other. It's clear from Forth's history that it has a secure niche in 8- & 16-bit microcontroller applications. I have no idea if there is such a thing as a Lisp application niche these days.
PostScript is another stack-based language based on Forth, but with specialized graphics commands. It also has the delightful property that many printers can interpret it. I always wished I had known this while taking my intro CS courses, so that I could have submitted my problem sets as PostScript files, to be computed by the printer.
I used PostScript to implement a back-propagation neural network trainer for one of my AI classes. It's not beautiful postscript code (many local variables, some parts are very clumsy because I didn't know better), but fun nonetheless: http://pastebin.com/eY0d11sA
I came to Forth after programming in Postscript and still have a fondness for stack-based languages. I actually think Postscript was the better language of the two, it seemed to easier somehow.
// In the early 90's I got a job that needed me to create a lot of reports / graphs out of a foxbase database. I had a postscript printer and a copy of Turbo C 2.0 (don't forget to download the floating point patch). Gotta love hand coding Postscript templates. I was loving life when I finally got a openstep box.
Factor's heterogenous stack (complex objects rather than integers) definitely reminds me more of PostScript than Forth, and I agree it can make programming much more straightforward. I also liked how PS handles flow control- while Forth uses rather traditional looking left-to-right reading constructs:
3 5 > if ." greater" else ." less" then
PostScript goes with operators like "if" and "ifelse" that consume code literals from the stack (enclosed in curly braces):
I read that a while back also. I'm afraid you got the wrong impression. Forth is another tool, to be used when appropriate. It seems best used when you can adopt the whole Forth worldview, which goes far beyond the typical mental shifts required to switch between, say, C and Lisp.
As I understand it, Forth shines when you look at the entirety of a project and are prepared to find the leanest, most elegant solution to the exact problem, not limited to writing programs for commodity hardware. Forth people are kind of like Motie Engineers[1].
Here’s a sketch of how you could write a toy lisp in forth:
Let’s use “(* 4 (+ 5 6))” as an example input string.
1. Drop ( and ): “* 4 + 5 6”.
2. Tokenize on whitespace and reverse the tokens: 6 5 + 4 *
3. This is forth. Execute it.
There’s at least one class of bug here (that “(- a b)” != “b a -”)), but it shows a sense in which they’re very similar languages. From 40,000 feet, lisp could be called a syntax hack to add variadic functions to a backwards dialect of forth.
To put it another way, forth really is trivially tree-structured just like lisp, but the trees are implicit in the number of arguments the functions take. This allows tricks that depend on the AST being easy to work with, just like lisp macros.
That is not forth. Instead (leaving out a bit of compile-time/run-time distinction magic):
- define [+] something like:
: [+] 0 swap 0 do + loop ;
- define (+ as a word that pushes the address of [+] and the stack pointer onto the retun stack
- similarly define [-] and (- , [* ] and (* , and [/] and (/
- define ) as a word that takes the current stack pointer, pops that saved stack pointer from the return stack and subtracts it from it (this puts the number of arguments to [+] on the stack, pops the address of [+] from the return stack and calls it.
Hooray! A pissing match that boils down to whether stacks are better than lists! //rolls eyes
Was very tempted to say "... match between two dead languages that ..."
But then somebody would nitpick, and they'd get 500 karma, and I'd get -20 and I would burn with the fury of a thousand suns... or if not that then at least the mild annoyance of a social worker watching a hobo be set on fire but not being arsed to do anything about it.
Never tried Forth? Do yourself a favor and start now with jsforth[1] or install the "gforth" package. Read Starting Forth[2] for a gentle introduction to the language and Thinking Forth[3] for an in-depth examination of the idioms and patterns of Forth programming.
[1] http://forthfreak.net/jsforth80x25.html
[2] http://home.iae.nl/users/mhx/sf.html
[3] http://thinking-forth.sourceforge.net/