Here’s the unedited version of my piece in the first issue. It’s about time travel and computer programming.
A performative utterance is where you say something that *does* something. Classic performative utterances are “Guilty as charged”, “I forgive you”, or “I promise”. Computer programming is when you type something that does something in the future, when the program is run, a kind of promissory performative. Programmers are basically future typists, making promises which get fulfilled more than once, maybe a million times, toying with the lives of different kinds of people, sensing whatever the future state of the world is and doing different things in response. Einstein described the wire telegraph (a prototypical Internet) as a very, very long cat, where you pull its tail in New York and its head meows in Los Angeles. Programming is like that but in between pulling the tail and the cat meowing, its front half might have moved somewhere else, maybe even Sittingbourne, or maybe splitting into a million catty tendrils across the four-dimensional space-time of Kent. These are the kinds of problems that programmers have to deal with all the time. Worse, programmers don’t get to actually travel with their code into these multiple futures, there are many sad stories where programmers do not see their work being used, and the users might not register that their software was made by a person at all.
Programmers rarely get to travel backwards through time either. The reason for this is that programmers have been trapped in a capitalistic ideal of linear progress towards an idealistic future which doesn’t arrive. The overiding metaphor of time in software engineering is of a tree of development, with its roots in the past, its trunk in the present and branches into the future. The metaphor falls down because what programmers want is for the branches to reconverge back to a new trunk, with all feature and bug requests fulfilled. The point isn’t to blossom into a million different possibilities of the future, but to clump all the branches back into a single woody stump.
When computer programmers finally give up on the future, we could rethink programming around the idea of cyclic time. Instead of writing code to engineer some future design, programmers could write code to try to get software to work as well as it did a few years ago. So far the “revision control” systems which look after these branches of code development do not support merging a branch back to a past version of itself. You can “backport” critical bugfixes, but not twist a branch round to connect the future with the past. If this was better supported, all sorts of interesting applications could appear. The coming apocalypse is one obvious application, requiring current strands of development to connect back to previous ways of life.
Südthüringer-Wald-Institut is a research institute working exactly on this kind of “technocratic doomsday fetishism”, developing technology to support post-apocolyptic research in a cave 200m below the Southern Thuringian Forest in the former East Germany. With a large percentage of technological research ultimately targetting military purposes, programmers and other technologists should certainly bear in mind the possibility that their future may involve a jump back to the past.
So far so gloomy, lets move on to talk about socks. We knit socks and other tubes by using circular needles, not back and forth but around and around in a loop. Programming can feel this way too, particularly when programming while drunk, at night, with a couple of hundred people dancing to the code you’re writing. This kind of activity is known as “live coding”, and is live in a number of different ways. Firstly there’s a live feedback loop between the programmer and their code, sometimes helped along by live data visualisation. Then there’s the feedback loop between the programmer and the music; writing some code, which generates music, which the programmer hears, and responds to by changing the code. Then there’s another between the programmer and the live audience, the audience responding to the music, and the programmer responding to their movements.
But in some sense, programming cannot be live at all. Programmers don’t program *in* time, they program *with* it. Back to that knitting analogy; programmers work with the thread of execution, or the timeline, by working on the higher-order level of the knitting pattern. The thread of time does not run through their fingers, but it does run through their ears, and their computers. Their fingers are instead working on the knitting pattern which are working outside of time, controlling the whole process, composing and manipulating patterns for present and future iterations.
No wonder then that live coders rarely look present at all in the performances they give. Their audience experience the music now, but the live programmers step out of time, abstracted out into an amodal, ungrounded timeless void. In a strange reversal the audience create all the spectacle, and the performers sit quietly in the corner, completely still apart from flurried typing and the occasional sip of mezcal. Maybe the next step for programmers is to learn to work with time while being in it.
This article was written during a residency at Hangar Barcelona as part of the European Culture ADDICTED2RANDOM project.