Starting Forth – the classic Forth language tutorial
forth.com
forth.com
So, yes, Factor is worth a look. Certainly as a mind-expander, and possibly as a practical production language (just guessing here).
I learned a lot from this book.
Forth is a programming language from the 1970s. This is the canonical book, published by someone who works at Forth Inc. (as K&R is to C)
Forth is interesting, not because of widespread usage, but because it has a different way of looking at things. Reminiscent of people who tell you that you should learn LISP because you'll never use it, but it will make you a better programmer.
The key difference is that it is stack based. (For those who are more mathy, you may have heard of RPN on the HP calculators)
e.g. 2 5 * 3 -
is take 2 and 5, multiply them. Take the result and 3, subtract them. get 7.
The wiki article has a nice picture of stacks that may help: http://en.wikipedia.org/wiki/Forth_(programming_language)
(btw, not super knowledgable about this stuff; just super confused, did some digging and figured others would be confused as well. Happy to edit.)
EDIT 1: Habits die hard. Corrected Fourth to Forth.
Start with 'jonesforth.S'
Seriously though, I could probably write something interesting about ArrayForth and GreenArray chips--I've been playing around with them for a while and even wrote an emulator for their instruction set. Yet another topic in the queue for my blog, which doesn't even exist yet :P.
That experience probably marked the last time I used Forth on an embedded system. Every time I considered the idea for my own work I remembered what happened to him. As a result I pretty much stayed with C/C++ for embedded work from that point forward.
My gut feeling is that today Forth is a liability for most applications outside cases where there might be an existing code base that must be leveraged.
EDIT: I still think it is important for programmers to learn about TIL's and Forth. You'd gain valuable perspective and a different way to see and approach problems.
[1] http://yannramin.com/2009/10/16/the-wikireader-cool-device-f...
As Forth is very low-level and allows direct access to memory (and thus memory-mapped registers), it makes testing hardware quite efficient (and fun).
What makes you believe the WikiReader didn't sell well? AFAIR quite the opposite.
I'm actually considering getting one of these for that price, would be an interesting device to tinker with FORTH.
Do moderately bright kids not get exposed to HP RPN calculators anymore?
No, they learn BASIC (maybe) on the TI graphing calculators.
A few years later he and his team had converted it to C, too, since they couldn't find people to work on it.
I recently re-read _Starting FORTH_ and was again struck by how simple the language is. It's perfect for things like system bringup (which is what we used it for at Atari) and other small applications where you don't need complex data structures or hard real time operation, and your team is small.
Beyond that, FORTH doesn't appear to scale. That's also an important lesson.
Every embedded engineer should write a FORTH kernel. It's small enough to take just a few days to get something running. It's a valuable lesson in "just enough, and lots less than you think you need".
Of course you can write your own dynamic allocation routines, but that will make your FORTH less than simple. [I'll assume here that garbage collection is probably out of scope for tiny embedded systems -- I'm just talking about lack of malloc/free-like functionality]
The standard advice is to break up functions into smaller and smaller units, but I found you can only go so far doing that, and in any case it just leads to having lots of small functions to understand which is a type of complexity in itself. Being effectively forced to use the stack to store and pass intermediate results around is highly non-intuitive for programmers used to more common languages.
That's not an "immediate" problem, far from it. I've written a standalone Forth system. I could boot it from a floppy, modify its source, and recompile it in less than a minute on an anachronistic 8086-based laptop. Then I ported to C in order to be able to play with the zillions of libraries one can find on Windows and Linux, to play with GUI and 3D Engines. I did implement heap functions, but it was more for the fun of it than because I needed them.
> poor handling of complex functions.
Other languages would let you create function/methods that spread over dozens of pages, but this is universally considered bad form. Forth isn't designed for bad form, which is indeed a serious competitive handicap nowasdays.
> Of course you can write your own dynamic allocation routines, but that will make your FORTH less than simple
So you either say "Forth sucks" or you can say "Are there better ways?". If you add up the overhead of heap allocation structures, the size of the malloc/free functions and the overhead of calling malloc/free, you'll find out that often, over-allocating static structures is just as good, memory-wise. Moreover most systems, including many embedded systems, have plenty of resources. So it doesn't really matter if you waste some kilobytes because you're over-allocating.
> having lots of small functions to understand which is a type of complexity in itself
Ravioli code versus Spaghetti code has always been a conundrum. In the end you just can't set an arbitrary limits on the size of definitions/functions/methods. I think the correct criteria is that you definitions are semantic units. As Brodie points out in Thinking Forth, if you can describe your definition in one short sentence, it is ok. If you do that and still end up with lots of definitions, it is likely that the problem you are trying to solve is itself complex.
> highly non-intuitive for programmers used to more common languages
That's to me a funny reproach, because my definition of a programmer is to be able to absorb and adapt to new languages, styles and paradigms in no time. You know that feeling when you try to explain what's your job exactly and people think you're talking witchcraft? Our job is to deal with non-intuitive, occult siliconic forces.
One question to programming language experts: Is it possible to have a stack-based programming like forth but without the need for the extra characters needed in the syntax (like quotes, brackets etc..) and only use whitespace to separate the 'words'?
arithmetic syntax: (a+b)*c
lisp syntax (polish notation): (* (+ a b) c)
forth syntax (reverse polish notation): a b + c *
'(' parses comments : ( comment)
's"' compiles string literals : s" abc"
'[if]' conditionally skips code fragments: 0 [IF] bla [THEN]
Thanks for the explanation. I really ought to do a practical session with Forth.
SOURCE TYPE BYE
Have a look at Rebol which is a mix of Forth, Logo & Lisp.
Here's an example of Rebol code (typed into the console (REPL))...
>> multiply add 1 2 3
== 9
>> multiply (add 1 2) 3
== 9
Here's an example of a conditional:
>> if equal? 1 1 [print "1 is 1!!"]
1 is 1!!
>> equal? 1 1
== true
>> [print "1 is 1!!"]
== [print "1 is 1!!"]
>> do [print "1 is 1!!"]
1 is 1!!I agree that Forth is a liability today. I could see it being used as an introductory language - in junior high school, for example - but not much beyond that.
Great to see it online.