Thinking Forth by Leo Brodie

by Leo Brodie

Thinking Forth applies a philosophy of problem solving and programming style to the unique programming language Forth. Published first in 1984, it could be among the timeless classics of computer books, such as Fred Brooks' The Mythical Man-Month and Donald Knuth's The Art of Computer Programming.

Many software engineering principles discussed here have been rediscovered in eXtreme Programming, including (re)factoring, modularity, bottom-up and incremental design. Here you'll find all of those and more, such as the value of analysis and design, described in Leo Brodie's down-to-earth, humorous style, with illustrations, code examples, practical real life applications, illustrative cartoons, and interviews with Forth's inventor, Charles H. Moore as well as other Forth thinkers.

Genres: Programming, Computer Science, Computers, Technology, Nonfiction, Software, Philosophy

Paperback

First published October 1, 1984

Reviews

[Chuck Morgan]

Thinking FORTH is really the book that started me on the way of thinking about life and software development in different terms. It is more about how to apply software methodology than about the FORTH language itself.

In my previous review of 'Starting FORTH' I broached on the topic of 'Reverse Polish Notation' and how it affected every thought I had for a while. I was always driven to refine software coding in small steps, trying them out along the way before moving on to the next, (the basis of Agile Methodology today ), but this book motivated me to strive for more.

Fueled by Brodie's writings, I continued my pursuit of FORTH for the remainder of the 80's, developing multi-tasking automated scripting engines for a Telecomm company so that they could simultaneously dial up and update four systems at once using a scripted based engine approach, all in FORTH.

This book was definitely the one to read for those who attempted to be the mavericks of software development in the 80's. Leo Brodie's style accompanied with the comical illustrations made me laugh and want to read more. Two really good ones are the illustrations below.

1. There is a drawing of a software developer standing on King Arthur's round table, surrounded by his knights and Merlin. The caption says "So then I typed GOTO 500 and here I am!". Priceless! A jab at the Basic programming language!

2. There is another drawing of developers looking at a wall of flow charts, each one more advanced than the next. The last one has the flow chart morphed into a stick figure much like Mr. Peanut, with a cane and eyeglasses. The stick figure is speaking to the developers in an English accent, asking for a spot of tea. One developer says to the other: "Tobias, I think you've carried the successive refinement of that module far enough". Bravo!

The book is different than the first one by Brodie, in it is more a philsophy course. The subtitle says it all "A Language and Philosophy for Solving Problems". The iterative approach is discussed in Chaper Two, something I have now always tried to live by.

There is a key phrase in the book that developers should all live by:

"You don't understand a problem until you can simplify it".

Here's another jewel that most IT organizations don't get today:

"Given two adequate solutions, the correct one is the simple."

You can read Thinking FORTH today in SourceForge.Net, if you go to this link:

http://thinking-forth.sourceforge.net/

[Mark Seemann · Rating 2 out of 5]

I try to read books about software development that may expand my perspective. I'm already well aware of various isomorphisms in programming, such as the Curry–Howard correspondence and the relationship between object-oriented design patterns and Category Theory-inspired constructs in functional programming.

Forth, being a stack-based programming language, looked at first glance to belong to an entirely different paradigm. I was hoping that by reading Thinking Forth I'd be learning about a completely new way of thinking about problems.

Unfortunately, that doesn't seem to be the case. The Forth stack is, as far as I can tell, just a glorified global variable, and it doesn't seem to eliminate the need for other kinds of global variables, either.

The reason this book seems to have endured longer than the language itself is probably because it's more concerned with good programming practices than the Forth language as such. When it looks up from the language to consider how to structure programs, it is, indeed, quite forward-thinking.

I particularly found this quote from Peter Kogge prophetic:

"write words with what is called “referential transparency,” i.e., given the same stack inputs a word will always give the same stack outputs regardless of the more global context in which it is executed.

"In fact this property is exactly what we use when we test words in isolation. Words that do not have this property are significantly harder to test."

Some of what the book has to say about decomposition and structure seems reasonable even today; more is, however, dated. After all, the book is originally from 1984, and even the most prescient advice is now common knowledge.

It's marginally interesting because it offers an insight into where some ideas that we today take for granted might have germinated. On the other hand, I don't think that I learned anything useful, apart from that.

[Michael · Rating 5 out of 5]

Stretch your mind. Never feel comfortable.

[Phil Eaton · Rating 3 out of 5]

