The Code of Beauty/ The Beauty of Code

def I():
    for i_am in infinite_dreams:
        print '... I make my own Reality ...'

Programmers with reasonable experience have one thing in common. The meek, shy, introverts and the bold, out-spoken, extroverts alike have a fairly strong opinion about coding styles - and this, as in my case, can sometimes be a lesson in humility.

Since not all languages have something like the PEP8 you sometimes have to suck-up and accept the most popular/prevalent coding style as the right one, no matter how strong you feel about your own style. For instance, I was fairly stubborn that the for loop has to be minimalistic with no unnecessary spaces -

for(int i=0; i<10; i++)

But, as this lovely article called The Great White Space Debate elaborates, I couldn’t have been more wrong. In essence, the most prevalent style is -

for (int i = 0; i < 10; i++)

The Beauty of Code #

$ python -c 'import this'

With a sufficient dose of humility and shame I reckoned it was time to dig deeper and listen to what the experts have to say about beauty-and-code. Geek Sublime, by Vikram Chandra and Beautiful Code, by Oram & Wilson helped me explore this.

What makes code beautiful? #

Yukihiro 'Matz' Matsumoto - Creator of Ruby

In "Treating code as an essay"

Judging the attributes of computer code is not simply a matter of aesthetics. Instead, computer programs are judged according to how well they execute their intended tasks. In other words, beautiful code is not an abstract virtue that exists independent of its programmers’ efforts. Rather, beautiful code is really meant to help the programmer be happy and productive. This is the metric I use to evaluate the beauty of a program.

No element by itself will ensure a beautiful program. When kept in mind from the very beginning, each element will work harmoniously with the others to create beautiful code.

Vikram Chandra, author Geek Sublime

So, beautiful code is lucid, easy to read and understand; its organization, its shape, its architecture reveals intent as much as its declarative syntax does. Each small part is coherent, singular in its purpose, and although all these small sections fit together like the pieces of a complex mosaic, they come apart easily when one element needs to be changed or replaced.

Why does code have to be beautiful? #

Don Knuth on Literate Programming

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other

…

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The Code of Beauty #

Writing beautiful code isn’t easy. Between work deadlines, family life, keeping up with latest technologies, languages and programming fads, and countless other things - it is difficult to care about, revisit, refactor and simplify Code that is produced in a hurry.

Vikram Chandra on 'reason for bad code'

Often, it is not the lack of programming skill that leads to the emergence of a Big Ball of Mud, but something akin to the time honored Indian practice of jugaad, a working improvisation that is built in the absence of resources and under pressure of time. In software, repeated applications of excessively frugal engineering by a series of programmers leads to a scheme that has no discernible structure, within which components use each other’s functionality promiscuously, so that the logic of the program becomes hard or impossible to follow. In a big ball of mud effects flow across boundaries, so that introducing a small change to one piece of code results in unpredictable behavior in distant parts of the system. Software needs maintenance: bugs need to be fixed, new features are demanded by users. If you are a programmer asked to go into the depths of a Big Ball of Mud, the prospect is terrifying. Introducing a new feature or fixing a bug may introduce another one somewhere else.

Hundreds of programmers may have worked of such a program over the years, each contributing a little to the mess. So you add your handful of mud to the Big Ball and you just back away carefully and leave that damn thing alone. There are some areas of code in running programs that may as well be marked Here Be Dragons.

But, the work of some of the best artists in the engineering world should motivate us to keep an eye for beauty, produce beautiful work and strive for beautiful code.

Vikram Chandra on Woz

Within the imagination of programmers, Woz is also a hard man, The Original Gangsta: he wired together his television set and a keyboard and a bunch of chips on a circuit board and so created the Apple-I computer. Then he realized he needed a programming language for the microprocessor he’d used, and none existed, so Woz - who had never taken a language-design class - read a couple of books, wrote a compiler and then wrote a programming language called integer BASIC in machine code. And he did this while holding down a full-time job at HP: ‘I designed two computers and cassette tape interfaces and printer interfaces and serial ports and I wrote a Basic and all this application software, I wrote demos, and I did all this moonlighting, all in a year.’

The second computer was the Apple-II, the machine that defined personal computing, that is on every list of the greatest computers ever made. Woz designed all the hardware and all the circuit boards and all the software that went into the Apple-II, while the other Steve spewed marketing talk at potential investors and customers over phone. Every piece and bit and byte of that computer was done by Woz, and not one bug has ever been found, not one bug in hardware, not one bug in the software. The circuit design of the Apple-II is widely considered to be astonishingly beautiful, as close to perfection as one can get in engineering.

Woz did both Hardware and Software. Woz created a programming language in machine code. Woz is Hardcore.

References from the Books #

Like any good book, these two leave you with a list of resources to follow up on -

Search Keywords - Literate Programming, SOAP (Symbolic Optimal Assembly Program), Functional Programming, International Obfuscated C contest

Books - The Elements of Programming Style - Kernighan & Plauger, Algorithims + Data Structures = Programs - Writh, Founders at work - Jessica Livingston, Coders at work - Peter Seibel

Websites - http://TheDailyWTF.com, http://blog.codinghorror.com

Languages - Clojure, brainfuck, Malbolge

Articles - Brown - “Stanford team turns DNA into a Hardrive”, Joshua Bloch - “Extra Extra - Read All About it: Nearly all binary searches and mergesorts are broken.”, Jonathan Oliver - Event Source - “Don’t store object state, instead store the events that have occured on the object. Recreate the object on the fly by fetching the list of events”

People: Radhika Santwanam, David Shulman

Acknowledgement: The title of this post are chapter names from the book Geek Sublime