Preface

What kind of book is this?

As indicated by its subtitle, this book is meant to be a handbook of sorts, but not in any conventional sense of it being a prescribed set of technical instructions.1 It is not meant to be read to simply learn to code nor to offer critical reflection upon the practice of coding alone, instead it offers something more messy and at the same time more “useful” we would say: a book about the more complex and deeply entangled set of relations between writing, coding and thinking.2

Most programming books are written with the primary objective of teaching readers how to learn a programming language to become a good (or better) programmer, with an emphasis on state-of-the-art technology, as well as practical examples that are explained and then designed to be deployed in technology-related or creative industries. Not many programming books address the cultural and aesthetic dimensions of programming as a means to think and act critically.3 Emerging trans-disciplinary fields involving computational technology — such as software studies, platform studies, and digital humanities to an extent — incorporate the practice of programming into the object of study, yet little practical detail is provided in terms of putting programming into a critical perspective, especially for those studying non-technical or non-scientific disciplines. This book attempts to address this gap between available literature and the growing interest in “computational thinking”4 to expand programming beyond the confines of computer science or software engineering (or even the digital humanities, which ultimately presents another set of limitations). We consider our approach to be distinctive from other books in this regard, as well as from other theoretical books in which source code becomes an illustration of the programmer’s thinking or a too-easy analogy for the hidden layers of operations (if not ignored altogether).

Whilst operating broadly in the spirit of Software Studies,5 the book offers an applied and overtly practice-based approach to understanding the importance of programming — reading, writing and thinking with software — as a critical tool for our times, in recognition of the way in which our experiences are ever more programmed. It is offered as a deep learning “tool” in its widest sense — a handbook for those unaccustomed to programming — that allows for the programmer’s conceptual skills to develop as they become technically more proficient.

To reiterate the point, our intention is for readers to acquire key programming skills in order to read, write and think with, and through, code (and we will return to the issue of literacy later). We feel that it is important to further explore the intersections of technical and conceptual aspects of code in order to reflect deeply on the pervasiveness of computational culture and its social and political effects — from the language of human-machine languages to abstraction of objects, datafication and recent developments in automated machine intelligence, for example. In other words, 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.

Alongside learning to program, we aim to bridge the gap between theories of computational culture, aesthetics and cultural studies. As part of this, we take a particular interest in power relations that are under-acknowledged, such as inequalities and injustices related to class, gender and sexuality, as well as race and the enduring legacies of colonialism.6 This is not only related to our own subject-positions and cultural backgrounds (see our biographies for more on this) and a politics of representation (the contested space between the subject and the representation of the subject), but also to how power differentials are implicit in code in terms of binary logic, hierarchies, naming of attributes, accessibility, and how wider societal inequalities are further reinforced and perpetuated through non-representational computation. In short, the handbook introduces and demonstrates a distinctive approach to the reflexive practice of what we call “aesthetic programming” as we explain and perform it, and to how it constitutes us as subjects.

Why aesthetic programming?

The argument the book follows is that computational culture is not just a trendy topic to study to improve problem-solving and analytical skills, or a way to understand more about what is happening with computational processes, but is a means to engage with programming to question existing technological paradigms and further create changes in the technical system. We therefore consider programming to be a dynamic cultural practice and phenomenon, a way of thinking and doing in the world, and a means of understanding some of the complex procedures that underwrite and constitute our lived realities, in order to act upon those realities.

The phrase “aesthetic programming” usefully describes this approach in our opinion. We claim a certain distinctiveness in this, but of course aesthetic programming is close to other phrases such as “creative coding” and “exploratory programming” that have been introduced in related literature in recent years to emphasize the expressivity of computer programming beyond something pragmatic and functional, in which cultural production, or critical thinking using the practice of programming, can be developed from the broad perspective of the arts and humanities.7 It should be explained that the title “aesthetic programming” actually derives from one of the undergraduate courses of the Digital Design degree program at Aarhus University in Denmark, which has been taught in parallel to a course in Software Studies since 2013. Taken together, as they were designed, these courses offer ways of thinking with software to understand wider political and aesthetic phenomena.8 We follow the principle that the growing importance of software requires a new kind of cultural thinking, and curriculum, that can account for, and with which to understand better, from within, the politics and aesthetics of algorithmic procedures, data processing, and abstracted modeling. The book’s structure largely emerges from the experience of teaching these courses and we owe gratitude to all our students and fellow teachers for their valuable contributions and critical feedback along the way.9

