This is a very interesting discussion. I tend to think about this topic
along two largely separate lines and it seems to me that depending which
line of thinking is chosen what "live coding" means ends up being very
different things.
The first is a kind of engineering perspective along the lines of "how can
I support live coding". The other one is an artistic one, where the
question is "is this live coding". I find the first one usually fairly easy
to deal with, while the second one to be on the hard side.
Let me tackle the second one first. because it leads back to what Thor
wrote in his herding article. It seems to me that Thor largely (though
certainly not exclusively) focuses on the artistic side of the definition.
It seems to me that a big part of the problem with definitions in art is
simply that art as seen in (post)modernity all too often is about the very
notion of challenging categories and definitions. From my perspective I
would even say "why worry about categories and definitions", when we can
look at art as experiences that are indeed highly individualistic (any two
observers or practicioners may indeed not agree on what they think or
experience). In short I do not see a need for normativity in that space.
I find it very easy to conceptualize pieces that would hit boundaries or
allow argumentation whether or not it was "live coding". Take a piece where
a single performer on stage writes code (projected to the audience) and
then hits a compile button. The performer waits for the computer to
respond, but the response never comes. The piece ends. Was this live coding
or not? Taking the question seriously I can fall on both sides of the
argument and it would fall along the arguments that Thor disucsses with
regards to strong or weak definitions. But from my view this piece does not
need an answer and in that character it is very much like modern art. The
purpose is not to give you clean categories. The purpose is to give you an
experience and perhaps stimulate ideas. To me it is much more exciting to
think about the relationship of the human to the expectations regarding the
computer in that piece than whether or not we can cleanly categorize the
piece.
That said I think it remains a persistent impulse to seek clean categories,
and either assume or desire normativity. What I would suggest is to perhaps
attempt to question those impulses along with definitions.
Now that is all rather abstract and lofty and almost sounds like I'm
advocating against definitions. So let's return to the first line of
thinking that asks the question "how can I support live coding".
Within science and engineering, definitions play a very important role.
Clarity helps communicate ideas and help form and understand structures. We
try to understand and build systems with predicted and desirable properties.
I do not find it very difficult to think about how I can make a certain
coding environment "more live" or "more fitting for live coding
activities". To do this using an operative definition of "highly
interactive programming" is perfectly appropriate to anchor the thinking.
But with any complex topic there are many moving parts. Some of these
topics may have nothing to do at all with a running program. For example
the question of defining a syntax that can be entered rapidly does not
require any consideration at all of the run-time system. Some absolutely
require consideration of the runtime system. Some are consequences of
practices that are sought to be supported. For example one of my grad
students (Sang Won Lee) worked quite a bit on supporting collaborative live
coding, i.e. 2 or more write code together. It starts with trying to
understand the pitfalls of what happens when two people concurrently write
code on one run-time state engine. Then it seeks to engineer solution that
alleviate problems that emerge from that practice. But while doing this
kind of work, one problem we distinctly did not have was finding
definitions or clear categories.
That isn't to say that all engineers agree what live coding is. One of my
grant proposal about collaborative mobile live coding was critiqued because
I had a "run" button and part of what we wanted to measure was
responsiveness of the system with respect to that button. The reviewer
argued that the very existence of a run button was antithetical to a system
being categorized as a live coding environment. I understand where that
comes from when people know liveness through Brad Victor's popularization.
But in music performance, having the control to decide when an algorithm
starts is important and merely relates to control over timing not the
liveness of the system itself. If there actually was a rebuttal process in
those grant reviews I do not think that this misunderstanding was beyond
repair, but it does point to an importance for clarity of definitions.
I know this is long but in short I am arguing that it's great to be
extremely lose with categories in art (live coding as artistic practice),
and that at the same time having clear engineering categories isn't all
that difficult (how to make environments more suitable for live coding).
And perhaps some clarity can be achieved by indeed taking multiple
different lenses on what "live coding" is.
- G
On Sun, Dec 27, 2015 at 9:54 AM, Robert Oetting <robo.oe_at_gmail.com> wrote:
> >> I tend to think David is right that you need to involve a computer in
> live coding. Sometimes those computers are humans, animals, nature, or
> analogue machines. (See Hayles' book "My Mother was a Computer").
>
> > I think I agree with you here. and its giving me a headache. Is there
> > really nothing that distinguishes a computer from a system? Does
> > Hayles' say no?
>
> I like to compare it to painting. The computer is like the canvas, the
> paint is like the language, and the actual painting is like the
> program. I guess the machine is as important to live coding as the
> canvas is to painting. Its your space in which you can operate.
> Imagining a painting is not painting. Electrons are as real as
> pigments.
> In this sense livecoding is the act of creating a real time-dependant
> system. For me, learning to code was learning that algorithms are
> real, and that systems can be a medium for art. I found this also
> politically extremely important, because coding for beauty means going
> in opposition against technocracy and positivism, against the horrible
> notion that technology is just a tool to increase efficiency. Not
> saving the program is an act of rebellion. Livecoding makes the fact
> that technology alters its environment immediately visible.
>
> 2015-12-27 13:38 GMT+01:00 Tristan Strange <tristan.strange_at_gmail.com>:
> >> Great to see a discussion happening on a mailing list and not on that
> awful Facebook!
> >
> > Fair enough - I don't see why everyones so down on the comment
> > section. Its got more of a forward thrust than mailing lists sometimes
> > what with easy quoting and what not. I also find I worry a lot more
> > about what I'm saying on than I do on mailing lists. You never know
> > which pricks going to weigh in on FB. Horses for courses.
> >
> >> I tend to think David is right that you need to involve a computer in
> live coding. Sometimes those computers are humans, animals, nature, or
> analogue machines. (See Hayles' book "My Mother was a Computer").
> >
> > I think I agree with you here. and its giving me a headache. Is there
> > really nothing that distinguishes a computer from a system? Does
> > Hayles' say no?
> >
> >> I once wrote a paper on the difficulty of defining live coding. That's
> why the title became "Herding Cats" - it might be relevant here.
> >
> > Thanks Thor, it's bonkers how much of human endeavour boils down to
> > some form of cat herding. I think I've heard it said about every job
> > I've ever done except for shelf stacking. Really looking forward to
> > having a read. Ta.
> >
> >> I wonder if you can live code lying on your back in the dark (like
> Beckett) writing code in your minds eye, and not bothering about an
> interpreter or an audience?
> >
> > In that situation isn't your mind the interpreter and audience?
> >
> > On 27 December 2015 at 11:59, thor <th.list_at_gmail.com> wrote:
> >> Hi all,
> >>
> >> Great to see a discussion happening on a mailing list and not on that
> awful Facebook!
> >>
> >> I tend to think David is right that you need to involve a computer in
> live coding. Sometimes those computers are humans, animals, nature, or
> analogue machines. (See Hayles' book "My Mother was a Computer").
> >>
> >> But on a reflection, I wonder if you can live code lying on your back
> in the dark (like Beckett) writing code in your minds eye, and not
> bothering about an interpreter or an audience? A bit like a modernist
> composer who doesn't give a damn about the listener.
> >>
> >> I once wrote a paper on the difficulty of defining live coding. That's
> why the title became "Herding Cats" - it might be relevant here.
> >>
> >> Thor
> >>
> >>> On 27 Dec 2015, at 11:38, Tristan Strange <tristan.strange_at_gmail.com>
> wrote:
> >>>
> >>> On 26 December 2015 at 16:19, David Barbour <dmbarbour_at_gmail.com>
> wrote:
> >>>> I think a computer must be involved with processing the code. I'm not
> >>>> inclined to include a Simon Says game as live coding, for example.
> But it
> >>>> doesn't need to be today's common keyboard-video-mouse setup. And the
> >>>> computer could certainly communicate in ad-hoc ways with other people,
> >>>> robots, and devices.
> >>>
> >>> It's funny, I came here expecting to be told that my definitions were
> >>> too restrictive - not to be telling other people that.
> >>>
> >>> If you're using this definition what distinguishes just using a
> >>> programmable computer program (lets say Excel) from live coding?
> >>>
> >>> --
> >>>
> >>> Read the whole topic here: livecode:
> >>> http://lurk.org/r/topic/6YN3PsRb6a6znz2nS93s5Y
> >>>
> >>> To leave livecode, email livecode_at_group.lurk.org with the following
> email subject: unsubscribe
> >>
> >>
> >> --
> >>
> >> Read the whole topic here: livecode:
> >> http://lurk.org/r/topic/70exJrb1n4wf0zbnxNmtKK
> >>
> >> To leave livecode, email livecode_at_group.lurk.org with the following
> email subject: unsubscribe
> >
> > --
> >
> > Read the whole topic here: livecode:
> > http://lurk.org/r/topic/3hqGGGS2bW2ZVqSy4Pme1D
> >
> > To leave livecode, email livecode_at_group.lurk.org with the following
> email subject: unsubscribe
>
> --
>
> Read the whole topic here: livecode:
> http://lurk.org/r/topic/4VB5MWGRkIDXPvJeOglJkx
>
> To leave livecode, email livecode_at_group.lurk.org with the following email
> subject: unsubscribe
>
--
--
Georg Essl
gessl_at_umich.edu
(734)-730-0791
Assistant Professor
Electrical Engineering & Computer Science and Music
University of Michigan
--
Read the whole topic here: livecode:
http://lurk.org/r/topic/5gMtYlRD9OkPzUa0UmLwUp
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Sun Dec 27 2015 - 17:00:40 GMT