Why I Use Forth

In 1986, I bought an Atari ST. Compared to other home computers of that time, it was bleeding fast, and had a wonderful GUI. It had virtually no software, but this was supposed to change. The main reason I bought it was to become a hacker (in the sense of ESR's "New Hacker's Dictionary"), and the main excuse was to computerize a comic strip a friend and I had been drawing for three years.

Well, there was nothing like a comic construction set or such like which would allow me to draw the comic on the screen. The only two programming languages I got with the ST were ST Basic and Speed Logo. ST Basic was soon forgotten, and Speed Logo was dog slow, and a toy. I used it three months to learn programming, though, and I wrote two little games in it.

After three months, I decided to get a real programming language. There was the C development system, which was very expensive, needed a hard disk (very expensive, too), and in fact, I didn't have that money.

However, I read that there was a PD Forth system (volksFORTH), and it was considered to be a machine oriented language, and since it won't cost me anything except the floppy (10 Deutschmarks! They were expensive those days), I got it. I got a book about Forth, too (Leo Brodie's "Starting Forth"), and I liked that language from the start.

I soon started to write my "Comic Construction Set" (CCS), and it turned out that I had to do a lot meta-work. There was a GUI, but it wasn't easy to program. So I wrote a half-ways object oriented package to cope with it. This brought the program forward, and soon it could handle multiple windows, user defined objects, and many things I needed. I've even drawn some "art" to test the program. However, the work on the comic strip stalled in the meantime.

After my window library stabilized, I sent it to the authors of the Forth system, because I though this would bring Forth forward, and I felt obliged to give the hacker community something back. It was the only major contribution the authors got, and since their motivation had erroded quite a bit, instead of incorporating my changes into their system, they gave the rights of what they did to me. So I had an improved 32 bit native code system with some flaws (volksFORTH was 16 bit, threaded code), no documentation and some work to put into it, and I was alone with it.

I decided to make it commercial, as the experiences of the PD authors were not very good. People seemed to want printed documentation (I never had any documentation for the system except the source), and therefore they must pay something, anyway.

Therefore I stalled the CCS until I got the new system to a state where it would be ready to use. Thus I never looked back. And that's how I became a Forth implementer by accident. At least I didn't want to write my own Forth, and in fact, I never wrote a Forth system from scratch.

Like Basic and Logo, Forth is an interactive language. You have a command line and you can just type commands in and try them out. This is very helpful for the beginner and the impatients, and it turns out that it is helpful for everyone, especially for debugging. You don't need to write a test program to test your program.

Unlike Basic and Logo, Forth isn't slow. Though it has an interactive command line, programs are really compiled to quite efficient code. Forth programs are also called "words", since each program has a name, like a Logo/C/Pascal function/definition. You call it just by typing in that name. There is no difference between words from the language and words you defined yourself, you can even define words using an inline assembler. The whole system is written this way.

In this respect, Forth is quite similar to Lisp and its descendents, like Logo. With my three months Logo experience, it was easy for me to pick Forth up.

Forth differs from Lisp in that it doesn't use lists, neither for calling, nor for storing multiple values. Forth uses a stack to pass data between words, and it uses the raw memory (as seen by the assembler programmer) for more permanent storage. It's much lower leveled than Lisp, and that's one of the reason why it is fast. It's not only fast, the simplicity makes it very small, too.

There's another feature in Forth which is almost unique: the compiler for definitions (or words) is not a single program, which handles parsing, control structures, statements and so on; it's split up into a simple loop which does parsing, and Forth words which are responsible for control structures. As said above, there is no difference between Forth system words, and user defined words, thus you can write your own control structures.

The same is true for data structures. Plain Forth has very few data structures, and it's hard to call them "structures", since they aren't. Forth has just a way to allocate some bytes of memory and assign them a name (which returns the address to allow operation on that memory).

The power comes in that you can bind some Forth code to the label. You can do almost anything with these enhanced labels; you can build arrays, you can even implement an object oriented extension to Forth, where each object, and the classes themselves are just user enhanced data structures.

Plain Forth doesn't have many abilities. It's always much work to get a complicated job done. However, Forth is the ultimate language for building extensions. Programming in Forth is generating higher levels of abstractions, until you have a language well fitted to solve your problem. The simplicity of the underlying system allows it to rely on it, which is important when you search bugs. The usual approach for application programming is to keep each layer simple, too. This is essential for rapid development of critical applications.

The strengths of Forth have therefore been mostly used in embedded control. I've never used Forth in embedded control, although a good customer uses my system to control chromatography systems. For me, Forth is the answer to the question "general purpose language", especially because of it's layered programming approach.