Continuing the discussion of aesthetics, it should be clear that we do not refer to ideas of beauty as it is commonly misunderstood (aka bourgeois aesthetics), but to political aesthetics: to what presents itself to sense-making experience and bodily perception (to paraphrase Jacques Rancière’s The Politics of Aesthetics, as one key reference).10 How we perceive the world in this political sense is not fixed, but is in constant flux, much like software itself and bound to wider conditions, and ecologies.

Political aesthetics refers back to the critical theory of the Frankfurt School, particularly to the ideas of Theodor Adorno and Walter Benjamin, that enforce the concept that cultural production — which would now naturally include programming — must be seen in a social context. Understood in this way programming becomes a kind of “force-field” with which to understand material conditions and social contradictions, just as the interpretation of art once operated “as a kind of code language for processes taking place within society.”11 The much-cited essay by Benjamin on technical reproducibility has become a touchstone for collapsing some myths of artistic production including the dismantling of the aesthetic experience of “aura” (the mark of an artwork’s authenticity and originality).12 It is also worth remembering that Adorno and Benjamin famously disagreed on the consequences of this destruction of aura: whilst Benjamin expressed the positive aspects of this shift and viewed the destruction of aura as a kind of political emancipation, Adorno expressed the negative view that standardization and pseudo-individuality would follow. It would seem that both tendencies have accelerated with computational culture, hence the continuing need for sharp critique, and one also based along the lines of “immanent criticism,” that which is inherent, as it operates within its object, in the inner workings of software and its material conditions.13 Yet it remains in question as to what extent these old (white, male) references are up to the task of unpicking the complexity of computational operations, and address the ways in which most people use computers or think about them. This is as much to do with what aesthetic programming is becoming as to what it is or was, and why we still take our point of departure from such references, also aware that they perpetuate problems in themselves, and require alternatives.

If everything is in flux, as it would seem, then we also need to be sensitive to our received methods, based as they are on Western traditions of knowledge production, and notions of progress, rooted as it is in European colonialism and extraction practices.14 We find the work on Anna Lowenhaupf Tsing useful in this regard as it offers a feminist perspective in which indeterminacy is taken more seriously to reflect the precarity of lived conditions.15 Not only are our theories of history and technology bound up with this but also critical practices and other nonhuman imaginaries. Other ecologies open up ways of thinking that are multidirectional, across times and scales, more open-ended and indeterminate, based on ideas of “assemblage,” as Tsing puts it.16 We don’t look to mushrooms for inspiration as she does, but to the immanent and relational qualities of technology itself. More precisely we have been working with fundamental programming concepts, such as geometry and object abstraction; loops and temporality; data and datafication; variables, functions, and their naming, as well as data capturing, processing and automation, as the starting point for further aesthetic reflection whereby the technical functions set the groundwork for further understanding of how cultural phenomena are constructed and operationalized.

Aesthetic programming in this sense is considered as a practice to build things, and make worlds, but also produce immanent critique drawing upon computer science, art, and cultural theory. From another direction, this comes close to Philip Agre’s notion of “critical technical practice,” with its bringing together of formal technical logic and discursive cultural meaning.17 In other words, this approach necessitates a practical understanding and knowledge of programming to underpin critical understanding of techno-cultural systems, grounded on levels of expertise in both fields (as in the case of Wendy Hui Kyong Chun or Yuk Hui, for example, who have transdisciplinary expertise18). Such practical “knowing” also points to the practice of “doing thinking,”19 embracing a plurality of ways of working with programming to explore the set of relations between writing, coding and thinking to imagine, create and propose “alternatives.”20 By engaging with aesthetic programming in these ways, we aim to further “queer” the intersections of critical and technical practices as in the many examples we refer to in this book (see “List of Projects,” and exemplified by our references to Winnie Soon’s work throughout), and to further discuss power relations that are relatively under-acknowledged in technical subjects. We hope to encourage more and more people to defy the separation of fields and practices in this way.

And software studies?

As stated, we draw heavily upon the field of Software Studies, and to an extent Critical Code Studies — the work of Wendy Chun, Matthew Fuller, Mark Marino, and others, including our own earlier work — to deal with and communicate knowledge of software as a cultural form via analyses of examples of software artefacts and close readings of theoretical texts and source code. In terms of approach we take our inspiration largely from Fuller’s Software Studies: A Lexicon from 2008, structured literally as a lexicon of key terms, it in turn taking its cue from the Raymond Williams’s Keywords: A Vocabulary of Culture and Society first published in 1958.21 In many ways, and simply put, our book can be thought of adopting a similar approach of zooming in to the formal logic of computation and zooming out to the cultural implications of software. In this respect it is also important to recognize that the book Software Studies derived from a provisional workshop, and it is worth quoting the project page for its clarity of intention:

