Vikram Chandra’s Geek Sublime: The Beauty of Code, the Code of Beauty is an audaciously weird book. It seems to be in part:

• A meditation on the conflict between Hackers and Painters and Dabblers and Blowhards
• An explanation of the basic mechanisms of digital computers in terms of logic gates and booleans
• A sociological history of programming as a profession, especially with respect to the exclusion of women
• A memoir of author’s childhood in India and the writing of his first novel
• A reflection on the effect of colonialism on contemporary Indians
• An explanation of rasa theory in Anandavardhana and Abhinavagupta

It succeeds marvelously at several of these goals, and it mostly also succeeds at another goal:

• An attempt to sell to a Western audience a book written in a traditional Indian style instead of the contemporary Western style of introduction, thesis, support, conclusion

Of the different projects in the book, the explanation of rasa theory is surprisingly successful. In spite of taking classes with Eliot Duetsch, I never really felt like I had a good handle on rasa theory in graduate school. In Chandra’s telling, the rasa (“flavors”) of a work depend on the ability of the ideal observer to acheive psychic distance:

Rasa is what the drama produces in the sahrdaya, the sophisticated “same-hearted” connoisseur who is the playwright’s necessary counterpart. The sahrdaya—because of education, experience, and temperament—is able to experience rasa precisely because he or she does not identify in a personal, egoistic way with the tragedy on the stage. The naive spectator who ascribes some sort of reality to what is happening on the stage and identifies personally with the emotions of the characters is incapable of rasa, which is an impersonal, disinterested pleasure. One might say that a certain psychical distance is necessary for rasa to be experienced. Rasa is sublime.

…

This generalization, this trans-personalization, sadharanikarana, is the essential basis of the aesthetic experience. The framing of an object as art produces this necessary detachment from the limited ego. For a viewer, “the tasting of pleasures, pains, etc., inhering in his own [limited] person” prevents the relishing of rasa. The attachment to limited self prevents universalization; if you are grieving over your own long-lost mother, you are not relishing the rasa of the tragic death scene in the movie you are watching.

This explanation of aesthetic experience is basically compatible with the theory of disinterested enjoyment in my dissertation. I think the earlier problems I had with rasa theory were that there was so much emphasis placed on the flavors of experience that I felt it lost track of the importance of same-heartedness and psychic distance. Chandra’s account corrects this.

On the other hand, as an explanation of whether or not code can be beautiful or sublime, I feel like Chandra lets the topic slip away from him without fully committing himself to a position. At the risk of sacrificing the mélange approach that is clearly important to him, I feel that the book would have been better if he had returned to this initial question in a final chapter.

This seems to be the closest Chanrda comes to staking out his own position:

code is denotative, poetic language is centrally concerned with dhvani [resonance], that which is not spoken; the end purpose of code is to process and produce logic, and any feeling this code arouses in an immediate sense is a side effect, whereas poetic language is at its very inception concerned with affect.

I disagree with this. Code shares with architecture the property that it is also an instrumental good. A house that collapses is not well architected, nor is a computer program with bugs. However, the beauty of the Taj Mahal cannot be reduced to the fact that it is dry inside. Rather, it surely matters that the building resonates with the love of a grieving husband for his late wife. So how can code resonate?

The SICP says:

programs must be written for people to read, and only incidentally for machines to execute.

Dick Gabriel praised the Ancients, saying:

Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who’d have guessed sophistication bought such noise?

Linus Torvalds says,

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

When you approach a problem with the right data structure, the code itself becomes simple and straightforward. The complexity of the problem just becomes a matter of simple relationships between data elements, rather than a morass of if and else clauses. The whole thing unspools itself in the mind of the reader and the points of extension are clear.

Peter Bourgon writes in Beauty in code and programming languages:

1. Code should be, as a #1 priority, maintainable; which means that
2. I should be able to read and understand existing code quickly; which implies that
3. The language should provide unambiguous ways of doing things; or, conversely
4. The language should not allow programmers to do one thing in N ways.

There’s a long-lived philosophy in the open-source world that I’m slowly becoming aware of. There are programmers that view code as art, and accordingly apply art-like valuations to code: how many times have you heard about a “beautiful” function or implementation of so-and-so, or read some veneration of an obscure and difficult passage by Carmack? Before I became a professional programmer I sat on the sidelines of these discussions in more-or-less agreement. I believed, or wanted to believe, that what I was doing was no less expressive than turning stone to statues.

I’m sitting here watching the late-afternoon sun kiss the flowers on the trees and thinking to myself how silly this idea that code is artful has become to me. What I believe now is that code is not beautiful when it is compact, obscure, or the belabored output of a capable mind iterating over the same idea until it is optimized beyond studied comprehension. Beauty is what makes me happy & satisfied; beautiful code is straightforward code, that I can read and understand, that I can maintain a mental model of, and manipulate, and more than anything else maintain through its useful life. Beautiful code behaves as code’s Platonic ideal: to be read by humans, and only incidentally by machines.

Beautiful code just is maintainable code. Maintainable code is maintainable just when the sophisticated “same-hearted” connoisseur can easily pick it up and continue where the Ancients left off.

It’s true that there is also a kind of beauty to a finely tuned algorithm where no instruction can be added or removed, but that kind of beauty is rare in professional programming.

Geek Sublime is an incredible book. I’m glad that someone was able to publish such a gloriously niche work for mainstream audiences.