Skip to main content

Learning Forth

One of my side projects for this year is to learn the programming language, Forth. Some people might consider this an odd language to learn. It is not a popular language. There are no hot startups using it (that I know of). It doesn't even show up in the top 100 languages in the TIOBE Index. However, I am convinced learning it is worthwhile. Some of my reasons for this are:

  • Forth is probably the most successful and widely deployed language that nobody has heard of. It is the language used to develop OpenFirmware. This boot loader is installed on the laptops of the One Laptop Per Child Project, on PowerPC based Apple Mac computers, and on SPARC based computers from SUN Microsystems. It has also been used to develop to develop control software for the National Radio Astronomy Observatory, which is where it was developed.

    While not as widely used as C/C++, Forth is used a lot in embedded applications and has been ported to most micro-controllers. For example, the Forth, Inc. website has downloadable examples for Arduino and the TI LaunchPad development board. The website also lists a number of interesting applications built with Forth.

  • Forth is a concatenative stack based language. This makes it very different from most mainstream languages, which are based on the object oriented (e.g., Java), imperative (e.g., C), or functional (e.g., Haskell), paradigms, or hybrid versions of these (e.g., Scala or Ruby). Learning this new paradigm opens up new approaches to solving programming problems and provides a new perspective on the art of programming. The stack programming paradigm is used in the JVM byte code interpreter and in the PostScript interpreter, so getting to grips with this programming model is helpful for understanding the low level details of these widely used technologies. Due to its underlying philosophies, Forth is the most pared down and open of the concatenative languages.

  • The history of the language is interesting. For example, one of the first Forth primers was written by W. Richard Stevens.

  • Forth is an excellent language for interacting directly with hardware and exploring the features of hardware. For too long in my career I have been able to get away without knowing much about the underlying hardware that my code runs on. With the rise of the Internet of Things this is a handicap. Understanding of hardware and how to code on it efficiently will become more important. The hardware to software interface is becoming more fluid and that is where Forth lives, so it is ideal for exploring the trade-offs.

  • The primary reason I want to learn Forth is that it challenges conventional programming wisdom. Conventional wisdom says hardware can be abstracted away completely behind multiple layers of abstraction. With Forth it is one layer away. This does mean you can cause damage, like accidentally frying the rx/tx GPIO pins on your Raspberry Pi, to pick a totally random example. However, it also allows for very small and efficient code. Conventional wisdom says you should always use libraries and not reinvent the wheel. The philosophy of Forth says that you are not going to need most of the library and it probably won't meet all the requirements of your application anyway, so writing your own version should be considered. Additionally, how well do you know how the library works and what its tradeoffs are if you haven't tried to implement it. It's these little heresies that point out how much of programming wisdom is taken for granted.

I am using the following resources to learn Forth:

  • Starting Forth, by Leo Brodie. This book is unfortunately out of print, but can be found online here. This is a beginners introductory book, but, looking at the table of contents, it seems to sneak in some advanced topics, like metaprogramming, near the end.

  • Thinking Forth, again by Leo Brodie. I have already read this and it is the best book I have ever read on how to decompose a programming problem and how to structure the solution code. I'll be reading it again after I write a significant amount of Forth code.

  • GForth: this is the main Forth implementation I'll be using.

  • Pi Jones Forth: this is a very bare bones Forth implementation that runs, bare metal, on a Raspberry Pi.


Popular posts from this blog

Repost: ANTLR Trinity

This post is a repost of an article I had on a previous incarnation of this blog. I hadn't intended to transfer it over, as the technology is old now (ANTLR is on version 4), but I recently came acros a slide deck online, where the post was referenced, so I am reposting in case anyone was looking for it. There are 3 components to a really useful software development technology: innovative features, clear and comprehensive documentation, and solid tools. The recent release of ANTLR v3.0 is a perfect example of this. This parser generator tool has all 3 components and each component is done superbly. ANTLR is a parser generator tool that is capable of targeting multiple output languages. Out of the box it will generate Java, Python, C, C#, or Ruby code for parsers. Other target languages are possible if the code generators are written. Amongst its cool features are: LL(*) parsing: This is an extension to the normal, top down with looka

First Post

Hello and welcome to the inane ramblings of an Irish software developer. The title of the blog comes from Lewis Carroll's, Through the Looking Glass . In the book, Alice goes running with the Red Queen, but they don't seem to make any progress. Alice remarks on this, saying, "Well in our country, you'd generally get to somewhere else - if you ran very fast for a long time as we've been doing." The Red Queen replies, "A slow sort of country. Now, here, you see, it takes all the running you can do, to stay in the same place." The Red Queen Effect is quite applicable to the software industry, and as I probably will be talking quite a bit about the software industry, I thought it would be a good name for a blog. I have a few objectives for my new blog. By writing here, I hope to learn how to write well. That is, I hope to learn how to write clearly and concisely, and be interesting at the same time. I also hope that this blog will become a good prof

Useful Links: Logs and Metrics

This article explains why storing log messages alone is insufficient for robust operation of a software service. Metrics also need to be gathered and stored.…/logs-and-metrics-6d34d3026e38 tl;dr - Log volume can spike dramatically when user activity increases, especially when things go wrong. This makes it possible for an alerting system based on logs to be swamped. For a metrics system, volume increases with the number of metrics collected. This is stable and much less likely to fail or slow down during a crisis.