On Wed, Jan 09, 2013 at 11:03:08AM +0000, thor wrote:
> 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").
>
Most importantly we can "play" without a audience. Whether you get
exhibited also does not affect whether you are a painter. "live"
implies things are in contrast to being pre-recorded, but it might
also refer to things like "live" electricity or even ammo.
Arguing semantics, BTW, still seems like entirely appropriate thing to
do when linguistics play such a large role in our activities ;-)
> 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 think so. For "livecoding" in the TOPLAP sense I think the most
important result is in the process allowing us to express feelings,
create entertainment, etc. Wether or not there is a functioning
program at the end is not that important; quite often the performance
will end in a breakdown of both the music and the code or a crash.
What people like Notch do seems more aimed at a end-result with the
exposed and likely entertaining process being a sort of side-product.
I admit that this can become a bit vague. A Lisp programmer might try
to impress his co-workers as he works at analysing data on a "live"
system, for example. He might be thinking more about his status within
the office than about the practical end-result in that scenario.
> 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".
I don't get this either. I'm relatively fluent in both Scheme and
English and I have no idea what this even means. I think I disagree as
I don't see a "contrast" between Lispy systems and "livecoding", I
think they are a good match but I'm not so sure what exactly I
disagree with now or what this now implies. I suspect that what is
called "persistent" here might be how (some) state gets preserved as
we add to or change the system, but I can do that in ChucK too; takes
a bit more effort and I should get round to doing a sort of library
for that, but I can and ChucK is not "LIspy" at all. I think it should
be rewritten after figuring out what it is meant to mean.
Yours,
Kas.
Received on Wed Jan 09 2013 - 14:04:27 GMT