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 Thinking Forth (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... You Arent Gonna Need It? -- 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 ;)


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

Don't set a flag, set the data.

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

I don't know whether Dijkstra said it first, but Leo Brodie did say that, on page 258 of Thinking Forth. 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. -- Doug Merritt

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


See original on c2.com