When Ludwig Boltzmann (physicist, 1844–1906) was criticized for his ugly brute-force calculations, his defence was: “Elegance should be the concern of shoemakers and tailors”. The criticism was of course not about elegance in the sense of fashion. It was about the fact that an elegant structure would have had the power to convince the reader of whatever the calculations were intended to demonstrate.

I think this episode has something to do with the fact that much of what we do on computers depends on software that, among other weaknesses, is in need of frequent and urgent “security updates”. Those who criticize this state of affairs are dismissed as unrealistic. To be realistic is to understand that any useful piece of software consists of millions of lines of code written by many programmers, mostly no longer traceable and certainly not accountable. No one has a clear view of the system as a whole; there is no description that enables anyone to gain such a view. The realists of today, who accept this state of affairs as inevitable, are of Boltzmann’s brood.

For Boltzmann, elegance was a frivolous side issue. Not so for Edsger Dijkstra (programmer, 1930–2002):

Elegance is not a dispensable luxury, but a factor that decides between success and failure.

Here he is referring to software. But Dijkstra also said:

The traditional mathematician recognizes and appreciates mathematical elegance when he sees it. I propose to go one step further, and to consider elegance an essential ingredient of mathematics: if it is clumsy, it is not mathematics.

Now he’s talking about mathematics. What does that have to do with software? The plot thickens further when look at the title, “Beauty is Our Business”, of the volume published on Dijkstra’s sixtieth birthday; I assume the title met with his approval. So there you have it: elegance is supposedly beauty and the criteria for good mathematics are supposed to be applicable to software.

The reason I am skeptical about identifying elegance and beauty is “The Phenomenology of Mathematical Beauty” [1] by Gian-Carlo Rota (mathematician, 1932–1999). The reason I pay attention to Rota is that he *was* a mathematician.

What Rota says contradicts Dijkstra’s claim “… if it is clumsy, then it is not mathematics”. Rota points out that the business of mathematicians is to solve open problems. Of course, they also discover problems and invent new theories. The latter two activities are relatively rare. Most of what mathematicians do is to chip away at the open problems.

Rota reports that when a well-known conjecture is settled, that first proof is typically ugly and clumsy. Yet it is this author that gets the credit. In mathematics it is the newly gained knowledge that counts. The reason Rota wrote “Phenomenology” is to report what mathematicians *do*, and this is worth noting because it is surprising if one listens to what they say. Rota notes that mathematicians *talk* a lot about beauty; Dijkstra wasn’t totally out to lunch when he noticed the talk, which is easy to understand for an outsider, and failed to notice the discrepancy with the deeds, which are not so easy to understand.

The talk by mathematicians about beauty is not entirely vacuous. Mathematicians are not satisfied with the clumsy first proof of the conjecture. They wrestle with it in attempts to clean it up. This is not in quest of beauty or elegance, but it is an attempt to *understand*. Success in this secondary activity also gets recognition, but it is a consolation prize. The big prize goes to who got there first. Mathematics gets by pretty well with beauty and elegance in a secondary role. It does not seem to happen that the conjecture settled by the messy proof turns out to be false.

Mathematicians are interested in (their specialty of) mathematics, not in beauty. Another way in which Rota illustrates this is in the following quote.

Attempts have been made to string together beautiful mathematical results and to present them in books bearing such attractive titles as

One Hundred Most Beautiful Theorems of Mathematics.Such anthologies are seldom found on a mathematician’s bookshelf. ([1], page 130).

Such an anthology would have been a nice birthday present for Dijkstra, witness his EWD538 “Collection of Beautiful Proofs” in [2].

I think we lose something when we equate beauty and elegance, as Dijkstra seems to have done. Something is either beautiful or not, for a particular observer at a particular time. Elegance is relative: it comes to mind when we compare a cleaned-up version with a messy earlier attempt. It seems to me that Rota would have done better if he would have made the distinction.

As Rota shows, Dijkstra was wrong when he claimed that if something is not beautiful, it is not mathematics. Rota shows that mathematical proofs serve their purpose, whether elegant or not. From a mathematical point of view elegance does not matter. If Dijkstra is right in claiming that in software elegance does matter, then he proves himself wrong in claiming that programming is like mathematics.

It is not so that software people agree with Dijkstra in church on Sunday that elegance is the overriding constraint but during weekdays continue building out and patching the messy legacy software. No, they actually have a spokesman, Frederick P. Brooks (born 1931), who proclaims

Complexity is the irreducible essence of software.[3].

So there: don’t even try to look for elegant designs. With hundreds of approving citations, Brooks is the voice of Boltzmann’s Brood.

Being warned that this is only of interest to a small fraction of the software community, I will nevertheless try to understand what the role of elegance can be in software. For starters, Richard O’Keefe (born 1955) has said it better [4] than Dijkstra:

Elegance Is Not Optional.

He explains:

