Truth, Beauty, Machine Code

John Rose
I was struck by Roger Penrose's words in his recent book The Road to Reality, as he describes the difficulties physicists face in evaluating each other's mathematical accounts. It sounds like he knows the difficulties we software designers face:
...Mathematical coherence [let alone mathematical beauty] need not itself be readily appreciated. Those who have worked long and hard on some collection of mathematical ideas can be in a better position to appreciate the subtle and often unexpected unity that may lie within some particular scheme. Those who come to such a scheme from the outside, on the other hand, may view it more with bewilderment, and may find it hard to appreciate why such-and-such a property should have any particular merit, or why some thing in the theory should be regarded as more surprising--and, perhaps, therefore more beautiful--than others. Yet again, there may well be circumstances in which it is those from the outside who can better form objective judgements; for perhaps spending many years on a narrowly focused collection of mathematical problems arising within some particular approach results in distorted judgements!
(Road to Reality, page 1014f)

It may be enough, for some computer scientists reading that quote, just to substitute "Scheme" for "scheme".

Unlike physical models which are useless apart from experimental validation, software systems can manage and describe anything that people care about, whether it's material or not. But, given any particular goal, software designers face similar problems as physicists. They must effectively and robustly formulate the behavior of their systems. This requires formal systems of notation called computer languages ("code"), which have a strongly mathematical feel to them. And it is often not enough to hack together some code which gets the job done: The code must be correct, robust, and maintainable. (Correct obviously means free of defects, operating as advertised. Robust means trustworthy, solid, even when under stress. Maintainable means suitable for further modifications, scrutable to maintainers.)

To be correct, robust, and maintainable, software must communicate clearly and effectively, and not just with the machine it runs on. It must communicate with the programmers who are responsible for its continued use, and (through its user interface) with its customers. If there is a flaw in the code, the flaw should not be hidden by the code's murky depths, but should be apparent to the programmer; it should have nothing to hide. If the code's behavior is to be simple and trustworthy, the code itself should appear so. Complex code usually has complex quirks. Code should also be orderly, not leaving the reader guessing what comes next. It should be simple, saying one thing at a time, and saying it well.

What kind of code is communicative like this? Clear, simple, coherent, expressive code. In a word, beautiful code. So why don't we just require programmers always to write beautiful code? Or physicists always to choose beautiful theories? Sometimes because beauty is at odds with truth or utility, but more often the three travel together. That is where the mysteries begin, of the ideal versus the subjective, the universal versus the parochial or the arbitrary. Who is in charge, the language or the poet? Which should we follow, the angel or the siren, and which is which... or should be suspicious of any guide more handsome than ourselves? I salute Roger Penrose for attempting to pull such stubborn mysteries into the light.

A few more notes on the book: Driven by a weakness for audacious science popularization, I bought The Road to Reality: A Complete Guide to the Laws of the Universe by Roger Penrose. Eating dessert first, I found that the last chapter is a stimulating group of essays on physics and its future, and the second-to-last chapter could be a whole book in itself, on Penrose's favorite subject of twistors. It's a pleasing book to take off the shelf for a quick ramble on the heights, sort of a cross between an Encyclopedia of Mathematics and the Feynman Lectures (or Feynman's elementary talks in QED).

Dr. Penrose frames the whole account in a series of meditations on what he calls the "three deep mysteries". These meditations occur at the beginning and end of the book, and concern the pairwise correspondences between the worlds of matter, mentality, and mathematics. By avoiding a premature reduction to any one of those worlds, he has a better than average standpoint from which to view other mysteries, notably the connections between beauty and truth. He acknowledges that an esthetic sense, an appreciation for beauty, is often helpful to the physicist in search of mathematical models. This is true because mathematical beauty seems to be more than merely a matter of taste, or a subjective emotional response. What more? Nobody knows; it's hard enough to get a handle on what mathematical truth is. But we experience both truth and beauty every day.

In his discussions about the importance of notation, he tells some interesting stories about better notations which were beaten by worse. (The choice of good notation is a crucial problem for both mathematicians and programmers. The story of computer science is in part the story of one language replacing another over time, sometimes for better, sometimes for worse.) On page 1019, we find that Bruno Zumino used the "2 spinor" notation to publish an idea, only to find that a later publication of the some idea using the more complex but established "4 spinor" notation became the standard reference. Zumino's resolution for next time was, obviously, to publish using XML instead of Lisp. (Sorry, "4 spinors" instead of "2 spinors".) The saddest part is that "4 spinors" were introduced in 1928 by Dirac, the improved "2 spinors" just a year later 1929, and Dirac himself was using the improved notation by 1936. But the poorer notation was entrenched. Zumino's experience was decades later, in the 1970's!

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.