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 - 01:00:42 GMT