What A Rembrandt Can Teach you about Software and Programmers

A thoughtful passage by David Gelernter in Mirror Worlds: or the Day Software Puts the Universe in a Shoebox…How It Will Happen and What It Will Mean on how looking at a Rembrandt can teach us to better understand not only software but the craft behind it.

Suppose you visit an art museum and walk up to a painting. I say “Ah ha! I see you’re admiring some powdered pigments, mixed with oil and smeared onto what appears to be a canvas panel.” You say “No, you moron. I’m admiring a Rembrandt.” Good. You’re three-quarters of the way towards a deep understanding of software.

How did this happen?

Well clearly we may, if we choose, regard a painting as a coming-together of two separate elements. The paints and canvas—the physical stuff; and the form-giving mind-plan. I’ll call these two elements the body and the disembodied painting respectively.

Both are necessary to the finished product. But they are unequally decisive to its character. If Rembrandt had (while trying to shake out a tablecloth) accidentally chucked his favorite paint set into a canal on the very morning he was destined to make our painting; if he’d accordingly been forced to go down to the basement and hunt up another set—the finished product would be the same. But if he’d altered his mind-plan—the disembodied painting—before setting to work, our finished painting would obviously have been different.

In fact, the disembodied painting is a painting in and of itself— albeit a painting of a special kind, namely an unbodied one. Rembrandt is perfectly entitled to tell his wife “I have a painting in mind” before setting to work. But plainly the mere body is no painting, not in and of itself. If the paints on Rembrandt’s table went around telling people “Hey look at us, we’re a painting,” no-one would believe them.

This distinction is the key to software and its special character. A running program is a machine of a certain kind, an information machine. The program text—the words and symbols that the programmer composes, that “tell the computer what to do” – is a disembodied information machine. Your computer provides a body.

Unlike Rembrandt’s mind plan, a disembodied information machine must be written down precisely and in full. It’s a bit like the engineering drawings for a new toaster in this regard; the machine designer leaves nothing to chance. Unlike Rembrandt’s mind plan or the toaster drawings, on the other hand, a disembodied information machine can be “embodied” automatically. No skill, judgement or human intervention is required. Merely hand your text to a computer (it’s probably stored inside the computer already); the computer itself performs the “embodying.”

So: A running program—an information machine or infomachine for short—is the embodiment of a disembodied machine. In saying this, we have said a lot. A fairly simple point first, then a subtle and deeply important one—

Some people believe that, when they see a program running, the machine they are watching is a “computer.” True, but not true enough. The computer, that impressive-looking box with the designer logo, is merely the paint, not the painting. When you say I’m watching this computer do its stuff, you are saying in effect I’m admiring not this Rembrandt but some paint smeared on canvas. Some people imagine the computer as a gifted actor (say) who is handed a program and declaims it feelingly. No: bad image. The computer itself is of the utmost triviality to the workings of the infomachine you are watching. It may decide how fast or slowly the thing runs, and may effect its behaviour just a little around the fringes, but essentially, it is of no logical significance whatever. It is a mere body, and bodies are a dime a dozen.

The second point is harder.

People often find it difficult to keep in mind that, when they see a program text, what they’re looking at is a machine. The fact that, for the time being, the machine they’re looking at has no body confuses them With good reason: This is a subtle, maybe a confusing point. They leap to the conclusion that what programmers do amounts to arranging symbols on paper (or in a computer file) in a certain way. They look at a program and see merely a highly specialized kind of document …

This mistake is fatal to any real understanding of what software is.

Understanding software doesn’t mean understanding how program texts are arranged, it means understanding what the working infomachine itself is like—what actually happens when you embody the thing and turn it on-what kind of structure you are creating when you organize those squiggles-the shape of the finished product, the way information hums through it, the way it grows, shrinks and changes as it runs, the look and feel of the actual computational landscape. This is where software creativity is exercised. This is where the field evolves, metamorphoses and explodes. Talented software designers work with some image of the actual running program uppermost in mind. Failing to see through the program text to the machine it represents is like trying to understand musical notation without grasping that those little sticks and ellipsoids represent sounds.

This kind of information is hard to convey. You can’t directly see a running program. You can sense its workings indirectly, but you can’t open the hood and look right at the mechanism. An ironic reversal of the Rembrandt experience: Here the mind-plan is tangible, but the embodied thing itself is not.

Finally concluding

[I]f you get carried away, and start asserting that “music is the mechanical manipulation of symbols on staff paper,” “programming is mathematics,” you have committed intellectual suicide. You’ve mistaken the means for the end. You’ve cut yourself off absolutely from all real inspiration, creativity and growth. And you have failed, profoundly, to understand the character of your field.

A dangerous mistake. Where software is concerned, an all-too-natural one.