Back in the olden days when computer screens looked a lot like the picture above, and computers were awfully slow with tiny memories the Forth programming language was a great invention.
For those who are too young to even know about what Forth is — it is basically a programming language that just implements a stack machine which is completely under the programmer’s control.
If you wanted to add two numbers instead of writing an expression such as print 1+2 one would have to place the numbers on a data stack, add the two topmost items together and then print the result, in Forth: 1 2 + . — the dot being the Forth command (“word” in Forth parlance) for printing a number.
This might look unfamiliar to most programmers today, but some machine to machine systems such as PostScript, the language used by high end printers, work in a rather similar way.
Some do consider Forth to be an esoteric programming language even though it has been used extensively in the past in various embedded systems. Forth also has been part of the bootloader in lots of computers (it was just called OpenFirmware) there.
One could create a Forth compiler that was small enough to fit into a few kilobytes of memory and do useful edit, compile, run cycles with precious little resources.
There was a time when the only option was to have one compiler on a small computer, and people wanted everything to be written in the only only language their system supported. Such systems are quite rare today as computers have grown more powerful. While on some embedded systems on the small end it still might pay off to do that, I have not worked recently on any system where trying to rewrite major parts of the software in Forth would be justifiable.
I have to admit that I have only worked on one large project that tried to recreate in Forth lots of functionality that was readily available in C at the time — a lot of things did not go so well. Among other things getting a bunch of Forth programmers to cooperate is like herding cats (and it shows in the Forth standards). In spite of that we did create a device that had everything written in Forth including a full TCP/IP stack and web browser, all running on an i21 Forth processor. But then if we were allowed to use C, we could have just grabbed something that was out there instead of spending time reinventing the wheel…
Why would anyone rewrite stuff that already exists instead of just building on it? OK, one reason would be if you can do a better job at it — but most people (including most religious Forth programmers) cannot actually do a better job at everything themselves. Modern technology requires cooperation, not individual isolated from the world trying to reinvent the wheel.
There were other aspects of working on a Forth only project that gave me interesting insight. For example working in the same office as the inventor of Forth for years, and watching people interact with him did give me the eery feeling that Forth was not so much a programming language as some sort of cult.
The days of serious resource constraints are mostly are gone except for some really small microcontrollers — which definitely are not very well equipped to provide a full ANS Forth platform.
A certainly would not consider writing any large scale desktop application in Forth — it is just so much easier to create something in C# with all the goodies in the libraries.
The average cellphone today has more computing power and storage space than a desktop had some 15-20 years ago. So why would anyone still use Forth?
Today many “small” embedded systems feature a 32 bit CPU core with some widely used instruction set. Many run standard operating systems originally designed for a desktop machine and adapted for embedded use. Others run an RTOS of some sort, or go without any OS to speak of.
I did spend a significant portion of my career working on systems that did not look like a desktop machine at all and provided precious little in terms of making it easier, or possible at all, to debug something that is in the field. It is an awful lot easier to debug a system, or bring up hardware and experiment with new features if one has some sort of interactive access to poke around registers, write little scripts to exercise functionality and in general have some notion of a command line to interact with the system for development, testing, debug, manufacturing and calibration purposes. And this is one area where I just can’t stay away from Forth.
While people often like to create ad hoc commands made up with their own syntax there is an advantage in using some well defined tools instead, such as a Forth interpreter. If commands do not need to parse their own parameters there is a lot less chance that they will do it wrong, or inconsistently — such as one expecting numbers in hex and another in decimal — looks like a ridiculous argument but people can and often do make such mistakes and then instead of fixing them enshrine them in the documentation providing anyone who has to maintain their code with endless hours of “entertainment” and some job security.
As a result I have ended up writing some form of Forth interpreter during every major project I have been working on during the last decade. Mostly I had to write a new one every time I have switched jobs since the previous one ended up being owned by the now ex-employer. I am not talking about large stand-alone Forth systems that one can run on bare metal or on top of a desktop OS — there are plenty of those around.
What I usually need if a Forth interpreter that compiles as a small piece inside a much larger C program. It is definitely an advantage if I do not need another tool (like a Forth compiler running on the compiler host machine). Ideally whatever comes out of the C compilation procedure should also have the functional Forth interpreter in it (no, I do not want to load an image file or whatever). An overly burdensome procedure might very well make it unpalatable to management to include a tool that is considered to be more of a developer convenience than a must have feature.
In spite of the belief system ANS Forth standards are based on I have never ever wished I had all the bells and whistles described in the standard.
While Forth enthusiast tend to preach minimalism most Forth systems that one can just download are based on the idea that you are going to do everything in Forth and every single feature in the standard must be present.
Most of the time I had quite the opposite need. I needed something that had a command line, let me rampage through memory, les me call a few service functions in the firmware (the firmware written in C).
I don’t think I have ever wished that I had some support for fancy keyboard events, floating point arithmetic, string manipulation other than some really basic stuff, or local variables. I do appreciate that there are systems that need that — I just ended up working on system that didn’t.
I thought it would be nice to just create one Forth engine, put it out there in the Internet and be done with it, never have to write a new one again, and other people could benefit from it too.
So I did. I am setting up this website and blog as a home for this newly created Embeddable Forth Command Interpreter.
There are lots of Forth systems on the Internet. Many of them are full featured environments that run as an application on a desktop. There are some that might be suitable for embedding in a C program, although not that many. I never found one that I liked but perhaps I am just like other Forth programmers — if I can even consider myself one in spite of the fact that these days I make my living writing in C and C# — and I always like mine better. My goal was not to create a tool to implement everything in Forth, but to create a tool that integrates well with larger C applications and allows interaction with such system.
I will also use this site as a place to share my thought about Forth programming and using Forth as a tool in the modern era of technology.
