On Thu, 28 Oct 2004 10:37:30 +0100, alex wrote
> On Wed, 2004-10-27 at 16:50, Dave Griffiths wrote:
> > You're informed by the process then, not the code itself.
> > The code is a tool to shape the process - not an end unto itself to hang
> > on the wall.
>
> I agree that the code is a tool to shape the process, but it's also true
> that the process is a tool to shape the code. I don't like to separate
> the code and the process, the code is the process in written form.
Exactly my point I think - so surely steps to make the mechanics of the
process obvious are needed to truely understand whats going on if you don't
understand the programming language. That's our most challenging task I
reckon. People aren't ever going to take the time to try to read code and
understand it during a live code performance (unless they are sober, and
already programmers) however, a dynamic process that doesn't look obscure and
geek chic is much more appealing. We're hiding our processes behind our
programming languages otherwise, and just saying - look at us, you can't
understand, but we're immensely clever!
> > I think it's by displaying a process as it's happening that's going to
> > make non programmer audiences understand live coding, not handing out
> > reference manuals in a nightclub so they can follow the code :)
>
> I agree with that. But I'd also say that they might also understand
> it just by hearing the process work without visualisations.
The word visualisation is a bad one - the process could well be audible - but
I think we need to work a lot harder at this than just triggering notes and
setting parameters using a text editor.
dave
Received on Thu Oct 28 2004 - 10:41:57 BST