On 13/01/2013 10:28 AM, Charles Céleste Hutchins wrote:
> I might be tempted to claim that in order to be considered a PL for live
> coding purposes, a language would been to be able to make decisions (ie
> if statements) and manipulate data.
Agree.
> However, many people write PD
> patches that never use conditionals and doing these patches live would
> certainly count as live coding.
Really? Under what definition.
I wouldn't consider construction of a deterministic dataflow patch "live
coding", I'd call it "live patching." I thought that distinction was
quite clear in the vernacular.
> If we're going to require a feature in
> a language, then that implies we'd also be requiring the performer to
> use that feature. Ergo, the only requirement is the ability to
> manipulate data and describe the way and order in which the data is to
> be manipulated.
Although my own performances have been limited to live patching, I have
a certain idea of what programming is. I expect to (and do) see that
thing when people perform live coding.
For me it is about the execution of *algorithms*. Not just data
specification or the construction of dataflow graphs. If a dataflow
graph clearly expresses an algorithm -- well that's a different matter.
I agree with what you say below about the ontology problem. But if a
performance convinces me that an algorithm is there, then I think it can
qualify as live coding (in all the cases you mention).
Perhaps "performed conceptual art of the reified algorithm" would be a
better moniker than "live coding"?
Maybe that doesn't require a Turing complete language. Personally I
rather think it does. Maybe even the Turing machine is not sufficient to
"express all emotions I might feel" as Kas requests.
> This allows all the live coding languages currently in
> use and also allows analogue computers and, by extension, patchable
> analogue synthesisers (some of which do support conditional logic
> anyway). It also, therefore, would have to include simulations of these
> same things, so a virtual modular synthesiser would count. This does
> imply that some user interfaces could also be included. I think this
> starts to become an ontology problem - some propellerhead software
> interfaces /could/ count for live coding, but they're not the best
> examples of what people mean when they talk about 'live coding.'
>
> Also, software interfaces just wouldn't be as exciting to watch. I
> think that one important feature of live coding is the possibility of
> crashing - the performer may do something that results in a sudden
> stoppage of sound that can not be recovered from immediately. I have no
> idea if this applies to any software interfaces. However, it is
> something I've experienced with live analogue patching.
>
> As to audiences - I know non-programmers who like to go to live coding
> shows. They don't understand the code they're seeing from the projected
> screens, but they do understand that it's live and that it's
> unpredictable and exciting. If they want to show up, why would we want
> to stop them? Anyway, not every programmer knows every language. I
> can't follow everything I see projected either.
>
> On Sat, Jan 12, 2013 at 9:17 PM, David Barbour <dmbarbour_at_gmail.com
> <mailto:dmbarbour_at_gmail.com>> wrote:
>
>
> In general no. Most user interfaces are not, in any formal
> sense, programming languages.
> To be a programming language you need Turing completeness.
>
>
> Oh? Eight years studying PL and that's the first I've heard of this
> significant restriction. I better go tell the Agda, Idris, Coq,
> Funloft, Synchrone, and Charity people that they've got it all wrong.
>
> But them SQL guys got it right. SQL's been Turing complete since
> 1998. Oh, and it seems CSS+HTML is also Turing complete (even
> without JavaScript).
>
>
>
>
>
> --
> cheers,
> Les
>
> --
> Charles Céleste Hutchins
>
> http://www.berkeleynoise.com/celesteh/podcast/
> http://www.bilensemble.co.uk
Received on Sun Jan 13 2013 - 07:25:18 GMT