Re: [livecode] live 2013

From: thor <th.list_at_gmail.com>
Date: Tue, 8 Jan 2013 13:18:49 +0000

On 8 Jan 2013, at 12:55, Ross Bencina wrote:

> On 8/01/2013 11:26 PM, alex wrote:
>> This looks good:
>> http://liveprogramming.github.com/2013/
>
> The closed access publication requirement is a complete non-starter:
>
> """Closed-Access Submissions: Research papers (4 pages) that present novel research ideas and early results; and position papers (2 pages) that raise open issues with the potential to stimulate discussion at the workshop. Papers are peer-reviewed by the program committee and will be published behind the paywall of ICSE's academic publisher. If you are a scholar looking for a traditional publication, this is your submission format."""
>
> What if you're a scholar looking for a modern open access publication?

Did they just add the "Open Access Submissions" or do you consider this not
attractive to scholars?

> Half a mark for full disclosure though.
>
> Is "live programming" something different from "live coding"?

There is a paragraph where this is discussed:

<quote>
Meanwhile, under the radar of the software engineering community at-large, a nascent community has formed around the related idea of “live coding”—live audiovisual performances which use computers and algorithms as instruments. In contrast to the reflective, persistent nature of live programming precursors like LISP and Smalltalk, live coding emphasizes the ephemeral, reactive nature of live performance.
</quote>

I stumbled when I read the last sentence, as many of the live coding environments I know
are versions of LISP and Smalltalk (Impromptu, Fluxus, Extempore, SuperCollider, etc.).
And are these live coding environments not reflective and persistent?
What _kind_ of contrast is being conjured up here between live programming and live coding?

But even if the terms "reflective" and "persistent" are said to be contrary to live coding
practice, which I consider a mistake in phrasing it, perhaps there is a sense in which
it would be good to make this distinction between live programming and live coding?

Alex you write: "In general I think it would be better if they lost the live coding /
live programming distinction", but it seems that they are framing that distinction
in the context of live performance. That might well be an interesting distinction
and one that could perhaps benefit the attempt to define what live coding is.

I'm not sure myself, but what do people think?

Thor
Received on Tue Jan 08 2013 - 13:19:33 GMT

This archive was generated by hypermail 2.4.0 : Sun Aug 20 2023 - 16:02:23 BST