Euclid Alone
I find it interesting that I learned more about clear technical writing from a math class I took in 1977 than from all of the English classes I ever took combined. Dr. Douglas Campbell not only taught Lebesgue Measure and Integration in BYU’s Math 641; he taught and demanded succinct, to-the-point exposition. I recall an assignment where I had fallen back on low-level, undergraduate techniques to solve a particular problem. Dr. Campbell handed it back with this message: “Yes, technically you’ve ‘solved’ the problem, but you have not used the power of the Dominated Convergence Theorem. Do it over, and in less than half the space.” It was not acceptable to just “get by”; we were expected to use all the high-level abstractions available to us to solve problems in the simplest way possible.
At about the same time, a couple of distinguished gentlemen from AT&T wrote a book on how to write good programs [1]. In those days, developers tended to spend more time reviewing hard copies than using terminals and would mark up their code with red pencils, rather than use a software tool, such as an intelligent editor or pattern-matcher, to find text and make changes. Note this excerpt from the text: “Far too many programmers are red pencillers. Some are literal red pencillers who do things by hand that should be done by machine. Others are figurative red pencillers whose use of the machine is so clumsy and awkward that it might as well be manual.”
A year or so later another book [2] from some AT&T folks introduced a language named, tersely enough, “C,” described as “a general-purpose programming language, which features economy of expression, modern control flow and data structures, and a rich set of operators... its absence of restrictions and its generality make it more convenient and effective for many tasks than supposedly more powerful languages.” Talk about an understatement.
Nowadays programmers routinely use software libraries and hide new complexity inside new abstractions. Or do they? Do they use all the power available to them, or are they “red pencillers?” Do they employ “economy of expression” or do they just churn out code and think later? Does it even matter?
It matters. In 1990 I joined a project that attempted to “reuse” some C code that was written by data processing “veterans” who didn’t bother to learn anything from the standard library beyond getc() and printf(). Not only was it unfit for reuse, it was barely fit for “use” and thoroughly unreadable. When a consultant was brought on board to help us out, he took all of three minutes to conclude, “I’m sorry, I just can’t work with this code.” As an exercise I rewrote one (multi-page) function from that code using my knowledge of the library. It came out one-seventh the original size and an order of magnitude more readable (at least).
A scientific description of “good code” may elude us, but it leaves the experienced programmer with that “good feeling” [3]. The terms simplicity, clarity, and generality have recently been used to describe it [4]. Consider the now-trite “word count” program that uses a map data structure to keep track of the number of instances of each word in a document. In Java, a language not known for its economy of expression, you’ll need code something like the following to process a word:
if (!myMap.containsKey(key)) myMap.put(key, new Integer(1)); else { Integer count = (Integer) myMap.get(key); int icount = count.intValue(); myMap.put(key, new Integer(++icount)); }whereas in C++ it is simply:
myMap[key]++;More expressive power begets higher-level programming, which in turn leads to elegant, readable code.
Perhaps it was the power of uncluttered logical expression that caused Edna St. Vincent Millay to claim that the mathematician “Euclid alone has looked on Beauty bare.” Elegance matters because it addresses the human side of programming. Code that comes out clean, that traffics in well-defined abstractions without repeating low-level details, and that communicates with programmers as well as the machine is code that is likely to serve its purpose throughout a long and healthy life. Such well-tended software also saves time and money over the proverbial Long Haul. Let’s not leave Euclid lonely.
Chuck Allison
[1] Kernighan and Plauger. Software Tools (Addison-Wesley, 1976).
[2] Kernighan and Ritchie. The C Programming Language (Addison-Wesley, 1978).
[3] Or if you prefer, the “quality without a name.” See Alexander’s A Timeless Way of Building (Oxford University Press, 1979).
[4] Kernighan and Pike. The Practice of Programming (Addison-Wesley, 1999).