The Beauty of Software

And what is done, and what is not done?


“And what is good, Phaedrus, and what is not good? Need we ask anyone to tell us these things?” Robert Pirsig, Zen and the Art of Motorcycle Maintenance

I am going to diverge a little bit from the “simplicity” theme of this blog and talk about how I know when I have completed writing some code. In short, the code appears beautiful to me when it is complete. How then, to describe my experience of beauty to you?

Let me point in the rough direction of what I mean by “beauty”. It is sort of like Quality, a very high degree of excellence in something. It is sort of like the Greek Arete, here meaning “excellence of any kind”. It is sort of like your experience when you see a work of art that touches you, or a landscape vista that momentarily overwhelms you with beauty. You yourself know when you experience something beautiful, and yet somehow it is difficult to describe that beauty.

I can, however, point to aspects of the beauty I see in software code when it is complete. These aspects are not the experience, of course, they are more like distorted shadows cast by the experienced beauty.

Several aspects are related to the anticipated experience of the next person to work with my code. Am I being as kindly as possible to the next developer? Is the code flow laid out in such a way that is will make sense to the next developer? Is the code commented and documented in a meaningful yet terse manner? Are there unit tests with nearly 100% coverage of the code? In short, would I feel revulsion or gratitude if this code landed on my head? There’s a saying in programming that captures a mindset I find useful: “Code as if whoever maintains your code is a violent psychopath who knows where you live.”

Other aspects of software “beauty”. Is there anything missing, the presence of which would make a difference? Is there any “fat” or cruft in the software that is really not necessary? Did I follow the Don’t Repeat Yourself principle? Did I create orthogonal software where algorithms/functions/operations are independent with clean, well-defined contractual boundaries?

Good heavens, as I write this, I see the list of aspects of software beauty could go on nearly forever. Let me stop there and simply say that I know that I am done with a bit of software code when I look over the code and feel a visceral “click” telling me this code is indeed complete.

Programming: Managing Two Point Six Billion Switches

Part the First: The fabric of a microprocessor.

There exists this lovely huge menagerie called “programming”. This thing covers an unspeakably large multitude of concepts, like languages, compilers, interpreters, how a geek understands a program, how a computer understands a program, performance, parallelism and on and on and on. I am probably not aware of all of the things that are a part of “programming”. I sense I may be certifiably nuts to even attempt to cover All Of It, and so what? It’s a worthy goal.

Glinda the Good Witch says she has always found it best to start at the beginning. Excellent advice. Let’s start with the transistors in a microprocessor and relate transistors to the binary machine language of ones and zeroes that microprocessors can execute.

A transistor is simply an on/off switch. Much smaller than your dining room light on/off switch, to be sure, but it does the same thing. Switch on, light on; switch off, light off. Starts off deceptively easy, eh?

The Intel 8-core Core i7 Haswell-E (translates loosely as “8 microprocessors lumped together into one gynormous, powerful microprocessor”) has 2.6 billion transistors. No worries, I can’t count that high, either. Let’s build up to that number. Let’s say you have a house with 26 switches controlling lights. All of the lights are independent – each light is controlled by its very own switch, so each of the 26 lights may be on or off. Given the distinct on or off state of each light, your house with 26 switches gives you 671,088,664 unique combinations of your 26 lights. Each unique combination could be assigned a meaning. For example, all 13 upstairs lights could be on and all 13 downstairs lights could be off. You could say this means “everyone is going to bed right now.” You could extend your possible combinations of lights with 99 very friendly neighbors, each of their houses having 26 independently controlled lights. Now we’re up to 2,600 light switches (26 in each of 100 houses) or far too many combinations of light switches to count. If you added  one million more really friendly neighbors, each of their houses having 26 independently controlled lights, you’re up to 2.6 billion light switches. A rather unmanageable number of unique combinations, to be sure.

Because they’re human, microprocessor designers don’t deal with all 2.6 billion transistors in a lump. They break these up into groups of functional blocks of transistors and assign meanings to the on/off transistor state of each individual functional block. A block might be an arithmetic unit, a memory cache or three, a memory management unit, an instruction processing unit, and so on. It’s the last one, the instruction processing unit, that relates most directly to programming. Remember programming? This is a blog entry about programming.

A geek readable program is made of english-ish instructions. These instructions get translated into a binary machine instruction language of ones and zeroes. The instructions are made up of, let’s say, 64 ones and zeroes. The instruction processing unit transistors get each set of 64 ones and zeroes, which turns each of 64 instruction processing unit transistors on or off. Like your house, each combination of on/off transistors means something. For example “0100010101000101010001010100010101000101010001010100010101000101” might mean “get data from there, add it to data gotten from here and cough up the result, buster”. In reality, those 64 on or off instruction processing unit transistors turn another set of transistors on or off and so on and so forth until the addition actually happens in the arithmetic unit. Details, details.

Ok, that was a lot of stuff. Let’s end this part of programming with:  computer programs somehow get translated into machine binary language. The machine binary language (ones and zeroes turn microprocessor transistors on or off in a combination that (hopefully) makes the microprocessor do what I want it to do.

Left Brain vs. Right Brain Programming?

Serial and parallel programming style.

Until the past decade or so, most software programming was serial. That is, the code was meant to execute one statement at a time. That was fine, serial code performance kept increasing as long as microprocessor clock rates kept increasing.

Microprocessor clock rates stopped increasing a few years ago, and so people turned to parallel programming to extract more performance out of their application programs. One central idea in parallel programming is that independent data and instruction streams may be divided up and executed simultaneously. Much of the underlying computer processors (CPUs, GPUs and FPGAs) support this style of programming. What I find puzzling is that the code development environments do not seem (to me, at least) to fully support a parallel programming style.

I’m speaking from personal experience here. I know I absolutely have to draw out my parallel code on a large piece of paper and only then can I implement pieces of the code in a traditional text-based development environment. Much to my surprise, I’ve seen papers in cognitive neuroscience concluding our human brains use the speech center to work things out in a serial fashion and use the visual center to work things out in a parallel fashion. It sure seems like a useful parallel programming environment would fully support coding using visualization instead of coding using text characters from a computer language. To be fair, this may be confirmation bias on my part. Or perhaps a programming environment using only imagery it a bit too far off in the future. I do not know as I tend to have many more questions than answers. And I’d love to be able to create parallel programs from pictures.