[T]he project aims at folding the internalist/externalist question of science studies inside out, the mechanisms of the one conjugating the subject of the other: what does software-enabled scholarship, in software, art, and literary practice have to say about its own medium? The purpose of this interaction is therefore not to stage some revelation of a supposed hidden truth of software, to unmask its esoteric reality, but to see what it is and what it can be coupled with: a rich seam of paradoxical conjunctions in which the speed and rationality of computation meets with its ostensible outside.”22

We believe that paying attention to fundamental, or key, concepts from programming provides the opportunity to open up new insights into aesthetics and critical theory, as well as new perspectives on cultural phenomena increasingly bound to computational logic. In this way, although aware that we inhabit the problem, we think it important to work in this way, from the inner workings of software and its material conditions. By extending the discussion beyond formal logic to its outside, we also emphasize the usefulness of artistic practice for opening up more speculative, alternative, and messy imaginaries. In this spirit, and in keeping with the development of software studies in Europe at least, we take inspiration from what has been referred to as “software art” (although admittedly the category was only meant as a placeholder) or “computational art.”23 That we draw upon examples from artistic (and critical design) practices as part of our argument, stresses our point that programming is not simply a practical tool that produces an artwork, but is a critical-aesthetic object24 in itself. Curator Inke Arns neatly clarifies this:

‘Software art’ […] refers to artistic activity that enables reflection of software (and software’s cultural significance) within the medium – or material – of software. It does not regard software as a pragmatic aid that disappears behind the product it creates, but focuses on the code it contains – even if the code is not always explicitly revealed or emphasized. Software art, according to Florian Cramer, makes visible the aesthetic and political subtexts of seemingly neutral technical command sequences. Software art can base itself on a number of different levels of software: source code level, abstract algorithm level, or on the level of the product created by a given piece of code.”25

We would argue something similar for this book. Moreover, in order to discuss the aesthetic dimensions of code and computational processes, we incorporate artistic works that explore the material conditions of software and the operations of computational processes as practical and theoretical examples. They are an integral part of our argument in other words, as well as serve to demonstrate some of the ideas in practice and offer unexpected epistemic insights. We might add, repeating what has already been introduced, that we are not simply interested in a critical aesthetics of programming but also programming as critical aesthetics.

Open publishing

More to the point, text is in code (in the ways that it is made human-readable) and code is in text (in the use of the text editor, interfaces and online platforms we use to render these thoughts). There is more to say on this, and we will return to these issues across the various chapters of the book, each following the logic of fundamental programming concepts. Suffice to say for now, that the book sets out to express how writing and coding are deeply entangled, and how neither should be privileged over the other: we learn from their relationality. Writing code and writing about code are forced together in ways that reflect broader cultural and technical shifts in data practices and open publishing initiatives, and, moreover, emphasize that writing a book is necessarily a work in progress. Like software, this is a book to be read, and acted upon, shared and rewritten.

There are clearly many precedents for such an overtly collaborative approach to software production, and clearly, free and open source principles underscore our thinking. It is worth emphasizing that FOSS 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 labor, which can be extended to the production of books and the associated reputation economy of academic publishing. However, we also recognize that the release of source code and open access books represents a number of ambiguities related to the sharing economy, free market capitalism, and opportunities to capitalize on free labor. We persist in the hope that our efforts challenge reductive logic, and our publisher, Open Humanities Press, broadly reflects FOSS principles of transparency and reproducibility in its commitment to open access for scholarly work.26 As such, this book can be downloaded for free or purchased as a hard copy at a reasonable price.

This is nothing particularly original. We acknowledge there are numerous other experimental publishing initiatives and even “anti-platforms” for decentralized article publishing.27 There are also plenty of other examples that have picked up on the perversity of writing books about programming where you have to type out the examples to run them, and live coding platforms demonstrate alternatives (e.g. Jupyter Notebook or DevDocs28). Our use of print and an associated software repository is our way of managing this problem. This has also informed our choice of designers for the book: Open Source Publishing collective (OSP) design using only free and open source software — “pieces of software that invite their users to take part in their elaboration,” as they put it29 — and make all files freely available using a Git versioning system that contains all the files for the project, distributed under the terms of Version 2 of the GNU General Public License. The following chapter introduces this in more detail.

In brief, the use of a Git repository for our writing further emphasizes FOSS working principles, and, by treating writing as software, or indeed software as writing, allows us to formalize the production of the book as an iterative process, in need of timely updates, allowing for forking and endless reversioning. By allowing new versions to be produced by others, we hope in a modest way to challenge commercial publishing conventions and illuminate our capacity to understand some of the infrastructures through which we encode our ideas and distribute them across networks. We believe that this way of working marks a departure point for collectively engaging with programming and creating changes in the social-technical systems (both inside and outside). We aim to do something similar to what Adrian Mackenzie has identified as “auto-archaeology” to indicate how the object of study is fully integrated into the analysis, which he demonstrated using the associated GitHub site for his 2017 book Machine Learners.30 This helps us as readers to understand something of the iterative process of writing a book about code in the spirit of how software developers collaborate, host, review, and merge code, as well as build software together.31