This is a well-known book and regarded to be a good introduction to the Forth language and philosophy. The first half of the book could accurately have been described like that. But the ideas are clearly less revolutionary now compared to a time when high-level languages like C were coming into popularity. Still, it gives an interesting historic look at project development and management from engineers in the 80s. The latter half of the book was almost useless to me with limited prior knowledge to a compiled Forth dialect. It emphasized rather specific Forth techniques for code quality, maintainability, and optimization. And while some or all of these techniques may be applicable elsewhere, they were difficult to follow with the amount of background I have today and the amount of background the book gave me. (I wrote a Scheme to Forth compiler in college and a simple Forth-like interpreter later on.) I might be interested in returning to this book in the future after reading Starting Forth, which seems like a more appropriate introduction to the language.

[David · Rating 5 out of 5]

The high praise for this book was well-earned. It just goes to show that the problems we've been dealing with since the dawn of programming have remained, largely, the same. While this is definitely a Forth-oriented book (and rooted in its time), the philosophy of simplicity and the encouragement to turn a problem on its head until it can be expressed simply is utterly timeless. The interviews were great and the examples were well chosen. In the year 2022, we still don't have the answers to a lot of these questions. Just opinions and more questions.

[John · Rating 5 out of 5]

Advice from an age when every CPU cycle and byte counted. AT first glance this book doesn't seem to have much of relevance to a modern programmer, until you realize that some of the tips are low level implementations of common language features (method overrides in OO languages, for example) *and* discussions on where they are best used. This is very relevant in the multi-paradigm languages of today.

[Frank Carver · Rating 5 out of 5]

Great advice for any programmer, whatever the language

I first stumbled on this book in the 1980s. I had been playing with Forth for a while and was reading everything I could find on the topic. At the time, this book did not make much of an impact. I wanted the pre-internet equivalent of Stack Overflow - quick answers to common questions - and this book had a bit too much philosophy for me.

Fast-forward over 30+ years in the computer business to 2023, and I spotted this on a bookshelf where I was staying for the weekend. Reading with fresh eyes, I can see just how important some of the philosophy really is. Younger me thought nothing of squeezing a whole program into one or two kilobytes and would be rightfully appalled at the gigabyte-sized applications of today. I have spent a significant part of my career working with bloated codebases. The people who designed, created, and maintained them should all read this book, and probably also Charles Moore’s (the man who created the Forth language) original manifesto “PROGRAMMING A PROBLEM-ORIENTED LANGUAGE”.

There’s no getting around the fact that Forth is an unusual language. It’s not much like any more modern language (with the possible exception of PostScript) which can make it a struggle to get started. But that same strangeness is what makes it such a good platform to discuss the finer details of what makes good code and good application design.

Read this book. Think hard about it and reflect on what that shows you about your own code.

[Adam Tait · Rating 4 out of 5]

Unless you're already a Forth programmer (any still out there?), this one is an eye opener. The entire concept of Forth is different to any language that I've seen. It's all based on the stack; you write code to put values on the stack (literally the memory allocation stack) and take them off again. Variables are defined much less frequently as you stack up new data & results. It took me quite a while to wrap my head around this, and understand even simple Forth code.

My favorite sections were:
1. The limits of level thinking. Brodie talks about the arbitrary division of high & low level. Instead, Brodie & Moore (Forth's inventor) recommend a fun (or creative) first approach; do the parts you're most excited about to begin with.
2. Factoring criteria. Brodie presents a simple rubric for deciding how/when to factor code. In short, when you feel unsure about the code.
3. The entire chapter on minimizing control structures. I can't say that I'd thought about control structures directly as a code smell, but Brodie & Moore make a great case for it + describe tips for factoring if's out.

Also, the appendices were actually useful (I often skip the appendices).

Overall, if you're looking for a mind expanding programming book then I'd recommend Thinking Forth.

[Jennifer · Rating 4 out of 5]

Was a great resource in the college, the book have narrative with humor which makes easy follow the concepts, and the tips and techniques are timeless for sure!

[Andrei · Rating 4 out of 5]

Read it using Kindle. Will have to rertead it on paper, the Kindle version is too hard to read.

[Jake McCrary · Rating 4 out of 5]

Much of the wisdom found in this book is still applicable today. The book describes how to think in Forth and how you should approach problems with Forth. The advice is valid for solving problems with other languages as well.

Throughout the book there are tips found in little asides. The book would be worth reading if it only contained the tips.

[Jean Ventura · Rating 4 out of 5]

3.5/5.0 stars (wouldn't be fair to give it a 3.0 star rating). Excelent book but, half way through took a wrong turn into too much Forth specific details and implementation (My bad, it is called Thinking FORTH). None the less, the initial chapters (requirements gathering, analysis and design) are pure gold.

[Gert · Rating 4 out of 5]

Very good book, recommended to all programmers.

[Alex · Rating 2 out of 5]

Mostly general discussion on software development. Topics that today are considered common sense and in the 80's were very novel. The book only tangentially covers Forth.