I was quickly entrenched in reading Love Coding’s user manual. Alan F. Blackwell – the author – quickly grabbed my attention when he outright challenged the notion of a user. This chapter immediately brings up multiple dynamics that come into play when one is using a computer, a piece of software, code. I found it fascinating how Blackwell juxtaposes Big Tech’s aim to make computers invisible for a good user experience, and Live Coding’s emphasis on the code. Furthermore, other characteristics of live coding mentioned make me very curious about the field. For example, I had never considered the temporality of software. I wonder if being “constrained” within the present tense when coding live will alter my perspective of regular software. I am also very interested in the materiality of software. The idea presented by the author that live coding brings out the materiality of a computer and hardware is interesting to say the least.
The practice of live coding as per Blackwell’s introduction makes me recall the live poets that I saw on the streets of New Orleans. These people write poems for people on the spot on a typewriter. The magic of these experiences lies not on the poem, but on the temporality and visibility of the whole process. I am eager to explore live coding and recreate this sensation that the poets brought out! Perhaps exploring the elements that Blackwell points out through this comparison will be a useful experience!!
The answer to this question was somewhat unclear to me before I took this class. I had watched an IM showcase performance from this course before, but apart from finding it very cool I wasn’t sure what the ideas behind it were. The book Live Coding: A User’s Manual quotes live coder David Ogborn on why live coding should not have a fixed definition:
“To define something is to stake a claim to its future, to make a claim about what it should be or become. This makes me hesitate to define live coding.”
As mentioned in the text, Computer Science textbooks and other sources where static code is printed often become outdated pretty quickly due to the ever-changing nature of coding practices. This holds even more true for live coding, which is improvisatory and involves thinking on the fly, writing and rewriting all in a public performance.
I liked the reflectiveness this reading incited, especially when it came to questions such as what it means to be live. I had not been aware of the etymology of programming (“writing in public”). Given the isolationist nature of programming today, we could say that we have strayed a lot from these ancient origins, further highlighting the need for live coding. Opening up this usually private activity to the public provides a liberating creative aspect which is also helpful in building community.
Finally, I want to touch upon the analogy to musicians they made for live coding in a creative context. This was particularly the most exciting part for me. I have watched live jazz performances and been floored by the open jam sessions where random people would come together with their instruments and jam on the spot, not having met or practised together before. I do not know much about music theory, so I just learned that what they usually do is choose notes from a particular chord sheet. Live coding gives even more freedom to the performers and basically makes them the on-the-spot composers, which is daunting but exhilarating to imagine. Overall, this reading made me look forward to learning more about live coding and actually practising it myself.
In this writing, instead of answering the question, “What is Live Coding?” with a fixed definition, the author explains it as making software live by interacting with each other, with software, and with the act of coding itself. What I like about this writing is how the author looks at live coding as “thinking in public” and as communication between the performers and the crowd. In live coding, the performers openly share their mental process through codes, while the audience gets to question and reflect on it as they follow the journey. Live coding differs from traditional computing, where we only focus on refined code rather than the process of coding itself.
The most interesting part for me was the following: “Live coding asks questions about liveness, inviting us to reflect on what it means to be live—to have bodies, to communicate, to act.” It made me think of live coding as a collective and performative ritual where everyone in the room is connected through the code-as-interface. I think live coding is an interesting and relevant way of performance that makes coding more accessible and visible, especially now when software is deeply entangled with our everyday lives.
The reading from “Live Coding: A User’s Manual” by Alan F. Blackwell and others presents live coding not just as a technical practice, but as a profound cultural and philosophical phenomenon. This perspective invites a deeper exploration of live coding beyond its surface-level description. The reluctance to strictly define live coding, as expressed by David Ogborn, suggests that its essence lies in its fluidity and resistance to rigid categorization. This resistance is not merely a characteristic of live coding; it is a statement about the nature of creativity and interaction in the digital age.
Live coding challenges conventional notions of software development, which is typically seen as a methodical, behind-the-scenes process. By bringing the act of coding into the public sphere, live coding transforms programming into a performative art. This transformation raises questions about the relationship between the coder and the audience, the nature of software as a creative medium, and the role of improvisation in technological practices. The act of coding in real-time, in front of an audience, demystifies the process, making technology more accessible and understandable. It bridges the gap between the enigmatic world of code and the tangible human experience.
Furthermore, the concept of “thinking in public” as a form of live coding is intriguing. It suggests a vulnerability and openness in the creative process, where the coder exposes their thought process, errors, and revisions in real-time. This transparency is a stark contrast to the often opaque nature of software development. It invites the audience to engage with the process of creation, blurring the lines between creator and spectator. The text also touches upon the idea of live coding as a way to “unthink” conventional engineering practices. This notion aligns with Viktor Shklovsky’s concept of defamiliarization, where familiar objects or practices are made strange to enhance perception. In the context of live coding, this means viewing code not just as a tool for building software, but as a medium for artistic expression and exploration. It encourages a reevaluation of the roles of creator and audience, the nature of software as an artistic medium, and the potential for improvisation and spontaneity in technological practices. Live coding is not just about making software live; it’s about bringing life to the process of software creation.
The reading dives into the concept and definition of live coding, emphasizing its lack of a fixed, universally accepted definition. The authors intentionally avoids rigid definitions, preferring a more diverse or “heterogeneous” definition. In simpler terms, live coding cannot be pinned down to a single explanation. It represents an evolving interaction between humans and computers, similar to a relationship one might have with plant life, as the reading mentions. Just as the health and growth of a plant is dependent on the caregiver’s attentiveness, the audiovisual outputs generated by a computer are a direct response to the user’s level of attentiveness or engagement (input). I like to think of it as coding that is alive, vibrant and responsive, far removed from a static set of instructions or algorithms programmed to produce predetermined outputs. Instead, each interaction with the code leads to unique “creative” outcomes. This idea is clearly expressed in the statement, “Live coding is about people interacting with the world, and each other, in real time, via code.” It emphasizes the dynamic and interactive nature of live coding, where the code becomes a medium for real-time communication and creation, reflecting the unique inputs of each user.
How different would the live coding experience be without the act of coding itself being projected onto the screen? I think with the invention of speakers and video recordings, a lot of experiences are diminished if it’s not performed in real-time as the audience would feel that they can get the same experience at home by watching a video. There have been incidents of concert-goers booing at the performers when they find out that the singer was lip-syncing the whole time. Does it really matter if they were lip-syncing or not? Either way, the same sound comes out of the speakers, but yet it matters a lot to an audience to know that the sound waves coming out of the speakers was produced right here, right now, and not recorded in a studio a few months ago, even if the recorded performance can be edited and rerecorded to be a much superior version to any live performance.
It is the act of a performance being performed in real-time, knowing the possibility of the performers messing up, and yet delivering beyond expectation to woo the crowd. An orchestra occupied by a speaker for each instrument. An algorave performance that’s just a prerecorded video. Though functionally they are the same, the feeling is not,, and the act of showing the code in live coding elevates it from a video to a performance.
The reading highlights the common nature between Live Coding and other art forms citing structure, rhythmic patterns, and sequence as key aspects. Initially, I held the assumption that music created through live coding might be overly repetitive or adhere to a rigid, machine-like formula. However, I’ve come to realize that the randomness introduced by computers can open up new possibilities and territories, particularly when used deliberately by the performer. Given that both repetition and chaos are essential elements in composition, Live Coding could serve as an ideal medium for achieving a harmonious balance between these two aspects.
The author also explores Live Coding as a practice resistant to hierarchical control, suggesting that it cannot be easily owned by established practitioners or institutions. Reflecting on this, I wonder if the independent nature of this movement could lead to excessive decentralization, making it challenging to keep track of its development. The proliferation of many similar live coding tools, each developing independently, may result in a situation where artists might not unify their power but instead fragment into individual parts. I believe a centralized platform offers advantages, providing a concise and focused space for artists and consumers to connect easily.