Jon Bentley likes to pare things down to their functional core. Best known for his Programming Pearls books and columns, Bentley delights in elegant solutions to complex problems―
Then there’s what Bentley calls his “real biography,” which includes an extensive outdoor life. Bentley has compiled a long list of hikes and climbing expeditions on both sides of the United States. In 2004, just below the summit of Mount Cayambe in Ecuador at about 5700 meters above sea level, he contracted high-altitude cerebral edema. These days, he tends to hike a bit lower. As we emailed ahead of our conversation, Bentley and I exchanged pictures of our backpacking trips last summer. As it turned out, we had been at the same lake about a week apart in the east side of California’s Sierra Nevada mountains. He also sent me a spreadsheet of his backpack contents, where he has pared his backpack down to the weight of a couple of laptops. As an aspiring minimalist backpacker, I see I still have work to do.
Bentley has thought about returning to teaching at the end of his career. His dream course: a freshman seminar on minimalism in software, writing and hiking. Those three passions can be seen in his contribution to the Japanese version of the book Beautiful Code: Leading Programmers Explain How They Think. Bentley wrote that programs can have three kinds of beauty. “One kind of beauty is that of strong, robust, industrial-strength programs that withstand many users and decades of maintenance. We know such beauty from other fields. One can see this kind of beauty in the poetry of Rudyard Kipling, as iambic stanzas gallop along for page after page. As a climber, I have seen this beauty looking up at the majestic rock wall of El Capitan in Yosemite Valley. In architecture, one sees such beauty in fortifications such as Himeji Castle in Hyogo Prefecture.
“I chose, instead, to write of a different kind of beauty: the beauty of minimalism, of graceful elegance. Japan has taught the world much about such beauty, in the poetry of haiku, in the graceful form of Fuji-San (majestic yet perfectly proportioned), and in architecture in classic homes that are delicate yet effective.”
Bentley added a haiku of his own:
“Beautiful programs
Small, fast, lean yet powerful
What a joy to code!”
- What is minimalism in programming?
For me, it’s an ideal. I worked for a number of years in the Computing Science Research Center at Bell Labs, the group that created UNIX. That system exemplifies minimalism. It’s an industrial-strength operating system with an elegant yet powerful design that emphasizes simplicity. UNIX was has come further than its designers would have ever expected. It’s still very much alive in the Apple Mac, for instance, not to mention in most of the servers behind the Internet. UNIX exemplifies Einstein’s famous advice: “Make everything as simple as possible but no simpler.”
But not every software project at Bell Labs embodied that kind of simplicity―or should. I worked for year on 5ESS, a software project involving about 5,000 people to build a telephone switch with stringent reliability requirements: about two hours of downtime every 40 years. To achieve that reliability meant that the software was incredibly over-engineered, but with good reason. So I appreciate that you have to make things big sometimes. But even so, you should still make them as small and as beautiful as possible.
- And then there’
s Ludwig Mies van der Rohe’ s guide for architects: “Less is more.” I was surprised to find that the phrase came from a 19th century poem by Robert Browning.
- You mentioned UNIX. Have you been following Google’
s Chrome OS development? Google says it will be a new Windowing system built atop the Linux kernel. The implication is that Chrome OS is the answer to the massive code that is Microsoft Windows. My understanding of Google Chrome and Google Chrome OS is only at the comic book level. But at that level, Google seems to be taking an interesting and powerful approach to an important problem. I wouldn't bet against Google on this one.
- But with the acceleration of computing power and resources cheap, software doesn’
t necessarily have to be so simple. What’ s the value of simplicity now? One big reason is code portability. For the past couple of months, for example, I’ve been working on a new sort function for the Java Development Kit. I’m working with Joshua Bloch, an old friend from Carnegie Melon, who is now the chief Java architect at Google, and with Vladimir Iaroslavski of Sun. For a long time, the sorting program to beat was one that I wrote with Doug McIlroy in the early 1990s. Well, these guys have beaten our old code, and I’ve been working with them on an industrial-strength implementation. We’re trying to make something that will run on a wide variety of machines. So on the one hand, you’re right that memory is free and many machines are fast. On the other hand, though, we have to write code that is efficient across a wide variety of machines―and a lot of machines are very small, so resources still matter.
Another advantage is that if things are small, you have a better grasp of understanding them, fewer bugs in the field, and fewer problems later on. I’m a big fan of simplicity both for performance and for intellectual manageability.
- It’
s intriguing that you have carried this through to your outdoor life. How has this turned into a personal philosophy that goes beyond code? For me, Einstein’s famous dictum works here, as well: make everything as simple as possible, but no simpler. When I went up Mt. Rainier in Washington State, I carried a 30-kilogram backpack―and I really needed every piece of that gear. But when I went into the Sierra this summer, I calculated what I needed, what I could leave behind, and what the tradeoffs were. I could have gone with a three kilogram backpack but I went instead with a luxurious five kilogram backpack just because I wanted to be comfortable. Of course you can take this to an extreme. My goal is to keep being able to do this―to backpack even though I’m no longer a teenager. My buddy and I have been hiking and climbing together for about a decade now. We want to travel light and fast, but we still want to have fun.
Here’s another example. I’m a volunteer emergency medical technician―and I have a pair of dark blue trousers with about 10 pockets. In those pockets are several pairs of gloves, a little splint, an aluminized Mylar emergency blanket, vacuum-packed bandages and other well-selected items. People jokingly refer to them as my “ambupants”
― because it’s as if I’m carrying the contents of a little ambulance in my trousers. My aim is to be absolutely prepared in an emergency, but still be comfortable by making everything as light as possible, This is a tradeoff I see in all areas of life. You want to be able to solve the problems that you face, but carry as little baggage as you need to do it. I think that’s an effective way to live life. It’s the same thing that you can certainly take to an extreme.
- You say that Japanese aesthetics reflect this idea as well.
Absolutely. I’m a big fan of haiku as poetry. One of my PhD students, Cathy McGeoch, has the website hockeyhaiku.
com that she first put up when her sons were playing the game. [An example: “Speeding wheels roll/ I'm just waiting for/ ice to freeze.” ] It’s amazing how expressive haiku can be. And likewise, there are times when you have to have castles with huge stone walls, and Japan has its share of those. On the other hand, they also know how to live in houses with paper walls. - When I spoke with Brian Kernighan, he was at a quandary about what to teach his students: simple code that they can understand, or code with large libraries that are much more sophisticated, but almost impossible to grasp.
You have to do both. That’s the reality that developers face. Having an intellectual grasp is important, but we also have to strive to make things better―which sometimes means making things more complex. You have to know both ways of working, and sometimes you can do both. I’ve been consulting on some big Avaya projects, where some performance bugs were making the system unbearably slow. But when we distilled the problem to its essence, the problem might amount to a seven-line piece of code. That’s a point where the two sides meet. Even though the system is complex, you have to boil the problem down to its essence.
- Do you think most development has gotten too big for its own good?
Complexity is a fact of life in the world in general, and certainly in my field, telecommunications. At Avaya, we have systems that offer a thousand different options, because our customers want them. But these features can often interact in subtle, unpredictable ways. You may experience something comparable on your cell phone. What happens when you get an incoming call while you’re making an outgoing call? How are those two functions supposed to work when they happen at the same time? Of course, these are sometimes the most interesting problems to solve. Problems become deep and interesting when they have a long time in which to grow.
- Is simplicity best achieved by paring down?
Absolutely. The French aircraft designer and pilot―Antoine de Saint-Exupery―said that a designer knows he has achieved perfection not when there is something left to add, but when there is nothing left to take away. That’s a good approach to programming. First you code, then you make it beautiful later, when you have time. . How can I make this code cleaner? How can I shrink this 300 word paragraph down to 50 words? How can I make my backpack lighter?
Of course, having the time to do that is a real luxury. Journalists have deadlines. So do programmers. Maybe you can only do this when nobody’s watching the clock; when you are doing an activity strictly for the love of it. I just gave myself the luxury of spending an entire weekend writing C code. I started with a program that contained about 800 lines of complex code. I tore it apart, and tried to put it together again more elegantly. At the end of the exercise, the program was more powerful yet was only about 80 percent as long. I had achieved my dream as a programmer: I added function by deleting code. Inside every fat program is a skinny program struggling to get out.