There is no tension between writing an elegant program and writing an efficient program. If your code is ugly, the chances are that you either don’t understand your problem or you don’t understand your programming language, and in neither case does your code stand much chance of being efficient. In order to ensure that your program is efficient, you need to know what it is doing, and if your code is ugly, you will find it hard to analyse.

Is there anything one can say in addition to “Thou shalt only code to elegant designs”? In 1992 Peter Reintjes floated the intriguing notion of “Elegant *Technologies*” [5]. These were CMOS, Unix, and Prolog. By now these names don’t create a great deal of excitement. That by now we don’t notice CMOS and Unix as anything special is the phenomenon of fishes not noticing that they are in water. The case of Prolog is dealt with elsewhere [6].

So far we only considered designs as candidates for elegance. The paper by Reintjes suggests considering also technologies, presumably because they can make it easier to produce elegant designs. The choice of programming language can make a bigger difference for the success of a software project than a fancy espresso machine or Herman Miller chairs. Whatever the merits, and even charms, of C, it should be kept in mind that for many applications this language makes it hard to produce an elegant design.

An intriguing exception to business as usual is Jane Street Capital. According to their website at the time of writing

Technology is at the core of our business, and software development is integrated into everything we do. Learn how functional programming sets Jane Street apart.

Other materials suggest that they only consider hiring people expert in languages like CAML or Haskell. A kind reader suggested mentioning also Tsuru Capital. “Tsuru Capital is a proprietary trading fund. We believe in using well written software to design and execute efficient trading strategies in financial markets.” In the next paragraph: “We use the Haskell programming language almost exclusively since we believe it gives the best combination of high-level cleanliness, execution safety and high performance.”

Do we see a pattern here?

Though it is easy to dismiss someone who blithely interchanges elegance and beauty, programming and mathematics, I think Dijkstra was on to something. An examination of what mathematicians do will show that it is not what programmers do, even in the most utopian state dreamed of by Dijkstra.

It is not so easy to disentangle elegance and beauty. My guess is that, when people use these terms, they mean that a system, however complex, can be decomposed in a simple way into subsytems that, though they may themselves be complex, are less complex. And, moreover, that each of these subsystems is amenable to the same treatment.

The success of such a decomposition depends on associating the subsystems with the right concepts. “Conceptual Integrity” may be a more fruitful description of what we are after than “elegance” or “beauty”. Brooks, that voice of Boltzmann’s Brood, recognizes its importance. It is to him that I leave the last word [7]:

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

and

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.

#### References

[1] * Indiscrete Thoughts * by Gian-Carlo Rota. Edited by Fabrizio Palombi. MIT Press, 1996.

[2] * Selected Writings on Computing: A Personal Perspective * by Edsger W. Dijkstra. Springer-Verlag, 1982.

[3] “No Silver Bullet—Essence and Accidents of Software Engineering” by F.P. Brooks, Jr. *Computer* Vol. 20, No. 4 (April 1987) pp. 10-19.

[4] * The Craft of Prolog * by Richard O’Keefe. MIT Press, 1990.

[5] “Elegant Technologies” by Peter Reintjes, 1992 (Zimmerman).

[6] Who Killed Prolog? and The Fatal Choice

[7] * The Mythical Man-Month * by F.P. Brooks, Jr. Addison-Wesley, 2nd ed. 1995.

PS(0)

In reply to Peter’s comment: Summary of a recent briefing by someone who works in the anti-virus industry. Hackers can do what they like in two ways. One: an existing virus is trivially modified into one that is not detected by anti-virus software that detects the original. Thus a hacker successfully attacks during the few days that it takes for the anti-virus software to be updated. Two: Widely used software, like Internet explorer or Adobe Acrobat has so many bugs that there is plenty of opportunity for a hacker to develop a new family of viruses. The speaker spent the next twenty minutes demonstrating the creation of a virus from scratch.

Expert’s conclusion: the only defence is error-free code.

PS(1)

I recently unearthed yet another paper by Dijkstra (“Computing Science: Achievements and Challenges”, ACM SigAPP Applied Computing Review 7(2), pp 2-9, 1999). Here he refers to the Oxford English Dictionary for the meaning of “elegance”. It turns out that there are eight meanings. Dijkstra’s intended meaning appears as number 5a: “Of scientific processes, contrivances, etc.: ‘Neat’, pleasing by ingenious simplicity and effectiveness.” But the OED accommodates Boltzmann as well, in meaning number 1: “Tastefully ornate in attire; sometimes in unfavourable sense: Dainty, foppish.” This is also the meaning used by Bernard Shaw: “She wears a very elegant hat, with a dead bird in it.”

March 8, 2014 at 12:44 pm |

Thanks so much Maarten for yet another tremendous essay!

March 25, 2014 at 7:54 am |

One of the most successful financial systems I know of (and worked developing it) is several millions of C++ lines in a huge mess. All original programmers left long ago, nobody can describe parts of the mechanisms. Ugly to the extreme, it would make Dijkstra wince, if not have a fit on the spot. And yet it is fast, precise, works like a charm, and became a standard in banking.