Theorising while() Practising: A Review of Aesthetic Programming

Article Information

  • Author(s): David Young
  • Affiliation(s): Royal Holloway University of London
  • Publication Date: July 2021
  • Issue: 8
  • Citation: David Young. “Theorising while() Practising: A Review of Aesthetic Programming.” Computational Culture 8 (July 2021).


Review of Geoff Cox, Winnie Soon, Aesthetic Programming: A Handbook of Software Studies, London: Open Humanities Press, 2020, ISBN: 978-1-78542-094-8; web:

Over approximately the past two decades, ‘creative coding’ has gone from a fairly niche, heterogeneous, and often elective unit in media arts education to an increasingly mainstream offering in many arts and design degree programmes. Distinct from the instrumental and disciplinary approaches in computer science where software is ‘engineered’ and technical principles are mastered in a formal sense, creative coding is defined by a more playful, interdisciplinary mindset where the artist-programmer is primarily invested in speculation, experimentation, and iterative practice. In this domain, code is pitched as a tool available to the creator that allows for the realisation of novel and unpredictable aesthetic effects, ludic possibilities, and immersive experiences.

During roughly the same time period, there have also been considerable theoretical shifts and elaborations in how we imagine the past, present, and possible futures of computational culture. Software studies, for instance, has productively built on traditions of critical theory and media studies to elucidate how the social and the technical are entangled in computational processes.1 In doing so, it facilitates critical inquiry into how these processes reflect established, and are generative of novel, configurations of power and knowledge. Yet, in the past, creative coding has tended to be taught in a way that disconnects the technical practice of programming from these discussions of power and knowledge. What then, does a critical ‘praxis’ look like for those who teach how to make art with code? And how might employing the principles of play and speculation as pedagogic strategies open up opportunities for problematising the taken-for-granted in computational culture?

It is on these points that Soon and Cox’s Aesthetic Programming2 makes its intervention. The text draws on the core principles of software studies in that it enquires into the ‘conditions of possibility that software establishes’3 while illuminating the politics bound up in algorithms, interfaces, and data structures. It also builds on these principles by exploring them through the process of learning to write and play with code—specifically, JavaScript, through the friendly framework of p5.js. Soon and Cox write:

the book embraces both the technical aspects and formal qualities of code as well as opens up imaginaries of code, including acknowledgment of the material conditions of programming practice, the non-human agency of code itself, and its inherent relationality within broader ecologies.4

The authors suggest that taking this seriously means that a ‘new kind of cultural thinking’, and indeed a new curriculum, is required.5 The publication thus takes the form of a handbook written in a way that assumes no prior coding experience, and constructed in a way that playfully develops technical proficiency while elaborating a theoretical discussion of the politics and aesthetics of computational culture. In this proposed curriculum, coding literacy is not presented as an instrumental professional skill that the student needs for the world of work or to participate in the notional ‘smart economy’. Rather, it is a strategy to develop a politicised literacy of how software structures the world, and by extension, to identify how the individual might make informed interventions that expose and destabilise such structures. At its core, then, is an effort to mobilise the speculative and playful dimensions of creative coding as political resistance: ‘program or be programmed.’6

Critical Play

Although seemingly contrary to the cool managerial rationalities and formal logic that tend to be the focal points in histories of software, acts of play, mischief, fun, and speculation have long been intertwined with the technical practices of computing.7 Chris Strachey’s Love Letter Generator, presented as a case study in Aesthetic Programming, is exemplary of this. Strachey programmed the generator in the early 1950s for the Ferranti Mark I at the Manchester University Computing Machine Laboratory, of which Alan Turing was assistant director. Although not intended as an art work, it nevertheless constitutes an early example of electronic literature that subverts and makes visible the underlying structures in epistolary writing. As Gaboury writes, Strachey’s work ‘is in this sense a queer critique of normative expressions of love, enacted through a kind of generative, computational performance, through a purposefully deficient simulation’.8

Soon and Cox’s reference to Strachey to contextualise an exercise involving generative algorithms is indicative of a broader effort throughout the book to provide a politicised, historical awareness to playing and speculating with code. A critical praxis for teaching code then should demand a politicisation of the history of computational arts, and a reflective attunement to the ways in which past discourses, techniques, and models continue to shape the present. In doing so, we might inquire into how the corporate sponsorship of the bleeding edge of the computational arts is by no means a novel phenomenon, and examine the gendered, heteronormative, and racialised barriers that materialised in institutional contexts where play was marshalled as a strategy of invention.

