You might find this article by Simon Yuill useful. Do you know it?
http://www.metamute.org/en/All-Problems-of-Notation-Will-be-Solved-by-the-Masses
He contextualises coding practices through the example of the Scratch
Orchestra of the late 1960s, then makes a historical parallel to live
coding which serves to demonstrate how innovative forms of notation and
improvisation techniques seek to free themselves from aesthetic and
social conventions and that these are devised in relation to wider modes
of production. Live coding can be seen to be reflecting present
conditions where our lives seem to be ever more determined by various
scores and scripts (this is what Paolo Virno says, that work is
performative and speech-like). What is innovative about live-coding
reflects wider processes. So live-coding is very much seen as a human
activity for better and worse! This also relates to what I am trying to
write about presently as a contribution to "software studies" (a
catch-all phrase for some research and publishing initiatives).
geoff
On 3/4/11 10:32 AM, alex wrote:
> Thanks for this Adam, very nice points! I am surprised that Warren
> Sack is apparently not taking a human centric view of the role of
> programming in software. It seems a bit odd, I'd like to know more.
>
> I don't know if 'critical code studies' is related to 'software
> studies', but I liked Stephen Ramsey's narration on Andrew's video:
> http://vimeo.com/9790850
>
> Also I don't know if 'platform studies' is related but I found this
> odd as well, which hidden amongst a discussion about course
> requirements, makes the strong claim that programming languages aren't
> languages at all:
> http://www.bogost.com/blog/computers_are_systems_not_lang.shtml
> that links to this post, which makes the point that programming
> languages are equivalent to recipes:
> http://arcade.stanford.edu/should-computer-%E2%80%9Clanguages%E2%80%9D-qualify-foreign-languages-phds
>
> Ian Bogost didn't approve my comment (I guess it got lost in spam) so
> I commented here, which then got some enlightening responses in the
> comments:
> http://yaxu.org/languages-are-languages/
>
> I also started a thread on PPIG, which also got some very interesting
> responses (although towards the end devolves into a technical
> discussion about printf):
> http://www.mail-archive.com/ppig-discuss-list%40open.ac.uk/index.html#00265
>
> It seems easy to forget that programming is a human activity, and view
> it under formal terms in `worst-case' scenarios of translating
> business logic from one form to another, rather than consider it more
> broadly as how programming is actually done, and what it makes
> possible. Live coding can help with this I think.
>
> alex
>
> On 4 March 2011 02:30, Adam Smith<adam_at_adamsmith.as> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>
>
> --
> http://yaxu.org/
--
Dr Geoff Cox
Associate Professor (Reader)
School of Art& Media
University of Plymouth
PL4 8AA
UK
W: http://www.plymouth.ac.uk/
E: gcox_at_plymouth.ac.uk
skype: geoffreycox
Received on Fri Mar 04 2011 - 10:01:05 GMT