I love Forth: I don't use it any more, but I'm glad I used it a lot in the past.
Programming in Forth is like doing power push-ups with weights, that make you stronger when you're programming in other languages.
It's a "glass box" and you just have to (and CAN, because it's so minimal) memorize not only the name, inputs and outputs of every word, but even recite their implementations in terms of other Forth words. It's simple and elegant enough that you can understand and get your head around the entire system, in terms of itself!
And then when you're writing code, you also have to remember what is on your stack between every word, which changes with every word, or you write explicit stack comments at the end of every line to keep track of them, if you're weak.
After Forth, programming in other higher level languages that let me (gasp) name my variables so they would stay in one place and be associated with meaningful symbols, instead of having to carry them around in my head and and shuffle them around on the stack, it was like slicing butter with a hot knife!
I did a lot of PostScript programming after Forth, but that was easy because PostScript has dictionaries that you can use for local scopes (and which can be used to implement a multiple inheritance object system like smalltalk's), so naming variables is acceptable, and you could keep the stack pretty shallow. Plus PostScript is just a lot more like Lisp than it is like Forth.
Forth is basically at the level of an assembly language, but somehow it feels much more high-level and flexible. Having written a bunch of x86 and some Forth, I would say Forth is more pleasant to use once you’ve gotten over the small initial hump of stack-based programming. And anyway, if you write your functions correctly, the stack becomes an implementation detail. It definitely affects your thinking in higher-level languages, though—naming bits of state ends up seeming way less necessary than naming and composing behaviours.
I’m writing a statically typed functional stack-based language called Kitten, in which the type system and local variables help you work compositionally and avoid managing the stack. It’s not yet ready for prime time, but you might be interested in following its development. Check it out!
One thing I love about Forth is that the Forth assembler is implemented in the same spirit as the Forth compiler, which is to say that it's fully integrated and programmable and extensible in Forth! So it has much more than a "macro" facility -- you can write full-fledged Forth assembly macros that assemble any code you like programmatically! And write your own assembler flow control constructs, and stuff like that!
Chuck Moore is the best sort of kook. I think a strong argument can be made that he is the apotheosis of the computer hacker -- working for a furniture company in Upstate NY? Time to write a round-robin scheduler for my own, personal computing environment!
I was in a serious Forth mode in college (even wrote my own Forth-like language, just because, and even used it for a class project) and because of that, I came across _Thinking Forth_ (http://www.forthfreak.net/thinking-forth.pdf PDF FILE) which ended up being one of only two books that seriously changed how I approach programming. Even if you never program in Forth, _Thinking Forth_ is worth reading.
Since the first time I played with GraFORTH on my Apple II, the simple elegance of Forth made it one of my favorite programming languages and one I'd love to be able to use more.
Amazingly compact too, the whole system code fit in 9k of memory and ran circles around AppleSoft performance-wise, despite having 3D wireframe graphics and bit mapped fonts.
I attended a summer computer camp in 4th grade at Purdue University. Ralph Hempel taught us how to use pbForth on the Mindstorm robots. It was just a simple line following robot but my Forth implementation was much, much better than a LabView implementation that I did as a freshman in college (at Purdue, of course =)!
I really need to reverse engineer the file format of the pbForth projects. I contacted Ralph a while ago, asking for help to obtain the source from the pbForth files that I found on an old floppy. He never responded. That code is oldest surviving code that I have written! The only possible older code is the "code" (I think it was probably GUI flowcharts) that I wrote for the Mindstorms predecessor (what were they called?) LEGO robots for my 3rd grade computer camp. =)
Unfortunately, LLVM is very heavily oriented toward register machines, so adapting its backends to handle a stack architecture would be quite onerous. There is, however, a forth-like demo language called Stacker[1] which might interest you.
edit: It's also worth noting that .fs (Forth Source) has quite a bit of history as a Forth file extension. Github is of the opinion that this belongs to F#, much to my chagrin.
It would, except that the JVM is short a stack -- Forth really likes having two. A Toy Forth is a great next step after writing a Toy Lisp. It's like exploring an alternate universe, where any sort of abstraction between you and the hardware should be knocked down in the name of simplicity.
A few great places to get started:
- Forth Warrior, a programming game using a java-based Forth machine with 2d sprites.
- Jones Forth, a literate x86 forth implementation (great for learning plumbing)
- Retro Forth, a minimalist little virtual machine and Forth image that targets it.
None of these are ANS Forth / FIG Forth / etc compatible, which I think is in keeping with Moore's tradition of just whipping up a new dialect whenever he has a new problem domain.
A Forth Haiku is an attempt to mix mathematics, art, and the
Forth programming language. It resembles a texture shader,
however, the emphasis is on direct expression in the
resulting image.
The Forth program describing each Haiku is run once per pixel
over a square image. Forth cells are floating point.
Conditions return 1 instead of -1. The position is available
from the words x and y, which range from 0 to 1, which the
origin in the lower left hand corner. The haiku returns the
desired color in (red, green, blue, alpha), with alpha being
topmost on the stack. If the stack has less than 4 items
default values are assumed: red:0, green:0, blue:0, alpha:1.
Like a traditional haiku, an ideal Forth Haiku has 3 lines
of 5, 7, 5 words. Compositions which don't fit the haiku form
are either 'short' (less than 140), or 'long'.
I love Forth: I don't use it any more, but I'm glad I used it a lot in the past.
Programming in Forth is like doing power push-ups with weights, that make you stronger when you're programming in other languages.
It's a "glass box" and you just have to (and CAN, because it's so minimal) memorize not only the name, inputs and outputs of every word, but even recite their implementations in terms of other Forth words. It's simple and elegant enough that you can understand and get your head around the entire system, in terms of itself!
And then when you're writing code, you also have to remember what is on your stack between every word, which changes with every word, or you write explicit stack comments at the end of every line to keep track of them, if you're weak.
After Forth, programming in other higher level languages that let me (gasp) name my variables so they would stay in one place and be associated with meaningful symbols, instead of having to carry them around in my head and and shuffle them around on the stack, it was like slicing butter with a hot knife!
I did a lot of PostScript programming after Forth, but that was easy because PostScript has dictionaries that you can use for local scopes (and which can be used to implement a multiple inheritance object system like smalltalk's), so naming variables is acceptable, and you could keep the stack pretty shallow. Plus PostScript is just a lot more like Lisp than it is like Forth.