The Fractal Computer
All of you, all of you, all of you: shut up, stop what you’re doing and listen to me!
“Dan, have you gone insane?”
No. Well, maybe. But you’re all looking at it all wrong. All of it!
Computers; programming; everything!
“You have gone insane!”
No. Well, maybe. But I’m right, and that’s the point.
“Piss off, Dan!”
You’ll like it…
“Well, OK, then – let’s have it.”
…and so it starts. In fact, it started last Friday, when I interviewed a couple of junior SQL guys: they were keen and eager enough, and could talk fairly well about their experiences and how they were able to integrate with their organizations… but something was missing. I couldn’t put my finger on it at the time, but I knew it had something to do with the way the candidates related to the entire concept of programming, database design – to the computer itself, as an entity. It was wrong to me because it was not the same as the way I do it. So I started thinking about how I do it, and I realized that in some basic sense, I didn’t really know. I just do it: it’s been so long since the days when I didn’t do it that it’s now second nature to me: I’ve been doing this since I was a child: my adult mind has always programmed.
Listen: a computer isn’t a machine to which you give instructions. A computer isn’t a tool which does stuff a human mind isn’t fast enough to do. It isn’t a games machine; it isn’t a data repository; it isn’t a tabula rasa which you fill with your own ideas; it isn’t a mandala into which you pour your cathartic needs; it isn’t an infinitely-extended supermarket; it isn’t a gateway to virtual social interaction and it most certainly isn’t a pure, flat surface on which you build your architecture. Well, actually, it’s all of those things at one time or another, but those things don’t matter: they don’t define the computer for what it really is.
So, what is a computer? Here’s what it is: a computer is a fractal. I’m going to write that word in a large font now, because it’s important, and because I want to:
Allow me to explain.
Here’s a computer defined in three words: the simplest definition of a computer that can ever possibly be made:
INPUT – FUNCTION – OUTPUT
“Yeah, yeah, Dan – that’s just obvious: I mean, everyone knows that!”
Yes, they do: but what appears to elude them is that INPUT-FUNCTION-OUTPUT is a fractal pattern. Let’s look at an example – for the sake of argument and simplicity, let’s take the INPUT part, and assume it’s a keyboard.
Well, a keyboard has keys on it (INPUT) and it has a little chip in it which translates those keystrokes you make into codes (FUNCTION) and it sends those key codes to the computer (OUTPUT). That little chip receives signals from the keys (INPUT) and then it translates them into a binary number (FUNCTION) and then it sends them to the USB circuitry which transmits them to the computer (OUTPUT). And so on: right down to the gates in the chip, or the contacts the keys make when you press them. And then, the computer sends a signal to the keyboard (INPUT) which gets received by a little chip (FUNCTION) which lights up things like the Caps Lock light (OUTPUT)… yes, that’s done by the computer, not the keyboard – on an 8086 PC, for example, I think it’s segment 64, byte 23, if memory serves – you can set different bits in it in software in order to activate the various locks on the keyboard.
So there you are: the INPUT part of the computer is, itself, broken down into a variety of INPUT-FUNCTION-OUTPUT patterns, each of which can, itself, be broken down into more of them; if you want to get really pedantic about it, you can keep going right down to the level of the gates in the chips. And we haven’t even talked about software yet: all this stuff is done by hardware, with a clever arrangement of a few AND gates and so on (unless you count the USB circuitry, and you could spend a day just breaking that down).
When that keystroke reaches the computer, it generates a hardware interrupt (interrupt 1 on PC architecture). That interrupt is intercepted by a bunch of different routines at different levels: primarily by BIOS, then by whatever else has decided to hijack the interrupt for its own purposes (the first of these things being the operating system). That key code represents the INPUT part of the pattern for each of these things. The FUNCTION part will vary: in most cases, it will be to spawn any number of other processes, each of which takes that key code as its input, does what it needs to do (FUNCTION) and reports back that it’s done, or with some resulting data that its caller requires (OUTPUT). The base level of this (the hardware interrupt handler) terminates the process by acknowledging to the keyboard that the key was received and effectively ending the transmission (OUTPUT).
Now, I’m typing this document in Microsoft Word. For any given key that I press to be output as a letter in the document requires thousands of INPUT-FUNCTION-OUTPUT operations to take place: in some cases, Word has to go and find extra information on the disk; there’s a little routine counting words as I type them: right now, there are 928. Another routine knows that I’ve reached Page 3 of the document; another routine is performing spell checking as I type; something else is sending instructions and getting responses from the font handling objects in the operating system; something else is sending output instructions to the graphics unit, which is talking to the DirectX interface, which is talking to the video card, which is talking to the monitor… and every single one of these processes is made up of INPUT-FUNCTION-OUTPUT: it’s a little fractal dance which occurs every single time I press a key on the keyboard.
Deeper down, at the level of the CPU, numbers are flying around between registers, the memory cache built into the processor, the machine’s RAM: the data buses are alive with information being prioritized, packaged, enumerated, tagged, sent to different peripheral objects which contain their own processors, doing their own little fractal dance of INPUT-FUNCTION-OUTPUT… and this is happening all the time – my pressing a key is interrupting this process and adding to it, modifying it, causing new elements to be created within it.
You care because when you’re programming, you’re not writing a self-referential, enclosed unit of code. You’re interfering with an existing fractal system: you’re adding to the fractal pattern that the system represents, and which represents the system. What you do changes the nature of everything else the system is doing. I’ll say it again: what you do as a programmer affects EVERYTHING ELSE THE SYSTEM IS DOING. There is no such thing as a standalone program. In a networked environment, you’re affecting EVERYTHING ELSE EVERY COMPUTER ON THE NETWORK IS DOING.
So there’s something you haven’t taken into account – that’s what. The computer isn’t the top level of the fractal. INPUT-FUNCTION-OUTPUT doesn’t start or stop with the computer, or even with the network. The entire IT infrastructure is simply one FUNCTION in a bunch of fractal INPUT-FUNCTION-OUTPUT patterns which define the business, which define all businesses everywhere. When you write your silly little program, you’re fucking with THE ENTIRE WORLD!
“Oh, come on, Dan: you really are insane! I mean, that doesn’t make sense – how can I be interfering with everything everywhere?”
Ask Mark Zuckerberg. I think he might have some idea…
“OK, then – what should I do about it? I mean, I’m going to program regardless of what you’re saying here – how should I program differently?”
Here’s the thing: here’s what made me think of all this nonsense in the first place: here’s what I think I’m doing differently from the relative novices who came for their interviews: what I’ve seen from too many people is that they sit there, think of how to solve whatever problem is it that they’re trying to solve, and then they try to figure out how to get the computer to do what they want: it’s as though the base relationship they have with the computer is that its default state is to want not to do things, and then they feel obliged to sit there and force these things to be done –as though they’re fighting the machine to make it cooperate. Eventually, once their program is ready to deploy, it tends to be inefficient and to work in opposition to the fractal balance of the system: in short, their code looks like a FUCKING ARGUMENT.
This is not the Tao of programming.
When I program, I feel more as though I’m sitting down with the machine, having a conversation with it, explaining to it what the problem is and how I think it might be possible to solve it. By necessity, the conversation takes place in whatever language I’m using to write the program (at the moment, I’m greatly enjoying explaining stuff in C#, which is a wonderful language, filled with beautiful ideas which it is a joy to discuss with the computer). By the time the conversation is over, the computer knows what to do, and the critical, pedantic part of me tends to find that I’ve managed to express my ideas clearly, tersely and efficiently, although I probably haven’t been thinking about doing that while I was programming: it just tends to come out that way.
I think this may be the Tao of programming.
“Dan, you really are insane. Having a conversation? You’re out of your mind – the computer’s not alive, you know.”
I know. But the fractal of which it is a part also contains you and me and all the rest of the universe, and to my mind, that implies that it, the fractal, is most definitely alive.
On the other hand, maybe all this really is insane. But it’s not insane if it’s true. You be the judge.