Flow of contents

Throughout this book, we use JavaScript as the main programming language with a primary focus on the open source and web-based library called p5.js, which already comes with a comprehensive and accessible resource for beginners to learn programming (more details will be included in chapter 1, “Getting started”). Our resource combines the aquisition of technical knowledge as a necessary part of doing critical work, all part of learning to program in its widest sense, programming as doing and thinking, as world-making.

Each chapter of the book starts with a flowchart32 to provide a “diagram” of entangled relationships between the formal/technical and aesthetic/conceptual aspects of its contents. Each captures the dynamic (learning) processes in both concrete and abstract representation for thinking with, especially the relations between the stage setup as expressed in the section “setup(),” starting point as expressed in “start(),” artefacts and sample code as expressed in “Source code,” formal and discursive activities concerning code and syntax as expressed in “Exercises and discussion in class,” and the further extended discussion as expressed in “While().” If a flowchart is conventionally used as an aid to the design of computational processes both for technical understanding and communication,33 then we also consider critical reflection to be an integral part of that process. Indeed, the flowchart serves as the starting point to exemplify our approach of turning concepts “inside out” and the need to understand computational and programmable objects, relations, and processes in both logical and discursive forms.

Beginning with the first chapter, “Getting started,” we illustrate the tools and environments that are required to use the book. The chapter is a guide to making your first program as a means to think through the notion of literacy, both in terms of writing code (RunMe) and writing about code (ReadMe). Chapter 2, “Variable geometry,” explores the use of variables, and the drawing of geometric shapes, sizes, positions, space, and so on, to connect to the discussion of emojis and the politics of representation they invoke. Chapter 3, “Infinite loops,” moves from static to moving objects using different syntaxes for transformation. Using the graphical spinning wheel icon of a preloader, we learn about conditional statements, loops, and time-related syntaxes, to reflect on how technologies play a crucial role in our experience of time. Chapter 4, “Data capture,” introduces how a program captures and processes input data (via audio and webcam devices, mouse and keyboard press, as well as customizable and clickable buttons), and further discusses the consequences of capture and datafication. Chapter 5, “Auto-generator,” focuses on how rules and instructions are performed, and how they can produce unexpected and/or complex results in generative systems, and produce emergent/queer life forms. At this point the book becomes more technically complex, and chapter 6, “Object abstraction,” introduces object-oriented programming in which customizable properties and behaviors of objects are introduced, alongside a discussion of the movement between abstract and concrete reality. Chapter 7, “Vocable code,” pays close attention to notation and computational structure, exploring the poetic relationships between program code and natural language. With a particular focus on voice, we reflect on how the human subject is implicated in coding practices and how coding itself can voice wider political issues. Engaging with the real-time query of an Application Programming Interface (API), chapter 8, “Que(e)ry data,” takes a closer look at how to request and acquire data, exploring how information processing is coupled with data selection, normalization, extraction, transmission, and presentation. As such, we gain an insight into the politics of a query-driven society and the ways in which search engines produce knowledge in compromized forms. Working towards the end of the book, chapter 9, “Algorithmic procedures,” does not focus on code syntax, but instead how we can break down the procedural operations of an algorithm into a logical form. It introduces flowcharts as a means to unfold the practical and conceptual aspects of algorithms, and to explore the political consequences of procedural operations (a strategy adopted to map each chapter, as mentioned above). The last chapter, “Machine unlearning,” introduces machine learning algorithms to explore the implications of training, teaching, and learning in general, drawing together many of the issues across the chapters, and operating as a further reflection on the purpose of the book as a learning tool. But this is not simply didactical, and we offer a bonus chapter in the form of an “Afterword: Recurrent Imaginaries,” a machine-generated chapter based on the contents of the book, on what has been learnt, and what might be unlearnt. In summary, the first six chapters set up the ground from which to understand the fundamental elements of programming, and the last four chapters build upon this towards more speculative forms and imaginaries.

