FORTH and thoughtful programming...

While searching Google for occurrences of "thoughtful" and "programmer", I came across a nice essay by Michael Misamore entitled: "Introduction to Thoughtful Programming and the Forth Philosophy"

I don't fully agree with all of the points that Michael makes in his essay, but I am glad to find that the doctrine of "minimizing overall complexity" still has passionate and thoughtful proponents...

I love FORTH...

In the mid 1980's I worked for a company that manufactured high speed offset printing presses (such as those used to print magazines like National Geographic). Those presses were huge assemblages of rapidly rotating drums that could print thousands of full color pages in seconds. For those not familiar with offest color printing, only 4 colors are used to create the full palette, and each color is applied separately. The alignment of the paper is crucial, or the illusion of full color will fail... Unaligned or unbalanced drums could lead to ruined print jobs, or even catastrophic destruction of the press itself.

The company was very progressive, and developed a remote system to monitor the rotational vibrations of the presses and diagnose problems long before they became evident. This "remote tortional vibration system" was built using the FORTH programming language, and yours truly had the pleasure of writing a Fast Fourier Transform (FFT) algorithm in FORTH. I had a great time developing the code, and the resultant algorithm screamed.

One of my fond but sad memories from that time was the week of training that I received from Elizabeth Rather in Melbourne Florida.

A fond memory because Elizabeth was a great teacher, but a sad memory because our training class took place the week after the Space Shuttle Challenger exploded (you could see the recovery ships combing for wreckage from our hotel).

But back to the FORTH training... Elizabeth (following Charles Moore's lead) was adament that the only code that should be in a production system is code that absolutely, positively has to be there.

To emphasize her point, our final project was scored on how small the code footprint was. We actually removed unused code from the FORTH interpreter itself to get the size as small as possible... A very extreme, but strangely satisfying exercise.

These days, the hard part of my job has much more to do with refining requirements than with implementing solutions, but it's good to take a look back and remember just how clean code can be if you make the effort.