Thinking Forth Tips

Everything old is new again. There are no new ideas. Modern software development is not so modern.

Here are some random tips (quoted verbatim) from the book ThinkingForth (published in 1984):

Start simple. Get it running. Learn what you're trying to do. Add complexity gradually, as needed to fit the requirements and constraints. Don't be afraid to restart from scratch.
Plan for change (by designing components that can be changed).
First, and most importantly, the conceptual model should describe the system's interfaces.
Factor the fruit. (Don't confuse apples with oranges).
You don't understand a problem until you can simplify it.
Decide on error and exception-handling early as part of defining the interface.
Generality usually involves complexity. Don't generalize your solution any more than will be required; instead, keep it changeable. (hmmm... YouArentGonnaNeedIt? -- Ed)
To simplify, take advantage of what's available.
The mean time for making a "two-hour" addition to an application is approximately 12 hours.
In deciding where to start designing, look for:
- areas where the most creativity is required (the areas where change is most likely)
- areas that give the most satisfying feedback (get the juices flowing)
- areas in which the approach decided upon will greatly affect other areas, or which will determine whether the stated problem can be solved at all
- things you should show the customer, for mutual understanding
- things you can show the investors, if necessary for the rent.

and that's just up to page 95 ;) -- ToddCoram

I seem to recall (although I can't begin to remember the page) another quote:

Don't set a flag, set the data.

The EwDijkstra page here attributes that one to him (Dijkstra).

I don't know whether Dijkstra said it first, but LeoBrodie did say that, on page 258 of ThinkingForth. He explains that, if you're just going to use a flag to choose between two data sources later, then just go ahead and save the correct value, rather than postponing the decision.

Similar tips follow:

DUP (copy) a flag, don't recreate it.
Don't set a flag, set the function (basically, save a function pointer).
Try to avoid altogether saving a flag in memory (save it on the parameter stack instead).

The advice is reasonable for any programming language, given his explanations. -- DougMerritt

This can also be seen as a primitive form of ReplaceConditionalWithPolymorphism, if you come from an OO background, or a more sophisticated form of ReplaceConditionalWithPolymorphism if you come from a functional background.

CategoryForth CategoryTips