There's been some interesting discussion around the Wegner/Goldin/Eberbach papers; seems like it touches a few prickly nerves here and there!
Here's one example:
Are There New Models of Computation? Reply to Wegner and Eberbach†
PAUL COCKSHOTT1 AND GREG MICHAELSON2,*
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.102.3854&rep=rep1&type=pdf
Seems like there's a lot of underlying passion. It would be nice to see through this to what's really important.
On Jul 17, 2010, at 1:36 PM, Till Bovermann wrote:
> IMHO, a language used for live-coding should not be turing complete, but a Choice Machine.
>
> http://www.engr.uconn.edu/~dqg/papers/myth.pdf
> http://en.wikipedia.org/wiki/Turing_machine#Choice_c-machines.2C_Oracle_o-machines
>
>
> lg
> Till
>
> On 07.03.2010, at 21:44, alex wrote:
>
>> On 7 March 2010 06:44, Adam Smith <adam_at_adamsmith.as> wrote:
>>> I couldn't help but notice your PhD transfer report that you use Turing
>>> completeness as requirement on livecoding languages.
>>
>> Yes I used it as a quick and convenient definition. Certainly not
>> authoritative outside of the report itself.
>>
>>> I can understand the
>>> move to a more rigorous definition of livecoding languages to exclude things
>>> like pressing merely buttons on a groovebox or rewiring devices in Reason on
>>> the fly, but, and here's my question, how important is the actual
>>> Turing-completeness aspect?
>>
>> I'm not totally sure. This issue came up before in October (subject:
>> IXI lang), although we didn't go into detail and I think everyone
>> disagreed with me.
>>
>> At the moment I don't think it is important. A Turing complete
>> language certainly seems a prototypical medium for live coding. But
>> why make the constraint on the language and not the use of it?
>> Perhaps that is a better place to start, not looking at what is
>> possible but what is done; the making of symbolic abstractions for
>> example.
>>
>>> A few months ago I created the livecoding language I called the
>>> "context-free music language" (http://wiki.github.com/rndmcnlly/cfml/).
>>
>> Nice! Yes this is a very good counterexample, I wouldn't claim this
>> wasn't a live coding language.
>>
>>> Working within a context-free language made it clear that distinctions
>>> between Turing completeness and context-freeness become much less important
>>> when you can edit the code while it runs.
>>
>> A good point.
>>
>>> In terms of Turing machines, the
>>> ability to edit the tape at run-time busts you into super-Turing territory
>>> right away, even if your surface syntax is technically just regular
>>> expressions or something else limited.
>>
>> Or indeed just editing a plain sequence of notes. Actually I think
>> symbolic computation is involved even when improvising music on a
>> piano. Why wouldn't it? Notes are clearly symbols. The argument
>> isn't that live coding is something completely different. In my view
>> playing music always involves computation married with spatial
>> exploration and reasoning. It's just that when you play the piano,
>> some of the spatial exploration is made explicit, whereas with live
>> coding some of the computation is made explicit.
>>
>> From that perspective, Turing completeness seems useful, because
>> notionally any computation can be represented. But you're right,
>> context free language is powerful enough. I've certainly done many
>> `live coding' performances where I've just tweaked constants in
>> pre-prepared scripts... I think the open-endedness of live coding
>> with general purpose languages can at times make the use of it rather
>> conservative.
>>
>> So basically I'm confused...
>>
>>> Perhaps a visualization of your code
>>> that is guaranteed to use no more than a regular expression (visualized with
>>> state-edge graphs and a highlighted current state) or context-free grammar
>>> (visualized with a tree and a highlighted path of active nodes) would
>>> provide a middle ground that entices the audience to both notice low-level
>>> regularities in the music and bootstrap understanding of your high-level
>>> code. Across edits, it would also serve to visualize the difference between
>>> edits that merely tweak a parameter and those that radically change the
>>> generation space (despite both only involving a two-character change,
>>> perhaps).
>>
>> This sounds great!
>>
>> cheers
>>
>> alex
>>
>> --
>> http://yaxu.org/
>
Received on Sun Jul 18 2010 - 18:26:22 BST