It's actually your quoting of me on the PPIG list that motivated me to come
out and clarify my thoughts.
Critical code studies is, afaik, one piece of software studies. I'm hesitant
to play the role of software studies expert here, though, because while
Warren Sack is a professor at UC Santa Cruz where I'm currently in the
computer science PhD program, I've neither taken a class from him nor
actually talked to him about this stuff directly (though I opened an email
discussion today). He offered a class on software studies last year that was
attended mostly by digital arts and new media students and a few of my
computer science friends. I have only really previously talked about the
relation to livecoding in our rather snarky IRC channel.
Platform studies is indeed highly related. In particular, I think it aims to
clean up the hardware-oriented concerns that software studies might miss.
Both of these X studies fields are relatively new, so we should probably
expect certain practices like hardware-level livecoding practices such as
live circuit bending to not be represented either. Regarding Bogost making
any sort of bold claim, I think that's just his trolling strategy to stir up
lively debate. 8000+ people now click a picture of a cow every six hours as
a result of his Cow Clicker experiment (
http://www.bogost.com/blog/cow_clicker_1.shtml), and countless other social
game developers are duly enraged.
In terms of programming as a human activity (and a creative one at that),
there was an interesting talk I saw at the Independent Game Summit at the
Game Developers Conference this week. A game designer (many game designers
lack programming skills) shared his experiences learning to program with no
direct goal in hand. In the talk, he described an event where he gathered
his non-programming designer friends and got them all to download and modify
a simple clone of Breakout, telling them only to "make something awesome".
The results were visually stunning, organic, technological, abstract,
playful, and each had clearly zoomed off into a unique area of the design
space. Ideas, this event demonstrated, freely arise from even accidental
interaction with code. Here's the abstract for the talk:
%%
Description: Programming is a sensitive creation tool. Changing one single
line of code could just as easily improve a full landscape just a notch,
radically transform it, or expose something amazing that the creator couldnt
have thought of. This talk is about how for Steph Thirion - originally a
graphic designer - coding has gradually become a fundamental instrument in
every stage of video game creation, and how code is not just a tool to
materialize an idea, but can also be the thing that invents the idea itself.
Takeaway: Attendees will learn how code is an amazing tool for
brainstorming, and the importance of having their eyes open to unexpected
discoveries and possibly branch out into new unexpected paths during
development. They will learn about the creative characteristics of code,
including idea sketching. They will also learn about specific examples of
development from TETRIS, BRAID, ELISS and FARAWAY.
%%
Steph gave a really interesting characterization of code as a medium, and
explained why this led to it being such a fertile playground. Unfortunately,
I can't remember the juicy details now.
Meanwhile, while we are on a relatively theoretical run on this excellent
introductions email thread, there's one more X studies field I want to rope
in: design studies. Livecoding is a design practice. We don't need to
discuss it yet, but here's a quote from Nigel Cross' Designerly Ways of
Knowing that I find myself coming back to often.
%%
If we contrast the sciences, the humanities, and design under each aspect,
we may become clearer of what we mean by design, and what is particular to
it.
The phenomenon of study in each culture is
* in the sciences: the natural world
* in the humanities: human experience
* in design: the artificial world
The appropriate methods in each culture are
* in the sciences: controlled experiment, classification, analysis
* in the humanities: analogy, metaphor, evaluation
* in design: modelling, pattern-formation, synthesis
The values of each culture are
* in the sciences: objectivity, rationality, neutrality, and a concern
for "truth"
* in the humanities: subjectivity, imagination, commitment, and a concern
for "justice"
* in design: practicality, ingenuity, empathy, and a concern for
"appropriateness"
%%
On Fri, Mar 4, 2011 at 1:32 AM, alex <alex_at_lurk.org> 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/
>
Received on Fri Mar 04 2011 - 10:16:00 GMT