Simple Things Doing What Comes Naturally

Simple Things Doing What Comes Naturally

Back in High School, when I got interested in computers, I naturally started out writing toy programs: four-function calculators, Hanoi towers, and so forth. And I looked up to the people who wrote tools like compilers and operating systems: they were demigods who bestrode the earth like colossi. The day when my friend and I learned how to make operating system calls and get the name of the current user so that our program could greet him by name, it was as if we had learned to tap into some source of deep magic bestowed upon us mere mortals by the benevolent gods of the data center.

Of course, I eventually learned better. One of the courses that affected me the most in college was Computer System Architecture. We started with transistors: a transistor is basically a three-layer sandwich of silicon with different types of impurities in the three layers; and as a result, it has an interesting electrical property: if you attach wires to the outer layers of the sandwich, the transistor acts as an insulator. But if you attach a wire to the middle layer and apply a little bit of current, then current can flow through the first two wires. This was simple stuff we’d covered in High School physics.

In Computer System Architecture, we saw how to connect transistors to each other and how, by connecting this output wire to that input wire, you could build more complex and interesting structures: logic gates, J-K flip-flops, memory cells, accumulators, adders, general-purpose logic units, processors programmable in microcode, and so forth. It was, in short, a primer on how to get from very simple components to a CPU.

Other courses picked up where that one left off: Operating System Design showed how to turn a CPU into something useful by providing useful ways to control the hardware. Theory of Compilers showed that a compiler is just a program that reads a file and transforms it into another, roughly equivalent file, that could be used by the operating system.

As a result, the compiler-writing demigods I had looked up to in High School were not quite so far above me. Not because they had shrunk, but because I had grown closer to them. Their achievements are still the same as ever, but now I can see how they managed to do what they did: by putting together simpler components into more complex structures, and arranging things to fulfill a goal.

But through it all, what’s astounding to me is that there’s no ghost in the machine: the editor I’m using to write this post (Emacs, for the record) and the computer on which I’m typing are just bits of wire and silicon and iron oxide and glass, arranged in such a way that electricity, doing what it “wants” to do, will wind up doing what I want it to do. Instead of writing text, I could be simulating nuclear reactions or composing music, but in the end, it’s just electricity doing the things that electricity does, but channeled in such a way as to do something greater.

For some reason, I’ve been reading about biochemistry lately: The Machinery of Life by David S. Goodsell, Genesis by Robert M. Hazen, and most recently Coming to Life by Christiane Nüsslein-Volhard. And what’s remarkable is that I’m getting the same sort of vibe as I did from Computer System Architecture: as wonderful and complex as life is, it’s just chemicals doing what they normally “want” to do; simple components arranged in such a way that by allowing carbon, hydrogen, and oxygen to do what comes naturally, they wind up carrying oxygen to the bloodstream, or growing feathers, or signaling developmental pathways or parasitizing bacterial reproductive mechanisms. There’s no ghost in this machine, and no need for one.

Now, given the lengthy analogy I just gave, you might think that I’d be inclined to see design in living beings. But it seems to me (and bear in mind that I’m not a biochemist or any other kind of biologist) that the closer you look, the more the intricate design of living things resembles a giant kludge.

I just attended a presentation at work about the way our employee information systems work—if you want to call that working. It evolved from the earliest computerized records in 1972. Though it has changed significantly since then, it was never possible to tear down the old system and start from scratch: at every point, the system had to be in production that month, and so the system evolved by adding patches upon patches and hacks upon hacks, so that today the system comprises several incompatible databases on different machines, serving different departments, and updating each other through a mess of batch jobs, homegrown glue scripts, and background jobs that look for errors introduced by the other parts of the system. And that’s just what living systems look like to me.