Hi all,
Great to be here! I am Alex, a live coder who works with the
afore-posting Kate Sicchio among other things. My blog is here:
http://yaxu.org/
I thought I'd introduce myself with a text I wrote last Summer, while
resident in Hangar Barcelona, which was printed in Hack Circus
magazine:
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.
http://hackcircus.com/
On 4 March 2014 19:28, Curt Cloninger <[log in to unmask]> wrote:
> Hi Paul (and all),
>
> I love the idea of "run-time" errors manifesting themselves in different ways depending not just on the vagueness/strictness of the instructions, but also on the very (immanent/lived) contexts in which the instructions are received and the means by which they are executed.
>
> Jack mentioned Gregory Ulmer, and I find Ulmer's take on Derrida (in _Applied Grammatology_) super provocative and productive. The idea is that human language progresses via slippages which happen during actual utterance events. So rather than always concerning ones-self with adhering to the etymology of a word (as if a word's historical etymology was somehow God-ordained), one can also concern ones-self with the future evolution of a word. So Derrida discovers that his name "accidentally" sounds like derriere, but that there is no "actual" etymological connection. But so what? Such accidents play a role in the "actual" historical utterances that wind up constituting the etymologies of words. So why not willfully play such accidents forward? Derrida writes as if his name "actually" has something to do with derriere, and then it does (he craps on strict adherence to etymology). So also, for instance, Ulmer = Elmer's (glue).
>
> So this leads to certain experimental esoteric programming languages (esolangs), where the variable values and sometimes even the syntactical rules of the programming language itself erode in real time as the program runs. And it leads to certain forms of viral meme hacking (purposefully hijacking the agreed-upon usage of a human language word).
>
> So (back to Derrida via Ulmer), it's not just that we are merely left to deconstruct existing language in order to arrive at an impasse. It's that we can play with langauage productively to arrive at something new. "When you cut into the present, the future leaks out" (William Burroughs). Or, as you say below: "logical 'errors' take on new meaning." Because we are always "making" meaning.
>
> ///////////////////////////////////////
>
> Here are two of my art projects that seem relevant:
> 1. http://playdamage.org/transcryption/
> it's like a translation engine that is fake ("technically"), but if you buy into it (even if only partially) as real, then it's really doing something.
>
> 2. http://deepyoung.org/current/google/
> two wrong answers make a new answer.
>
> ///////////////////////////////////////
>
> Best,
> Curt
>
>
>
>
> On Mar 4, 2014, at 11:26 AM, Paul Catanese wrote:
>
>> e.g. write a set of operations to find a water fountain starting anywhere
>> on earth - then when students return w/their operations, have them
>> "perform" each others code. logical "errors" take on new meaning in this
>> context - questions of strict/loose interpretation/handling of
>> instruction.
>
>>>>>
--
http://yaxu.org/
|