Hi Adam,
thanks a lot for this detailed description. I think the field of "software-/code-studies" is actually a branch of media studies (or media science as we call it). Scholars in media science have been writing a lot about computers and code, both in artistic and scientific contexts, since the 1980s. The more conceptual papers that have been written about live coding so far can be considered as publications in this field. So there never has been any omission ! :) It is just that the notion of computation is a contested one, even amongst us, I think...
Best,
Julian
On 04.03.2011, at 03:30, Adam Smith wrote:
> 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 - 22:46:10 GMT