Creative practice is at the forefront of our approach. Every chapter comes with an example that utilizes different technical syntax, facilitating the discussion of the formal aspects of code. But beyond that, we also have experienced in our teaching that students, especially beginners, have difficulty in putting different functions together in a sketch. Although each chapter builds on others, we have found that it is important to repeat the use of syntax and to show how different functions and syntax can be combined and used in multiple ways. Most individual functions can be found using the p5.js reference page or are available in other instructional online videos,34 however we stress the importance of how to bring making and thinking together. Our examples are developed with this in mind and increase complexity across the chapters, and each sketch has around one hundred lines of code for relative ease of comprehension. It should be said that we do not take effective and efficient code to be a priority here and sometimes twist the expected use of syntax accordingly. Indeed we do not aim to offer a comprehensive list of the core p5.js functions like many other programming books, but rather we offer ways of explaining the syntax according to the examples that we have selected and for their ability to generate further discussion. Our examples, inspired by other artists, designers, scientists and theorists, are custom-made according to the perceived pace of learning and their critical potential, with the incorporation of syntax and features that are closely aligned to the corresponding focus of the chapter. Examples are thus provided to spark both the technical and conceptual discussion in and outside of the classroom, including the mini exercises (aka “miniX”) that we have set out for each chapter.

Using the dual elements35 of “RunMe” and “ReadMe” to cultivate reflection by writing code and writing about code, students are encouraged to question the application of their learning in the making of artefacts. Using the pedagogic principle of “low floors, high ceilings,”36 students can easily get started with the materials in the book but each miniX also encourages independent learning by addressing the theme openly instead of looking for a prescribed outcome. We introduce various set and open tasks as well as questions throughout the chapters to test the limits of what is known at any point in time. When it comes to practice and iterative learning, we have also included peer-feedback for every miniX so as to encourage peer learning through reading other people’s code,37 and to further emphasize the diversity of approaches as well as the value of sharing ideas in public, like a shared recipe. The analogy to cooking is something we have adopted in the book by making conceptual parallels between, for example, variables and kitchen containers, algorithms and recipes, and so on. We take inspiration here from our book designers Open Source Publishing who have extensive experience of running workshops for beginners, and adopt their use of kitchen metaphors: drawing together practices of coding and cooking, tasting and testing, to invite further experimentation with various ingredients: “In the OSP kitchen, source files = ingredients.”38

What we have attempted to outline follows the principle of “situated knowledge,” in the sense that what we offer reflects the particular conditions in which it was produced, and the situatedness of the knowledge producers (us, as well as the students we have worked with).39 Specifically, the book has been developed over the past five years through the actual setting of classroom teaching and assignments, in a very specific cultural and educational context, situated within an educational degree program in the humanities with a focus on software studies. Students mostly have had no prior programming experience. The course has run for fourteen classes with blocks of eight and three contact hours every week — for Aesthetic Programming and Software Studies respectively. Though we offer ten main chapters here, in practice40 we provide a “pause week” to slow things down by not introducing new functions and syntaxes, instead revisiting previous ones and discussing what constitutes aesthetic programming, and how this links to their weekly practice and learning. We also have project weeks for preparation towards the final assessed submissions. Some flexibility is recommended if you are following this book for your own curriculum and clearly the intention is for readers to adapt, modify and re-arrange the contents to suit their purposes and the particularity of the context in which they work. Our contents are offered as an open resource, to open up different possibilities for making “cuts” across the various materials and ideas,41 and to encourage readers to fork a copy and customize their own versions, with different references, examples, reflections and new chapters for example, for further modification and re-use.42 Thus, adopting the words of Jennifer Gabrys, our project is “an invitation to make, organize, orchestrate, conjure, and sustain people, technology, and worlds toward openings rather than prescribed ends.”43

The book object

Finally we would like to stress that this book is not simply the physical object that you might be holding in your hands as you read these words, but a computational and networked object, distributed across various other spaces and temporalities, made available to both readers and writers alike. In saying this we reference Benjamin again, and his essay “The Author as Producer” in which he writes: “The reader is always prepared to become a writer, in the sense of being one who describes or prescribes. […] And writing about work makes up part of the skill necessary to perform it. Authority to write is no longer founded in a specialist training but in a polytechnical one, and so becomes common property.”44 Interestingly, for Benjamin, as with this book, cultural production requires a pedagogic function.

That is precisely our point. The book expresses itself as a dynamic object not fixed in terms of attribution or commodity form or specific determination. It follows that, although this preface is only the beginning of the book, there can be no end: this book is purposefully stuck in an endless loop of its own becoming.

