Jack, you raise many good points. You say that performativity is embodied
in your work literally “in the naming of the classes, functions, and
variables”. I am very interested in ways that artists use performativity
directly in the writing of code and would love to hear more about this from
you Jack or from others who do the same in their own work.
Bill, thanks for the list-based performance, I hope you will continue to
treat us to these throughout the month (and hint to all to view his
source<http://www.master-list2000.com/abillmiller/sentencesonconceptualart.html>
).
Paul’s– love the name of your one-off course *“*unplugged programming” and
the idea of teaching people about code first when they are untethered to
computers. Thanks also for bringing up a specific question to the list - how
he expansion of data-flow programming languages for is (re)shaping curricula,
creative practice, and tendencies towards emergence/support of hybrid
forms. What are some examples of these languages and how have they been
used?
GH Says “Sometimes the coding structure suggests what I can do with it.” –
I definitely find this in my own work ... Sometimes I wonder if I am
writing the code or if the code is writing me… I often feel as if I am
following a trail of code to see where it will spit me out.
Kate, I appreciate your statement that you “purposely try to use terms that
can be explored through movement and not directly dictate a movement” and I
agree that this is where the performativity comes in. I wonder if it is
always the body that runs code and gives code “life”?
And Alex has named programmers “future typists” in this poetic piece …
On Tue, Mar 4, 2014 at 8:09 PM, alex <[log in to unmask]> wrote:
> 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/
>
--
Victoria Bradbury
[log in to unmask]
PROJECTS
www.victoriabradbury.com
Researcher at CRUMB
www.crumbweb.org
New Media Caucus
Communications Committee
www.newmediacaucus.org
|