Live Coding: Program / Process Semantics

Andrew Sorensen, live coder and author of Impromptu, sent me some interesting comments about the previous post on data, code and performance. In particular he pointed me to a concept that seems very useful in unpacking live coding practice. Computer / cognitive scientist and philosopher Brian Cantwell Smith outlines the concepts of program and process semantics. Program semantics refers to the relation between the program code (what Cantwell Smith calls "passive text") and the resulting process or behaviour - what the code does when it's compiled or interpreted and run. Process semantics refers to the relation between that process or behvaiour, and the "task domain" or "subject matter" of the software - the context in which it is applied. There's a two-stage chain of meaning: 1. the meaning of the code with respect to the computational process; and 2. the meaning of the process with respect to the context it operates in.


For Sorensen "the addition of program semantics to live performance is the primary reason to program in real time." Live coding transforms the two-stage chain that Cantwell Smith describes, because it introduces the program semantics into the task domain. In the modified version of Cantwell Smith's diagram above it's marked B. This is important: it's not just the displaying of the program code, but the playing out of the relationship between code and process / behaviour. In a live coding performance where we see code and hear sound, we are presented with the task of understanding the relation between the two - inferring or mapping the generative relation between code and sonic output. The specific relation may have a semantics of its own in the "task domain" of performance - it's not simply what you do, but also how you do it. There's also the semantics of the code itself, in relation to the task domain (A): this seems less interesting to me, but related to the code-focused theory around software art - see for example Inke Arns' paper (Runme 2004).