In US-centric histories of computational arts, the campuses of Bell Labs, Xerox Parc, MIT, and RAND feature prominently. Of course, despite the creative experimentation in animation, interfaces, and even computer games, the work undertaken at these sites very much fell under the shadow of Cold War American militarism. For example, the artist John Whitney modified anti-aircraft predictors to make his ‘cybernetic artworks,’9 while VR pioneer Ivan Sutherland developed the Sword of Damocles at MIT’s Lincoln Laboratory—the very same place where the immensely impactful SAGE early warning computer system was created. SPACE WAR!, also developed at MIT in the 1960s and regarded as one of the first computer games, is inseparable from the paranoia of command and control systems such as SAGE.10

A sense of play also features prominently in early prominent exhibitions of computational arts, where the public spectacle of the computer as creative agent allowed for the popular rehabilitation of a technology that was otherwise frequently cast in popular culture as a sinister cinematic villain. IBM’s pavilion at the 1964 World’s Fair in New York, replete with a monumental multimedia-architecture designed by the Eames Office, is exemplary of this.11 Cybernetic Serendipity, curated by Jasia Reichardt at the ICA in 1968, was another early landmark in the public exhibition of works of art and design made with digital computers. The connections between the ICA show and the military-industrial complex are abundantly clear—not only in the title, but in its list of sponsors: IBM, Boeing, Bell Labs, and the US Air Force, amongst others. As Usselmann states, ‘the exhibition merged science and technology with great entertainment and a dash of art’ yet only managed a ‘conspicuous silence’ when it came to remarking on the prevailing imperatives guiding digital computing development in 1960s America.12

A similar critique for the present moment could be arguably levelled at the amorphous and heterogeneous sphere of computational arts commonly referred to as ‘creative coding’. Although it certainly could not be described as an organised movement, its origins are widely attributed to the Aesthetics and Computation Group at MIT where, during the 1990s, John Maeda developed the coding framework Design By Numbers (DBN). As Maeda explains in his eponymous book,13 in its inception creative coding was primarily about the sense of open play and the unexpected that came with unbundling design practice from the processes hard-coded into commercial software packages.

As students of Maeda, Ben Fry and Casey Reas greatly extended DBN with the Java-based framework Processing, which has consequently gained wide popularity amongst artists and designers since the mid-noughties. Maeda’s pedagogic focus on play is retained in the nomenclature of Processing, where one does not program, but ‘sketches with code.’14 Now 20 years old, the Processing project was notable for facilitating those without a background in computer science to quickly and adeptly develop sophisticated algorithmic art. Active online communities of practitioners quickly coalesced around Processing, voluntarily sharing their code, writing modular libraries to extend new functionality, and generating considerable documentation and tutorials, generally in the spirit of open source software.

Although creative coding developed around a diverse array of open source coding frameworks and creative commons licences, it was not bound by any common politicised effort to produce art that itself posed questions about computational culture or the sociopolitical implications of ‘free culture’. In the absence of a defined political or ethical disposition, creative coding is thus generally characterised by the choice of medium and a speculative intentionality. Creative coding understood literally then might thus be understood as a superset of software art, which, as Inke Arns defines it, is more reflexive: ‘activity that enables reflection of software within the medium—or material—of software’. For Arns, a transparency is necessary: the software should not purely function ‘as a pragmatic aid that disappears behind the product it contains.’15

Past creative coding handbooks have adopted various thematic approaches to teach software in an arts context, although none have employed the core principles of software studies and a commitment to transparent and cooperative workflows in the way that Aesthetic Programming does. A survey of prior Processing-based handbooks indicates a focus on the aesthetic possibilities of algorithmically-generated art. Reas and Fry’s handbook16 adopts an explicit visual cultures frame, where the resultant artworks tend to play with colour and form in a way that recalls constructivist painting and op art. In his book Nature of Code17, Daniel Shiffman focuses more on temporality and emergence through the use of ‘generative’ algorithms to simulate natural phenomena. In her handbook, Lauren McCarthy imparts core technical concepts through the development of playful, characterful algorithmic drawing.18 McCarthy is also the author of the JavaScript-based variation of Processing, titled p5.js, which also serves the framework of choice in Aesthetic Programming. Like Soon and Cox, McCarthy’s project is aware of the social contexts and structural barriers within the arena of creative coding. P5.js was explicitly designed to address the issue of inclusivity and representation in what was a most visibly a white, male, able-bodied community.19

What is important and distinctive about Aesthetic Programming is that it resists fetishising technicality and lingers on the way software configures, and is configured by, structures of power. Instead of slick UX design and algorithmic op-art, Soon and Cox present ‘speculative, alternative, and messy imaginaries’20 grounded in shared experiences of computational culture: a coded drawing of an emoji opens up a discussion about representation and variation in the Unicode standard; an introduction to animation involves the design of a loading wheel (or in its macho terminology, a ‘throbber’); and an examination of ‘machine unlearning’ through AI chatbots and text generation algorithms poses questions about how we ‘teach’ computers to model the world.

