On 14 August 2013 01:56, David Barbour <dmbarbour_at_gmail.com> wrote:
> With 'live programming', the whole point is the easy, low-overhead retries
> with rapid feedback. It's a learning and exploratory experience. It's the
> difference between aiming a hose vs. aiming a bow - no need to restart,
> reload, re-aim
The above is true of the live musical context too, both in composition
and improvised performance.
> The end goal is a program that is 'on target'. Only the
> final program matters; getting there is largely a question of efficiency.
As you say it's a learning and exploratory experience, and so it is
not just a question of efficiency, towards a fixed or idealised goal.
If it's exploratory, the goal is changed or emerges during the process
of programming. If it's learning, the programmer changes through the
process too. I think live coding/programming is an opportunity to drop
entrenched thinking in software engineering, and open things up for
new kinds of programmers and find new motivations for programming.
> With 'live coding' the show must go on. There are no take-backs in front of
> an audience. The intermediate outputs matter. The end-state of the code does
> not.
In live coding there may not be an audience beyond the programmer.
When there is, then yes that does change things, but in agile
programming there could be an audience too, as the client is included
in the design process.
> A live coder is strumming and manipulating that code like an
> instrument, but generally not developing an independently usable program.
> Some live coders even delete their code at the end, to make it extra super
> clear that they aren't programming.
Of course we are programming, we are just programming for the moment,
not for multiple future moments. Automation during a live coding
performance is going on, it is just mutable and transient. For live
coded composition, design processes are closer to those you have in
mind for 'traditional' software engineering.
> Different purposes, different priorities, different concerns, different
> communities. I feel there is a need to distinguish them.
I agree there are different purposes, priorities and concerns at play,
but they are intermeshed and interdependent. It would be a shame to
see them considered separately, and I'm sure that would result missed
opportunities.
I agree there is a need to consider liveness as a feedback loop
between programmer and code as a particular concern, such as that
exhibited by feedback.pl, IXI lang, spreadsheets, pure-data and
max/msp. I think this is an aspect that could be explored much more,
as a feedback loop which goes unsupported by many contemporary live
coding systems.
There are different but related concerns related to on-line
programming, which includes the outside world in the live feedback
loop. Examples of this include live coding in front of an audience,
live systems programming, live coding in conference presentations,
live coding with clients, and so on.
It is important not to get these two kinds of live feedback loops
confused - one between programmer and code, and one between
programmer, code and the world. I think we generally do not get these
confused, it's just that in the present context they often come
together, and we have not developed terms for discussing them
separately.
We do not have to be single-discipline people. Great insights are
achievable by linking together and participating in multiple
disciplines. As computer programming is our topic we have special
opportunities to do so.
alex
--
http://yaxu.org/
Received on Wed Aug 14 2013 - 06:22:52 BST