Perhaps I should formally retract my statement. It looks like the
document I had in mind when writing that was an unpublished draft, and
I don't know the current state of the document. I'll try to summarize
my original thoughts anyway, but first, a little introduction.
Wikipedia gives a general starting point
(
http://en.wikipedia.org/wiki/Software_studies), but, as I understand
it, software studies examines the interaction of software and culture
from a decidedly white-box perspective, intentionally involving
source-level technical details in the discussion. As toplappy
livecoding is poking into new areas of music and software engineering
alike, it is highly relevant to software studies, but I think it is
off the radar for most authors writing on the subject. The idea that
we would make and break rules of how we normally develop software out
of a thirst for new musical experiences only to have the practices we
invent quickly reshape the aesthetics of the artifacts we were
after... that's juicy stuff.
In a draft introduction to a then-unnamed book
(
https://content.wuala.com/contents/SoftwareStudies/Readings/sack-introduction.pdf?key=6FLtmS7awQ30),
Warren Sack describes the ways programs are unlike prose (page 18), as
software studies is otherwise structurally similar to literary
studies.
* [Imperative] He describes computer languages as possessing mainly
two tenses: imperative and conditional (lacking past/present/future
distinctions). While this is mainly true (with some interesting debate
possible for functional and logical programming languages), I think
the most interesting counterexample to this idea comes up in
livecoding where ChucK and Impromptu, two pick only two, have either
specialized syntax or language idioms for making very rich statements
about time. The imperative focus is more tradition or convention than
something in the nature of programs at large. He writes "while it may
be possible to write a procedure to narrate a story, it is not
possible to write a narrative in a computer language" -- but we
certainly have the language to write a musical score.
* [Autonomous] "Writing computer code is more like building a machine
than composing a letter: once code is written it can be executed,
autonomously, by the computer." But in livecoding there is no "once
the code is written", we keep writing and by the end we've often
dismantled anything we've build up along the way. In my context free
music language, the language constructs simply aren't expressive
enough to regularly capture a procedure that is both autonomous and
interesting -- any single snapshot of the code tell you very little
about the overall trajectory of a piece, both the artist and the
audience have to be there at the same time, both keeping track of
larger scale patterns that are never formally represented in code, to
understand what is going on.
* [Impersonal] Sack writes that computer languages lack the concept of
"me" and "you" or other ways to refer to people (noting the absence of
these in legal code and bureaucratic rules as well). I think is a very
deep observation, and it really speaks to the disembodied perspectives
of purist functional programming (where every software function boils
down to the computation of a value). In livecoding (and more generally
stream computing) the idea of input and output (to/from other
systems/actors/people) is inescapable. From this perspective, input
always comes from an external place/person, is transformed, and passed
on in a relatively live fashion. The idea of functional reactive
programming (FRP) is an interesting way to merge behavior with the
purely computational perspective, but that's a discussion for another
time.
* [Infinitesimal] Sack describes programs as (metaphorically)
microscopic, impossible to observe with the naked eye. CDs and hard
drives can store instructions on an invisibly small scale, but this is
just the result of practical optimization to storage of pre-written
programs. Programs written live necessarily exist on a tangible human
scale (it's the scale we build them at!). Livecoders work in terms of
"screenfuls" putting considerable effort into giving a sane layout to
the wires in PureData or avoiding too much scrolling in Fluxus via the
intelligent code zooming. Just has a long novel has a tangible weight
due to it's physical size, the livecoder senses the size of a program
and will make effort to keep the size manageable (perhaps deleting
code from a text editor that is currently running but won't be
modified in the near future, a practice inherently tied to the
non-infinitesimal Size of the program).
* [Illegible] Citing the experience of opening the executable for
Microsoft Word in a text editor, he claims programs are illegible.
Perl aside (and I'm a fan), the legibility of even well written source
code is questionable. However, to whoever wrote the software, at the
time they wrote it, programs are always at least moderately legible.
In livecoding, that it's-under-development-right-now period of minimal
legibility often equals the entire lifetime of a program. Between the
"show us your screens" demand and efforts to engage the audience in
understanding the symbols we type and click while livecoding, we are
making progress on the legibility of programs. With this and other
efforts in literate programming, perhaps illegibility will come to be
seen has a historical quirk. With plain-text javascript embedded in
webpages and easily decompilable Java class files, various systems are
actually requiring a kind of mandatory legibility on the basis of
technical concerns alone (machine independence).
* [Instantaneous] Sack's final bullet point is the temporal equivalent
of the infinitesimal space claims above. Primitive opterations, he
reminds us, execute in billionths of a second. To this, my knee-jerk
is to quote a previous message on this list "For a long time computer
scientists have been erasing time from programming, and we're now
putting it back in."
I'm sure theres a much deeper level to discuss all of these, but
here's what think is going on at a high level. Sack has made some
interesting observations about programs and programming at large that
capture some patterns we've all seen but never written down before. At
the same, we fringe livecoders are making and breaking rules in a way
that changes what programs and programming are. It's personally
validating to see the humanities catch hold of something we care so
much about, software, but to the degree that we are a bit rebellious
I'll try not to hold them accountable for all of our activities.
On Wed, Mar 2, 2011 at 1:12 PM, Dan S <danstowell+toplap_at_gmail.com> wrote:
> Adam -
>
> I'm curious to know, so allow me to take your statement at face
> value... what kinds of claims from the Software Studies world (not a
> world I know, AFAIK) are invalidated by livecoding?
>
> Dan
>
>
> 2011/2/15 Adam Smith <adam_at_adamsmith.as>:
>> Changed your mind?
>>
>> I'm interested to know the spectrum you ranged over.
>>
>> I suppose to some it can come off as a totally absurd practice, or a
>> stunt as best. At the best of times it reveals a whole new perspective
>> on software engineering where processes only usually (but by no means
>> necessarily) have a temporally constant representation in source code.
>>
>> Having done a little bit of reading in Software Studies, I was
>> surprised by just how many claims are invalidated with a single simple
>> example of livecoding.
>>
>> Maybe the world isn't ready for it yet. That's fine, we can keep it
>> here for now.
>>
>> On Tue, Feb 15, 2011 at 3:12 PM, Click Nilson <clicksonnil_at_gmail.com> wrote:
>>> Good to see some familiar and some new live coders emerge in this thread.
>>>
>>> I've changed my mind about live coding many times, and maybe that's why it's fun.
>>>
>>> CN
>>>
>>>
>>>
>>>
>>>
>>
>
Received on Fri Mar 04 2011 - 02:33:42 GMT