Forth Methodology Applied to Programming:

1. BEGIN BEGIN BEGIN Identify and reject your illusions and ideas that don't help. 2. Identify and reject the non-problems blocking your problem or keep them but trick them into helping solve the real problem. 3. First consider the options that everyone else would reject first, that is where the biggest algorithmic improvement is likely to be found. 3. Carefully construct a well thought out solution. 4. Optimize that solution design as far as it can go in that direction. 5. Identify and reject the illusion that starting over is bad and you are ready to code. Return to 1. with a greater understanding of the issues UNTIL you collect all the good solutions that you can imagine. 6. Compare solutions. Construct experiments, benchmarks, simulations or whatever you need to confirm that you found the optimal approach to the problem. 7. Continue to return to 1. UNTIL the ideas are "right by design." 8. After making the problem look brutally simple by doing the factoring factoring factoring before coding approach the trival programming task of constructing a one-to-one image of the optimal solution in code. 9. Code. Build custom tools if they help. Write code so simple and clear that bugs simply can't happen. Make the code "right by design." :define using one-liners about this long ; Interactively test each Forth word. Extend the core language making your custom language and moving you toward your solution. Return to 1. UNTIL the code solution falls out. 10. Write documentation so simple and clear that bugs simply can't happen. Document the "right by design" algorithms and code. Create a glossary with a description of each word. Have fun at all times. Enjoy the satisfaction of a job well done. -------------------------------------------- If you do this right the easiest step is 9. If you start at 9 you understand 1% of this methodology. This methodology, framing a programming task here, can be applied to designing hardware, it has, or to any type of problem. The inventor of Forth, Charles Moore, says that his language was designed to "avoid" the "unsolveable" problems in computer science. He says that the "real" problem is the problem that you want to solve. Adding unsolvable problems to the real problem is really your problem. On each iteration you understand the problem better, each time you go through the loop, you find remaining places for new optimization. After you found and removed the last bottleneck you find the next largest bottleneck in each sucessive iteration. Mr. Moore repeated steps 1-10 on software for 20 years. He declared that the programming problem had been solved. The remaining problem was hardware. Mr. Moore studied the problem and constructed his own new tools. Mr. Moore repeated steps 1-10 on hardware/software for another 20 years. Computers are hardware/software and Mr. Moore has been getting closer. He used step by step iterative changes. He said that he made a couple of wrong turns on a couple of landings and had to go back to find the up staircase again. Learn to recognize when you have left the up staircase. I admire him for all the times when he told us that he had been wrong in an approach or in a conlusion, that he had taken the wrong path before or told us something that was not true. I see a lot of people taking a leap, or climbing up the vertical wall. I tell them that there are stairs and that it is a longer, but easier and better path. But some people will get stuck trying to go up the down escalator. Consider using the up stairway. If you find an up escalator somewhere please let us all know! Jeff Fox 12/09/01