Information Technology Reference
In-Depth Information
program with that of its development, using dynamic interpretation or compilation.
Interactive programming makes a dynamic creative process of test-while-implement
possible, rather than the conventional implement-compile-test cycle, so that arrows
showninFigs.
9.3
and
9.7
show concurrent influences between components rather
than time-ordered steps.
Interactive programming not only provides a more efficient creative feedback
loop, but also allows a programmer to connect software development with time
based art. Since 2003 an active group of practitioners and researchers have been
developing new approaches to making computer music and video animation, col-
lectively known as
Live coding
(Blackwell and Collins
2005
,Wardetal.
2004
,
Collins et al.
2003
, Rohrhuber et al.
2005
). The archetypal live coding performance
involves programmers writing code on stage, with their screens projected for an au-
dience, while the code is dynamically interpreted to generate music or video. Here
the process of development is the performance, with the work generated not by a
finished program, but through its journey of development from nothing to complex
algorithm, generating continuously changing musical or visual form along the way.
This is bricolage programming taken to a logical and artistic conclusion.
9.7 Conclusion
What we have discussed provides strong motivation for addressing the concerns of
artist-programmers. These include concerns of workflow, where elapsed time be-
tween source code edits and program output slows the creative process. Concerns
of programming environment are also important, which should be optimised for the
presentation of shorter programs in their entirety to support bricolage programming,
rather than hierarchical views of larger codebases. Perhaps most importantly, we
have seen motivation for the development of new programming languages, pushing
the boundaries to greater support artistic expression.
From the embodied view we have taken, it would seem useful to integrate time
and space further into programming languages. In practice, integrating time can
mean, on one hand, including temporal representations in core language seman-
tics, and on the other, uniting development time with execution time, as we have
seen with interactive programming. Temporal semantics and interactive program-
ming both already feature strongly in some programming languages for the arts, as
we saw in Sect.
9.6
, but how about analogous developments in integrating geomet-
ric relationships into the semantics and activity of programming? It would seem the
approaches shown in Nodal, the ReacTable and Text described in Sect.
9.1
are show-
ing the way towards greater integration of computational geometry and perceptual
models into programming language. This is already serving artists well, and could
become a new focus for visual programming language research.
We began with Paul Klee, a painter whose production was limited by his two
hands. The artist-programmer is limited differently to the painter, but shares what
Klee called his limitation of reception, by the “limitations of the perceiving eye”.
