Creative processes are rather more mysterious than computer processes, which we like to think of as well defined, predictable and subservient to human control. For artist-programmers though, the computer process is a component of their creative process. What then is the rela-
C 6: C
tionship between an artist, their creative process, their program, and their artistic works? We will look for answers against the backgrounds of psychology, cognitive linguistics, computer science and computational creativity, but first from the perspective of an artist.
e painter Paul Klee describes a creative process as a feedback loop:
“Already at the very beginning of the productive act, shortly aer the initial motion to create, occurs the first counter motion, the initial movement of recep- tivity. is means: the creator controls whether what he has produced so far is good. e work as human action (genesis) is productive as well as receptive. It is
continuity.” (Klee, 1953, p. 33, original emphasis)
is is creativity without planning, a feedback loop of making a mark on canvas, perceiving the effect, and reacting with a further mark. Being engaged in a tight creative feedback loop places the artist close to their work, guiding an idea to unforeseeable conclusion through a flow of creative perception and action. Klee writes as a painter, working directly with his medium. Artist-programmers instead work using computer language as text representing their medium, and it might seem that this extra level of abstraction could hinder creative feedback. We will see however that this is not necessarily the case, beginning with the account of Turkle and Papert (1992), describing abricolageapproach (aer L´evi-Strauss, 1968) to programming by analogy with painting:
e bricoleur resembles the painter who stands back between brushstrokes, looks at the canvas, and only aer this contemplation, decides what to do next. Bricoleurs use a mastery of associations and interactions. For planners, mistakes are missteps; bricoleurs use a navigation of mid-course corrections. For planners, a program is an instrument for premeditated control; bricoleurs have goals but set out to realize them in the spirit of a collaborative venture with the machine. For planners, geing a program to work is like “saying one’s piece”; for bricoleurs, it is more like a conversation than a monologue.
(Turkle and Papert, 1990, p. 136) Turkle and Papert describe the bricolage programmer as forming ideas while working in the text editor, making edits in reaction to edits, rather than planning their work in advance. is accords with Klee’s account, and may also be related to that ofReflective Practice from professional studies (Schon, 1984). Reflective practice distinguishes the normal conception of knowledge, as gained through study of theory, from that which is learnt, applied and reflected upon while ‘in the work’. As such, practice is not ruled by theory, but embedded in activity. Reflective practice has strong influences in professional training, particularly in the educational and medical fields. is suggests that the present discussion could have relevance beyond our focus on the arts.
C 6: C
Although Turkle and Papert address gender issues in computer education, this quote should not be misread as dividing all programmers into two types; while associating bricolage with feminine and planning with male traits (although for critique of their method see Blackwell, 2006a), they are careful to state that these are extremes of a behavioural continuum. Indeed, programming style is clearly task specific: for example a project requiring a large team needs more planning than a short script wrien by the end user.
Bricolage programming is particularly applicable to our theme of the artist-programmer, writing soware to work with media such as music and video animation. To ground the fol- lowing discussion, we bring an image of a visual artist to mind, programming their work using the Processing language environment (§5.2). Our artist begins with an urge to draw superim- posed curved lines, having been inspired by something they saw from the train the previous day. ey quickly come up with the following program, shown with its output below:
float rx() { return( random (width )); }
float ry() { return( random ( height )); }
void draw () { background (255);
for (int i = 0; i < 20; ++i) { bezier (rx(), ry(), rx(), ry(),
rx(), ry(), rx(), ry ()); }
}
On seeing the output of the first run, our artist is immediately struck by how hairy it looks. anks to arbitrary placement of the curves through use of pseudo-random numbers, each time the artist runs the program it comes up with a different form. Over a few runs, the artist notices the occasional suggestion of a handwrien scribble. Intrigued, they change their program to join the curves together, in order to remove the hairiness and accentuate the scribble:
void draw () { background (255);
float x = rx (); float y = ry ();
for (int i = 0; i < 5; ++i) {
float x1 = rx (); float y1 = ry (); bezier (x, y, rx(), ry(), rx(), ry(), x1 , y1); x = x1; y = y1; } }
e end-points of the curves are still placed arbitrarily, but they now begin at the point where the previous curve ended, resulting in a continuous line. Aer a few more runs, our
C 6: C
artist begins to perceive a leer-like quality in the scribble. ey decide to try writing them across the page, grouped into word-like forms:
float letterSpace = 30;
float rx () { return( random ( letterSpace + 10)); }
float ry () { return( random ( height - 10)); }
int rWordlen () { return(3 + int( random (4))); }
void draw () { background (255);
int letters = (int) (width / letterSpace ) - 4;
int wordLen = rWordlen ();
int word = 0;
float x = rx (); float y = ry ();
for (int letter = 0; letter < letters ; ++ letter ) {
float ox = letter ∗ letterSpace + word ∗
letterSpace ;
if (wordLen -- == 0) { wordLen = rWordlen (); word ++;
}
for (int i = 0; i < 3; ++i) {
float x1 = rx() + ox; float y1 = ry ();
bezier (x, y, rx() + ox , ry(), rx() + ox , ry(), x1 , y1 ); x = x1; y = y1; } } }
e output has a handwrien quality, appearing almost readable, a quality of ‘automatic writing’ used by mystics to supposedly channel the spirit world. is may bring further con- ceptual development to our artist’s mind, but at this point we will leave them pondering.
Our case study is somewhat simplistic, and is not intended to illustrate either great art or great code. However it does trace a creative process of sorts, as carried out by the present author. We are not suggesting that the algorithms themselves are creative, any more than we would suggest that paint is creative. Multiple executions helped our artist perceive qualities in the output, but it was the artist’s perception, and not the algorithm that discovered value. It is clear that our programmer, like a painter, could not understand their code until they had perceived its output, that the act of perception was itself creative, and that the concept they were trying to encode was continually changing in response to their perception of the results. We seek to understand this process in greater depth in the following sections.
C 6: C
Figure 6.2:e process of action and reaction in bricolage programming
6.3.1 Creative Process of Bricolage
“e source of the exhilaration associated with computer programming is the continual unfolding within the mind and on the computer of mechanisms ex- pressed as programs and the explosion of perception they generate.” Alan Perlis (foreword to Abelson and Sussman, 1996)
Figure 6.2 characterises bricolage programming as a creative feedback loop encompassing the wrien algorithm, its interpretation, and the programmer’s perception and reaction to its output or behaviour. Creative feedback loops are far from unique to programming, but the addition of the algorithmic component makes an additional inner loop explicit between the programmer and their text. At the beginning, the programmer may have a half-formed con- cept, which only reaches internal consistency through the process of being expressed as an algorithm. e inner loop is where the programmer elaborates upon their imagination of what might be, and the outer where this trajectory is grounded in the pragmatics of what they have actually made. rough this process both algorithm and concept are developed, until the pro- grammer feels they accord with one another, or otherwise judges the creative process to be finished.
e lack of forward planning in bricolage programming means the feedback loop in Figure 6.2 is self-guided, possibly leading the programmer away from their initial motivation. is straying is likely, as the possibility for surprise is high, particularly when shiing from the inner loop of implementation to the outer loop of perception. e output of a generative art process is rarely exactly what we intended, and we will later argue in§6.5 that this possibility of surprise is an important contribution to creativity.
C 6: C
Representations in the computer and the mind are evidently distinct from one another. Computer output evokes perception, but that percept will both exclude features that are ex- plicit in the output and include features that are not, due to a range of effects including aen- tion, knowledge and illusion. Equally, a human concept is distinct from a computer algorithm. Perhaps a program wrien in a declarative rather than imperative style is somewhat closer to a concept (§4.3). But still, there is a clear line to be drawn between a string of discrete symbols in code, and the morass of both discrete and continuous representations which underlie cognition (§2.2).
ere is something curious about how the programmer’s creative process spawns a sec- ond, computational process. In an apparent trade-off, the computational process is lacking in the broad cognitive abilities of its author, but is nonetheless both faster and more accurate at certain tasks by several orders of magnitude. It would seem that the programmer uses the pro- gramming language and its interpreter as a cognitive resource, augmenting their own abilities in line with the extended mind hypothesis (Clark, 2008).