Notes


  1. The casual address “for dummies” could also be used, as it has been for many technical books, but this carries the unfortunate connotation of learning disability. 

  2. The book aims to provide some “useful knowledge.” Here we refer to nonstandard literacy, such as in the article: Marilyn M. Cooper, “Really Useful Knowledge: A Cultural Studies Agenda for Writing Centers,” The Writing Center Journal 14, N°2 (Spring 1994): 97-111, https://jstor.org/stable/43441948

  3. Mark Guzdial suggests there are other purposes for programming beyond the normative focus on economic impact and the development of professionals for the software industry that open up various possibilities for learning and teaching programming. See Mark Guzdial, “Computing for Other Disciplines,” in The Cambridge Handbook of Computing Education Research, Sally A. Fincher and Anthony V. Robins, eds. (Cambridge: Cambridge University Press, 2019), 584, https://doi.org/10.1017/9781108654555.020

  4. Seymour Papert’s influential book Mindstorms from 1980 introduced computing to children’s learning. He coined the term “compututional thinking” to emphasize the practice of constructing procedures with the early programming language Logo (which does not simply use software as a tool), aiming to bridge the gap between mathematics, the culture of science and education as well as social critique. Donald Knuth made the concept of literacy more apparent in the book Literate Programming and considered a program literature which involves viewing programming languages as natural languages for human readers. In recent years the notion of computational thinking was also picked up by scholars in the field of software studies, such as David Berry, Matthew Fuller, Nick Montfort and Annette Vee. See Seymour Papert, Mindstorms; Children, Computers and Powerful Ideas (New York: Basic Books, 1980); Donald Ervin Knuth, Literate Programming CSLI Lecture Notes, N°27 (Stanford, CA: Center for the Study of Language and Information, 1992); Jeannette M. Wing, “Computational Thinking,” Commun. ACM 49, N°3 (March 2006): 33–35; Michael, Mateas, “Procedural Literacy: Educating the New Media Practitioner,” Horizon 13, N°2 (June 1, 2005): 101–11; David M. Berry, and Anders Fagerjord, Digital Humanities: Knowledge and Critique in a Digital Age (Hoboken, NJ: John Wiley & Sons, 2017); Matthew Fuller, How to be a Geek: Essays on the Culture of Software (Cambridge: Polity Press, 2017); Nick Montfort, Exploratory Programming for the Arts and Humanities (Cambridge, MA: MIT Press, 2016); Annette Vee, Coding Literacy: How Computer Programming Is Changing Writing (Cambridge, MA: MIT Press, 2017); Ole Sejer Iversen, Rachel Charlotte Smith and Christian Dindler, “From computational thinking to computational empowerment: a 21st century PD agenda,” Proceedings of the 15th Participatory Design Conference Full Papers - Volume 1, N°7 (August 2018): 1-11. 

  5. Software studies is an interdisciplinary research field that studies software and its social and cultural effects, see Matthew Fuller, ed. Software Studies: A Lexicon (Cambridge, MA: MIT Press, 2008). 

  6. See, for instance, Syed Mustafa Ali’s “A Brief Introduction to Decolonial Computing,” XRDS: Crossroads, The ACM Magazine for Students 22, N°4 (2016): 16–21. 

  7. Here we are referring to John Maeda, Creative Code: Aesthetics + Computation (London: Thames & Hudson, 2004); Kylie A. Peppler and Yasmin B. Kafai, “Creative coding: Programming for personal expression,” The 8th International Conference on Computer Supported Collaborative Learning (CSCL) 2 (2009): 76-78; Montfort, Exploratory Programming for the Arts and Humanities; Noah Wardrip-Fruin, Expressive Processing: Digital Fictions, Computer Games, and Software Studies (Cambridge, MA: MIT Press, 2012). 

  8. Our blend between formal logic and conceptual thinking is designed to open up space for further reflection. As one of our students commented in 2018, “Aesthetic Programming was not just programming 1.1, but instead a much more reflective and critical course.” And from student feedback from the 2019 course, a student commented that the course structure provides “a hands-on experience with coding as a practice as well as a theoretical approach. […] It was great to see behind the code and try to decode the greater picture in a digital culture context.” 

  9. Special mention should be made of Magda Tyżlik-Carver and Christian Ulrik Andersen who have contributed to the teaching of these courses, as well as teaching assistants including Frederik Westergaard, Nils Rungholm Jensen, Tobias Stenberg, Malthe Stavning Erslev, Ann Karring, Simone Morrison, Nynne Lucca Christianen, Ester Marie Aagaard, and Noah Aamund. 

  10. Jacques Rancière, The Politics of Aesthetics (London: Continuum, 2006), investigates what aesthetics and politics have in common: according to Rancière, the delimitation of the thinkable and the unthinkable, the possible and the impossible. 

  11. The quote continues, “which must be deciphered by means of critical analysis,” in Martin Jay, Aesthetic Theory (Minneapolis, MN: University of Minnesota Press, 1996), 177. 

  12. To quote Benjamin on this point: “The instant the criterion of authenticity ceases to be applicable to artistic production, the total function of art is reversed. Instead of being based on ritual, it begins to be based on another practice - politics.” Walter Benjamin, “The Work of Art in the Age of Mechanical Reproduction” [1936], Selected Writings, Volume 3, 1935–1938, Howard Eiland and Michael W. Jennings, eds. (Cambridge, MA: Belknap Press of Harvard University Press, 2002). 

  13. Adorno says it better: “A successful work of art, according to immanent criticism, is one that resolves objective contradictions in a spurious harmony, but one expresses the idea of harmony negatively by embodying the contradictions, pure and uncompromised, in its innermost structure” (Adorno, in Prisms (1967), 32; quoted in Jay, Aesthetic Theory, 179). 

  14. Black and indigenous aesthetics would make an important addition here, such as found in Ron Eglash’s African Fractals, as would reference to Afrofuturism, not to simply insert black voices into racist historical narratives, but to envision new imaginative forms. See, Ron Eglash’s African Fractals: Modern Computing and Indigenous Design (New Brunswick, NJ: Rutgers University Press, 1999), and, for instance, Kodwo Eshun’s “Further Considerations on Afrofuturism.” CR The New Centennial Review 3, no.2 (2003): 287-302. 

  15. Anna Lowenhaupf Tsing, The Mushroom at the End of the World: On the Possibility of Life in Capitalist Ruins (Princeton: Princeton University Press, 2015). 

  16. Tsing, The Mushroom at the End of the World, 23. 

  17. Philip E. Agre, “Toward a critical technical practice: Lessons learned in trying to reform AI,” in Geoffrey Bowker, Susan Leigh Star, William A Turner, William Turner, Les George Gasser, eds., Bridging the Great Divide: Social Science, Technical Systems, and Cooperative Work (ACM Digital Library, 1997). https://dl.acm.org/doi/book/10.5555/549261

  18. Wendy Chun has studied both Systems Design Engineering and English Literature, which she combines and mutates in her current work, see https://en.wikipedia.org/wiki/Wendy_Hui_Kyong_Chun. Yuk Hui studied both Computer Engineering and Philosophy, see http://digitalmilieu.net/yuk/

  19. The notion of “doing thinking” suggests non-standard ways of knowing that draws upon artistic research and technofeminism in computing. See Loren Britton, Goda Klumbyte, and Claude Draude, “Doing Thinking: Revisiting Computing with Artistic Research and Technofeminism.” Digital Creativity 30, N°4 (October 2, 2019): 313–28, https://doi.org/10.1080/14626268.2019.1684322

  20. Agre, “Toward a critical technical practice”. 

  21. Fuller, ed. Software Studies; Raymond Williams, Keywords: A Vocabulary of Culture and Society (London: Fontana, 1983); updated by Blackwell in 2005 as New Keywords: A Revised Vocabulary of Culture and Society

  22. The project workshop description an be found archived at https://web.archive.org/web/20100327185154/http://pzwart.wdka.hro.nl/mdr/Seminars2/softstudworkshop

  23. We were highly influenced by the series of Readme festivals that promoted the artistic and experimental practice of software, which took place at the Marcros-Center in Moscow (2002), Media Centre Lume in Helsinki (2003), Aarhus University and Rum46 in Aarhus (2004), and HMKV in Dortmund (2005). The associated software art repository Runme.org was established in 2003, and many participants and people who submitted their works did not necessarily call themselves artists. Indeed the category of art in itself becomes inadequate to cover the kinds of creatives practices that have developed in the field. As an annual festival for art and digital culture, transmediale had started to use ‘artistic software’ or ‘software art’ from 2001-2004. Many artists and researchers have contextualized and written about the genre of software art, see Florian Cramer, and Ulrike Gabriel, “Software Art,” American Book Review, issue “Codeworks”(Alan Sondheim, ed.) (2001); Goriunova, Olga, and Alexei Shulgin. read_me: Software Art & Cultures (Aarhus: Aarhus Universitetsforlag, 2004); Andreas Broeckmann, “Software Art Aesthetics,” Mono 1 (2007): 158-167. 

  24. The field Critical Code Studies (CCS) makes this explicit, promoting the examination of source code as a cultural object for critical analysis. As Mark Marino suggests that CCS pays attention to code as textual materials and its main argument is that code itself can be considered as a “cultural text worthy of analysis and rich with possibilities for interpretation”, and furthermore, code allows one to reflect “on the relations between the code itself, the coding architecture, the functioning of code, and specific programming choices or expressions, to that which it acts upon, outputs, processes, and represents”. See Mark C. Marino, “Critical Code Studies”, Electronic Book Review (December 4, 2006); “Field Report for Critical Code Studies,” Computational Culture 4 (9th November 2014), http://computationalculture.net/field-report-for-critical-code-studies-2014%e2%80%a8/; Mark C. Marino, Critical Code Studies (Cambridge, MA: MIT Press, 2020). 

  25. Inke Arns, “Read_me, run_me, execute_me: Code as Executable Text: Software Art and its Focus on Program Code as Performative Text,” trans. Donald Kiraly, MediaArtNet (2004), http://www.mediaartnet.org/themes/generative-tools/read_me/1/

  26. For more on Open Humanities Press, see https://openhumanitiespress.org/

  27. For instance, dokieli is a client side editor for decentralized article publishing, annotations and social interactions, see https://dokie.li/

  28. See https://jupyter.org/ and https://devdocs.io/javascript/

  29. For more on Open Source Publishing (OSP), see http://osp.kitchen/about. We are interested in this approach as it somewhat breaks down the divisions of labor associated with traditional publishing in which writing, editing, and designing, and the people that perform these tasks, are distanced from each other. 

  30. See Adrian Mackenzie’s “Preface” to Machine Learners: Archaeology of a Data Practice (Cambridge, MA: MIT Press, 2017); and on GitHub at https://github.com/datapractice/machinelearners

  31. As a dynamic repository Git collapses the distinction between storage and production. For more on Git, see Matthew Fuller, Andrew Goffey, Adrian Mackenzie, Richard Mills and Stuart Sharples, “Big Diff, Granularity, Incoherence, and Production in the Github Software Repository,” in Matthew Fuller, How To Be a Geek: Essays on the Culture of Software (Cambridge: Polity Press, 2017). 

  32. The flowcharts for each chapter are programmed with Graphviz, open source software for graph visualization. All the source code is provided in the folder “graphviz” on the GitLab repository. See https://graphviz.org/

  33. Stephen Morris and Orlena Gotel, “The Role of Flow Charts in the Early Automation of Applied Mathematics,” BSHM Bulletin: Journal of the British Society for the History of Mathematics 26, N°1 (March 2011): 44–52, https://doi.org/10.1080/17498430903449207

  34. We extend our appreciation to the many educators’ various ways of presenting code which this book was built on. In particular, we would like to acknowledge and thank Daniel Shiffman for his The Coding Train YouTube channel that offers excellent creative coding tutorials for us and our students to learn programming in an accessible manner. Since the basics are clearly covered in the instruction videos, students subsequently find it easier to digest the materials in this book providing room for alternative forms to take place. 

  35. Here we once again reference the series of Readme festivals, as well as the Runme.org software art repository, http://runme.org/

  36. A concept first formulated by mathematician, computer scientist, and educator Seymour Papert, MIT Professor, who created a design principle for a programming language called Logo. See Seymour Papert, Mindstorms: Children, Computers, and Powerful Ideas (New York: Basic Books, 1980). 

  37. The field of Critical Code Studies considers source code a cultural text for critical reading and interpretation beyond the understanding of how this code works technically and functionally. See Marino, Critical Code Studies

  38. See OSP’s home page and note the URL: http://osp.kitchen/

  39. By “situated knowledge,” we refer to the work of Donna Haraway, and others broadly in the field of feminist new materialism, to think outside of spurious universal and objective forms of knowledge. See Donna Haraway, “Situated Knowledges: The Science Question in Feminism and the Privilege of Partial Perspective.” Feminist Studies 14, N°3 (1988): 575-599. 

  40. You can find the curriculum and the messy notes for recent years’ Aesthetic Programming courses here: https://gitlab.com/siusoon/aesthetic-programming/-/tree/master/

  41. We are referring to feminist new materialism here, and in particular Karen Barad’s thinking, cutting “together/apart” how-to guides, across the fields of computer science, art, cultural studies, critical theory, and software studies. See Karen Barad, Meeting the Universe Halfway: Quantum Physics and the Entanglement of Matter and Meaning (Durham, NC: Duke University Press, 2007). 

  42. The whole repository, including the text, source code for all sample code and flowcarts, is currently hosted on GitLab as an open source project with a Creative Commons License. You are encouraged to fork or clone a copy if you have a GitLab account or download the whole repository (by pressing the icon of the download button). See https://gitlab.com/siusoon/Aesthetic_Programming_Book

  43. Jennifer Gabrys outlines her “how-to” approach in the “Introduction” to How to Do Things with Sensors (Minneapolis, MN: University of Minnesota Press, 2019). We’d like to think we were doing something along these lines too. 

  44. Walter Benjamin, “The Author as Producer” [1935], quoted in Geoff Cox and Joasia Krysa, eds. Engineering Culture: On the Author as (Digital) Producer (New York, Autonomedia, 2005), 22.