These active, intersectional perspectives are vital in that they demonstrate and expose the normative assumptions sometimes taken for granted in creative coding, and which have explicit and violent implications for those communities algorithmically-situated as exterior to such narrow classes. The book thus guides the reader through an approach to programming where history, theory, and practice are not neatly parceled out, but thoroughly combined in a way that lends itself to creative and critical invention and intervention.

This does indeed present a new curriculum, one that is in marked contrast to the institutionalised modalities of creative coding which, over the past decade or so, have been co-opted into the neoliberal discourse of the ‘creative industries.’21 In this discourse, creative practice is only ever framed in terms of digital-technological innovation in an ‘open economy.’22 As such, coding literacy becomes something of a technocratic obsession, one taken for granted as worthwhile and sensible in and of itself. Indeed, many artists who make work with and about digital media might be familiar with the fatiguing task of reimagining themselves as entrepreneurial subjects in a realm of proliferating cultural startups, competing with one another for essential yet increasingly scarce funding streams. Within this logic, and echoing somewhat the imperatives of Cold War America’s research campuses mentioned above, the ‘play’ in arts practices such as creative coding becomes at risk of being increasingly instrumentalised toward the production of ‘disruptive’ and ‘agile’ tech. An illustrative case in point here is Google’s own misguided attempt in 2014 to obfuscate the long, multivalent history of the computational arts behind the singular, brandable neologism ‘DevArt’—a venture that attracted considerable ire and debate amongst digital media arts communities online.23

One effect of this increasing tilt toward industry is that the argument for coding literacy is legitimised through an imperative to produce viable economic actors for the 21st century. Digital media artists are taught programming workflows that perhaps happen to be open source alongside proprietary commercial software packages for image processing and video editing, without much consideration for how or why we might wish to envisage the messy new imaginaries of computational-cultural production that Soon and Cox call for.

Framing coding skills in terms of ‘employability’ and ‘industry-readiness’ may have a boring-dystopia logic when, in the aftermath of a period of sustained assault on cultural funding, technical fluency in mainstream software packages can be converted into a gig-based revenue stream for early-career practitioners. Nevertheless, I might suggest that proclaiming allegiance to Creative Cloud while accepting precarity is not a wholly satisfactory compromise. In any case, commercial proprietary software presents considerable and often immediate frictions to creative media arts education. As Mansoux and de Valk note in FLOSS+Art,24 the continuous intrusion of update cycles and aggressively-priced licensing plans that come with proprietary software generate problems for the production and maintenance of digital media artworks, not to mention a dependency on expensive and highly-DRMed software subscriptions.

Aesthetic Programming maintains a commitment to the spirit of cooperation and collaboration central to FLOSS, enacted not only through the way the code contained within is shared and made accessible, but in the design and publication of the book itself as a ‘dynamic object.’25 They write:

[FLOSS] development is a collective practice that challenges the normative relations of production associated with commercial development, such as a narrow definition of authorship and copyright, and fixed divisions of labour.26

The role of the design agency Open-Source Publishing (OSP) in the design of the book enacts, extends, and plays with these conceptual issues. The book was collaboratively written and formatted through code (Markdown), and managed using the version-control system Git—and indeed the authors use the word ‘Git’ to open up a bigger discussion about the problematic terminologies embedded in programming.27 OSP chose fonts rooted in material and technical problems in the history of computing: a font originally designed to work within the limitations of vector plotters, for instance, and another intended to be readable by ‘both machines and humans.’28 The workflow through which the book has been written, compiled, designed, and published is a conceptually coherent and collaborative process that reflects and accentuates the politics laid out in the content.

Extremely Online

It must be said that the task of constructing this conceptual coherence across mediums, pedagogic strategies, and theoretical content is extraordinarily challenging, requiring considerable time and expertise to devise and maintain. This has been even more true over the past year where, amidst the extreme crisis of the global pandemic, lecturers prepared to adapt significant portions of teaching and learning to whatever virtual learning environment their institution opted to purchase a subscription to. The sudden dominance of platforms such as Microsoft Teams and Zoom has precipitated what might well be the greatest incursion of big tech corporations into the mediation of higher education thus far. Setting aside the technical and aesthetic idiosyncrasies of these platforms (very much worthy of critical study in themselves), both Teams and Zoom have been widely criticised in the news media for reproducing problems that are routinely scrutinised within software studies. Teams has been criticised for facilitating new and pervasive modes of employee surveillance, generating ‘productivity scores’ in the spirit of digital Taylorism.29 Meanwhile, Zoom has been described by security researchers as ‘malware’ and a ‘privacy disaster.’30

