Re: [livecode] is live coding aiming to audience with particular programming knowledge

From: Ross Bencina <rossb-lists_at_audiomulch.com>
Date: Sun, 13 Jan 2013 23:11:46 +1100

On 13/01/2013 10:28 PM, alex wrote:
> On 13 January 2013 07:24, Ross Bencina <rossb-lists_at_audiomulch.com> wrote:
>> 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.
>
> I consider live patching as a subset of live coding.

Necessarily. An apple is not an apple tree.


> PD is a Turing complete language anyway..

Indeed. However David gave the example of Pd being used without
conditional logic.


>> 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).
>
> What is an algorithm anyway? To me, functional programming seems to be
> the most popular approach in live coding circles, and if your
> definition of algorithms includes constructs in pure functional
> programming, surely it also includes dataflow programming as a
> declarative sibling?

When I referred to deterministic dataflow programming I had in mind
networks that can be expressed in a directed acyclic graph. It was my
impression that's what David had in mind when he was talking about live
patching in Pd without conditionals. I don't think cyclic graphs would
work in Pd without conditionals.

This kind of dataflow may be a function, but I don't think it's a program.

If we allow for decision processas, cyclic graphs (possibly)
non-deterministic message delivery semantics then yes, there is a strong
relationship. Similarly in a functional language the use of recursion
combined with decision processes provides a basis for what I might call
"programming" as opposed to "specification".

Perhaps there is a better way to deliniate "functions that express
programs" than Turing completeness, but I can think of plenty of
functions that are not programs.

b = ax

Is that a function, algorithm or program?


>> Perhaps "performed conceptual art of the reified algorithm" would be a
>> better moniker than "live coding"?
>
> Has a nice ring to it :)
>
> alex
>
>
Received on Sun Jan 13 2013 - 12:12:27 GMT

This archive was generated by hypermail 2.4.0 : Sun Aug 20 2023 - 16:02:23 BST