That's an interesting mail Kassen.
You are right in your comment about performance. Of course one can live
code without an audience. The word is too narrow in that understanding.
It should perhaps be swapped out for "play" (you're playing at home, and
playing for an audience)? Or we might say that we can perform without
an audience? (as in "performing a task").
If we want to maintain a distinction here (something I'm not convinced
is necessary), it probably would be with regards to the end goals being
different. Both practices are obviously creative, but is there a different
understanding of what is a successful outcome?
I still don't get the distinction here "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".
This distinction compares languages with a practice. And those languages
are used in live coding. What is the practice of live programming then?
Does anyone have a good example of this persistence and reflection?
thor
On 9 Jan 2013, at 00:59, Kassen wrote:
> On Wed, Jan 09, 2013 at 01:00:04AM +1100, Ross Bencina wrote:
>>
>>> 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?
>
> As I see things not even live performance is essential for our kind of
> lovecoding. We might be playing to ourselves for our own enjoyment. I
> also think that while showing screen is far preferable it is not
> essential either; performances on media like CD or radio could still
> qualify.
>
> To me personally there is a big distinction in the way we relate to
> the possibility of errors and to what degree we plan ahead. I livecode
> in Fluxus and ChucK and also use those in long-term projects intended
> to be presented only in a finished form with not much emphasis on the
> process. Though the system is the same in those cases I will try less
> impulsive things and consider the future, both in therms of design and
> with regard to the risk of losing all work in a crash in a different
> way. Later on in a livecoding performance I sometimes start getting
> (intentionally?) sloppy because I know in ten minutes I will have
> stopped or started over. At that point introducing bugs might even be
> nice as could crashes be.
>
> Then again the same psychology might be found in professional
> programmers how know they will be fired in a week. It's a subtle
> distinction, I agree. It's one of context and where it matters the
> context will already change the perception of the acts; we might not
> even need to explain in words what could already be made clear by the
> presence of a stage, chairs or a dancefloor on the one hand or
> announced game release on the other?
>
> Yours,
> Kas.
>
Received on Wed Jan 09 2013 - 11:03:58 GMT