I’d like to suggest, however, that when it comes to thinking about the pedagogical strategies and modalities through which subjects like creative coding are taught, this point of crisis also presents an opportunity for a radical rethink of how play might be redeployed as part of a critical praxis. With Aesthetic Programming, Soon and Cox offer a rich, inventive, and original means to do so in a manner that encompasses multiple dimensions: the book object with its reflexive processes of collaborative authorship, design, and publication; in theorising while() practising; and in the design of code examples and exercises that activate and open up opportunities for creative problematisation.

In its distinctive approach to software art, it presents a curriculum that is at its core playful and speculative yet also critically reflective of the structural, and structuring, capacities of software. In this sense, it presents the possibility of developing a critical praxis that employs ‘play’ in a politicised, subversive, and reflexive manner—one that presents richly imagined possibilities for investigating formations of power and knowledge in computational culture. At a point where such formations are undergoing rapid and extreme reconfiguration and normalisation, the invention of new curricula where the theory and practice of code are thoroughly and mindfully entangled only become more urgent.


Author biography

David Young is a researcher interested in archiving media technologies, histories of computing, and the culture of defence research in the United States during the Cold War. He is a lecturer in Media Arts at Royal Holloway, where he teaches creative coding, history of digital media, and data visualisation.



  1. Matthew Fuller, ed., Software Studies: A Lexicon (Cambridge, MA: MIT Press, 2008).
  2. Soon and Cox, Aesthetic Programming: A Handbook of Software Studies (London: Open Humanities Press, 2020).
  3. Fuller, Software Studies, 2.
  4. Soon and Cox, Aesthetic Programming, 13.
  5. Ibid., 14.
  6. Ibid., 30.
  7. Olga Goriunova, ed., Fun and Software. Exploring Pleasure, Pain and Paradox in Computing (London: Bloomsbury, 2014).
  8. Jacob Gaboury, “A Queer History of Computing: Part Three”, Rhizome (April 2013);
  9. Gene Youngblood, Expanded Cinema (E P Dutton, 1970), 208.
  10. Christian Ulrik Andersen, “Monopoly and the Logic of Sensation in Spacewar!” in Fun and Software, ed. Olga Goriunova
  11. Orit Halpern, Beautiful Data: A History of Vision and Reason Since 1945 (Durham: Duke University Press Books, 2015), 122–25.
  12. Rainer Usselmann, “The Dilemma of Media Art: Cybernetic Serendipity at the ICA London”, Leonardo (2003), 393;
  13. John Maeda and Red Burns, Creative Code (London: Thames and Hudson, 2004).
  14. Casey Reas and Ben Fry, “Processing: Programming for the Media Arts”, AI & SOCIETY 20, no. 4 (September 2006), 529,
  15. Inke Arns, “Read_me, Run_me, Execute_me” Media Art Net (February 2007);
  16. Casey Reas and Ben Fry, Processing: A Programming Handbook for Visual Designers and Artists (Cambridge, MA: MIT Press, 2007).
  17. Daniel Shiffman, The Nature of Code: Simulating Natural Systems with Processing (2012),
  18. Lauren McCarthy, Casey Reas, and Ben Fry, Getting Started with P5.js: Making Interactive Graphics in JavaScript and Processing (Make Community, LLC, 2015).
  19. Lauren McCarthy’s statement on p5.js on her website;, n.d.
  20. Soon and Cox, Aesthetic Programming, 16.
  21. Geert Lovink and Ned Rossiter, MyCreativity Reader: A Critique of Creative Industries (Amsterdam: Institute of Network Cultures, 2008).
  22. See for instance the UK government document “Build Back Better: Our Plan for Growth” published in March 2021.
  23. Georgina Voss, “DevArt: Google’s Powerful New Move to Arts Patronage”, The Guardian (February 2014);
  24. Aymeric Mansoux and Marloes de Valk, eds., FLOSS+Art (Poitiers, France: OpenMute, 2008), 9–13.
  25. Soon and Cox, Aesthetic Programming, 12.
  26. Ibid., 17.
  27. Ibid., 44.
  28. Ibid., 25.
  29. Rachel Sandler, “Microsoft’s New ‘Productivity Score’ Lets Your Boss Monitor How Often You Use Email and Attend Video Meetings”, Forbes  (November 2020).
  30. Kari Paul, “‘Zoom Is Malware’: Why Experts Worry About the Video Conferencing Platform”, The Guardian (April 2020).