Notes on “Thinking Forth”
I saw a mention of Thinking Forth
online sometime back, and downloaded it.
I finally got down to reading it this lazy Sunday afternoon,
and made some notes.
To quote from the homepage
Thinking Forth is a book about the philosophy of problem solving
and programming style, applied to the unique programming
What I feel after reading this book is that many concepts and tips
taught in the book can actually be applied to which ever
programming langugage you are using now.
Here are some general notes that I have made.
Component programming is about minimizing the impact of any change.
A component is a resource, which can be a piece of hardware or
a software resource (such as a queue or stack).
This idea is in contrast to Sequential or Hierachical Design.
An example was given by the author: updating a record.
However when designing by components, we think in terms of the
components which describe the structure of the records,
provide a set of editing commands, and provide read/write
methods to storage.
Thinking Forth talks about the Nine Phases of the Programming Cycle,
I took special note of the first two: discovering requirements and constraints,
and building a conceptual model of the solution.
To build a conceptual model, we can follow these steps:
1. Define interfaces
By using Data Flow Diagrams for example.
2. Define rules
By using English, Decision Tree, Tables. And subsequentlhy simplify
the rules so that it can be easily understood and coded
3. Define data structures.
This is a description of the structures’ conceptual model, i.e.
what attributes to keep.
These are general ways we can use to approach problem solving.
– Determine you goal
– Picture the problem as a whole
– Develop a plan (e.g. work backwards)
– Step back from the problem
I found Believe to be exceptionally inspiring.
To achieve success you first need to believe you can succeed.
As a pretty well-known quote goes
The 2 hardest things in Computer Science are naming things,
cache-invalidation, and off-by-one errors.
Thinking Forth gives some tips on naming things, though some
may actually be more relevant for the Forth language itself.
– Choose names according to “what”, not “how”
– Choose names that work in phrases
– Spell names in full
– Favour shorter words
I feel that naming is a balancing act.
On one hand you want the names to be expressive,
but you also want them to be concise.
For certain local variables, especially array indices,
it makes sense not to give them long names; you will be
typing them a lot, and they will not matter once you return
from the function, so naming them
i is fine.
For variables with a bigger scope,
data could mean a lot of different things.
Factoring is about organizing code into useful fragments
by separating reusable parts from non-reusable parts.
We can work to factor out:
– Code within Control Structures
After factoring, make sure that the factored code serves
a single purpose, if not the refactoring might just have
made things worse.
Minimizing Control Structures
The rationale behind this is that control structures introduce
complexity into the code, and makes it harder to read and maintain.
This rationale is clearly demonstrated in an example given by the
author, where there is a heptly-nested (6 levels)
The author suggests a few ways to minimize control structures:
– Do not test for something that has already executed
– Combine booleans of similar weight
– When conditions do not share similar weight, place conditions that
are easier to calculate, or least likely to be true on the outside.
– Choose control structures that closely matches the control-flow
I read through the book quite quickly, and skipped the parts which
I felt was about Forth, because I was more interested in the concepts
taught than the language.
However many concepts introduced
are based on what Forth provides, and how Forth works.
As such, I think that learning Forth while you are going through
this book will greatly increase the value gained from reading.
Nonetheless, I gained a lot of valuable insights from Thinking Forth,
all of which I shared above, which will definitely help me in being
a better programmer.
I would like to thank the author,
Leo Brodie, and
Thinking Forth Project, for
taking time time and effort to make the book available for free,
and in high-quality format.