A recent blog post by Josh Ledgard reminded me of a book that had a great influence in my early programming days. The books was Programming Proverbs by Henry Ledgard and I still have my copy. It's one of the few computer books I bought in the mid 1970's that still has some relevance. The code examples are in ALGOL, FORTRAN and BASIC but the ideas apply to most all programming languages. Dr. Ledgard also wrote related books specifically for C, COBOL (I have that one), FORTRAN (I used to have that one but I can't find it) and PASCAL. It was quite the series.
I've been re-reading the book since last week and I am thinking about writing a series of posts about each proverb. I'm interested in seeing some discussion about how each one holds up over time. The book is over 30 years old and there is a lot we have learned about programming in that time. Or is there? Other than Object Oriented Programming what's new? Are programs today less buggy than they were thirty years ago? Actually I think they are worse many times. Perhaps we should bring more of these proverbs to people's attention? Of course many of them are being brought up but are people really paying attention? Let's discuss it.
What is the list you ask? Well here it is.
What do you think of this list? Anything you would add or drop?
Walking On Water and Writing a Software is easy, if the Water and Specifications are FROZEN
1. Explicit is better then implicit
2. Practicality beats purity
3. Readability counts
4. When in doubt, use brute force
5. Simplicity, Clarity, Generality form the bedrock of good software
Write automated tests.
Number 3: It's interesting to note that IntelliSense encourages a bottom-up approach. See http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
Number 21: This was all the rage when programs took 10 minutes to compile. It's still a good idea for discipline but probably far less important.
Number 13: Any compiler worth its salt is going to optimize these out.
Numbers 25 and 26: Impractical in most cases.
The most interesting thing about what has happened in CS over the past quarter century is that Fred Brooks' 1-3-9 rule is now completely inverted. He said that it costs nine times as much to make a general, interoperable system than an ad hoc one. Now, it is far more costly to make an ad hoc system than a general, interoperable one. This is mostly due to standards, such as XML, HTML, Soap, Unicode, the DOM (especially in .Net 2.0), XSLT, XPath, etc.
Interesting comment about IntelliSense encouraging a bottom-up approach. I think that is true if you start with programming and not with design. What I mean by that is that some people create their design in code rather than working out the full design before starting to code. I think that if you create a design using a top down approach it takes longer to get to the building blocks. that is frustrating to many, especially students, but in the long run results in a much better design.
With a complete design in place one does know what the little blocks of code will be at least from the standpoint of names and interfaces. Creating those little blocks early on in the programming is fine as long as the design is complete.
When ever programming teachers get together one of the debates that often starts up is between using
In some ways I think this is one of those proverbs that was more important back in the days when batch
This proverb is a corollary to the last post in this series . While getting the program correct and the
I've been telling students and others that " reading the manual is the shortcut " for years
What's that old line about if all you have is a hammer all your problems look like nails? There are
The statement "Don't be afraid to start over" seems obvious to the breed of programmer