Contributed Columns

The following rules for programmers were published 19 years ago. Enjoy this glimpse at The Way Things Were... and still are!

-Joe Horn-

Bill Kolb (265)

"PPC Journal," September 1979
Volume 6, Number 6, Page 19

The following is a collection of observations and general principles for programmers. It should remind us that Murphy's Laws apply to calculator enthusiasts as much as anyone. If you are an experienced programmer, you can probably testify to the truth of most; if you are a beginner, you may as well resign yourself. So before you rush out to buy the HP-41c or the HP-34c, you may want to meditate on the following.

  1. Fundamental Laws of Computer Arithmetic:

    1. A = A +/- something in the last place.
    2. A+B is not equal to B+A.
    3. AB is not equal to BA.
    4. A(B+C) is not equal to AB+AC.
    5. A^n is not equal to A times itself n times.
    6. Reversing an operation won't get you back.

  2. Computers do what you tell them to do, not what you want them to do. (Ingerman's Law)

  3. No one will have as high an opinion of your programs as you.

  4. No program is completely debugged.

  5. No program is fool-proof.

  6. The first person to use your program will find an error.

  7. No program works the first time. Be especially leery if you get the expected answer on the first run.

  8. When all else fails in debugging a program, explain it to a seven year old child.

  9. The longer it takes to debug a program, the more likely it will be recorded with the program switch on RUN.
    [That erased the program in RAM. -jkh-]

  10. Each half-hour of analysis saves two hours of programming and debugging.

  11. A program's usefulness is inversely proportional to the time spent on it. (Morgenstern's Law)

  12. It's far easier to write a new program than modify an old one.

  13. Any problem has more than one solution. Corollary: No two programs are alike.

  14. Ninety-five percent of the time is spent on five percent of the problem.

  15. Most problems with your calculator can be traced to not reading the manual.

  16. Manuals are useless when you have a problem.

  17. Variables don't, constants aren't. (Osborn's Law)

  18. An integer isn't.

  19. Variables will be known with greater accuracy than constants.

  20. Using more digits will make your answers more believable.

  21. Having a sophisticated calculator is no excuse for confusing the problem.
    EXAMPLE: 1+1
    Solution on a Four-Function Calculator:
    Solution on the HP-67:

  22. No calculator will have all the features you want.

  23. Useful features won't be convenient; the features you want won't be used.

  24. A fifty percent increase in memory doubles the capacity of a computer.

  25. There are at least two ways to save three steps in any program.

  26. You never have enough memory.

  27. Any program can be improved.

  28. A long run is more likely to crash at the end than at the beginning.
    [!!!!! -jkh-]

  29. When you want to use LASTx, the stack will be in the wrong order.

  30. Inside every large program is a small program struggling to get out. (Hoare's Law)

  31. Inside every large program is a small program struggling to defeat the purpose of the large program. (Joe's Law)

  32. You cannot successfully determine beforehand which side of the bread to butter. (Law of the Perversity of Automata)

  33. Basic Laws of Programming:

    1. Any given program, when running, is obsolete.
    2. Any given program costs more and takes longer.
    3. If a program is useful, it will have to be changed.
    4. If a program is useless, it will have to be documented.

  34. Everything should be as simple as possible, but no simpler.
    (An observation by Albert Einstein)

WM KOLB (265)

Part of the HP Calculator Archive -