Download raw (22.9 KB)
Title: 0. *Aesthetic Programming: A Handbook of Software Studies* page_order: 0 *Aesthetic Programming: A Handbook of Software Studies* **Preface** // What kind of book is this? Reading its subtitle, this book is clearly meant to be a handbook of sorts, but not in any conventional technical sense of it being a prescribed set of instructions (how-to recipe-style book) in order to find out how to do something like coding in a straightforward fashion (for beginners, and so on).<sup>[1](#myfootnote1)</sup> As such this handbook is not simply meant to be read in order to learn to code or indeed to offer critical reflection upon the practice of coding alone. Instead, it is something more messy and at the same time ambitious we would say: a book to represent a more complex and deeply entangled set of relations between writing and coding as "really useful knowledge".<sup>[2](#myfootnote2)</sup> The book is therefore unashamedly pedagogic, aimed at those who would like to learn how to read, write and *think* with program code, but is not prescriptive. Most programming books are written with a 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 IT-related or creative industries. Not many programming books address the cultural and aesthetic dimensions of programming as a means to think and act critically. In emerging trans-disciplinary fields involving computational technology -- such as software studies, platform studies, and digital humanities to an extent -- the practice of programming is incorporated into the object of study and yet little practical detail is provided, especially for those studying non-technical or scientific disciplines. This book attempts to address this perceived gap in literature and the growing interest in *computational thinking* to expand programming beyond the confines of computer science (or even the digital humnaities which presents a set of other limitations ultimately). We consider our approach to be distinctive from other programming books that are more focused on programming languages from an engineering perspective, as well as distinctive from other theoretical books where source code becomes an illustration of the programmer's thinking or too-easy analogy to the hidden layers of operations (if not ignored altogether). Whilst operating broadly in the spirit of Software Studies,<sup>[3](#myfootnote3)</sup> the book offers an applied and overtly practice-based approach to understanding the centrality of programming -- the 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 conceptual agency of the programmer to develop as they become more proficient in their technical skills. To reiterate, our intention is that readers will acquire key skills of programming in order to read, write and think with, and through, code (and we will return to the issue of literacy later). We see that it is important to fully explore the intersections of technical and cultural aspects of code in order to reflect deeply on the pervasiveness of computational culture and its social and cultural effects -- from the language and politics of human-machine languages to datafication and recent developments in automated machine intelligence, for example. In other words, the book embraces both the technical aspect and formal qualities of code as well as imaginaries of code, including acknowledgement of the material conditions of programming practice, the nonhuman agency of code itself, and its inherent relationality. We aim to bridge the gap between theories of computational culture, aesthetics and cultural studies, alongside learning to program. As part of this, we take a particular interest in power relations rarely acknowledged, such as class, gender, race, as well as the authoritarian logic of command and control inherent to computational systems. In short, the handbook introduces and demonstrates a distinctive approach through the intersectional and reflexive practice of aesthetic programming as we understand it. // So why aesthetic programming? The argument the book follows is that computational culture is not just a trendy subject to study, or a way to understand more about what is happening with computational processes, but a means to engage with programming as a way to create change in the technical system. Thus we consider programming to be a dynamic cultural practice and phenomenon, a way of thinking and doing in the world, and a means to understand some of the complex procedures that underwrite our lived realities, in order to act upon that reality. We consider that the phrase *aesthetic programming* best describes this approach. We claim a certain distinctiveness here, but of course aesethetic programming comes 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 through the practice pf programming, can be cultivated and developed from the broad perspective of the arts and humanities.<sup>[4](#myfootnote4)</sup> It should be explained that the title *aesthetic programming* actually derives from one of the undergraduate courses in the Digital Design degree programme at Aarhus University in Denmark, which has been taught in parallel to another course in Software Studies since 2013. Taken together these courses offer ways to think with software to understand wider political, cultural, social and aesthetic phenomena. 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 the inside -- the politics and aesthetics of algorithms, loops, variables, and other key concepts. The structure of the book largely emerges from this experience of teaching and we thank all our students and fellow teachers for their valuable contributions and critical feedback along the way.<sup>[5](#myfootnote5)</sup> To go further, invoking aesthetics, it should be clear that we do not refer to ideas of beauty as it is often misunderstood, but to aesthetics at the core of politics, to what presents itself to sense-making experience and bodily perception (see Jacques Rancière's *The Politics of Aesthetics*, for instance).<sup>[6](#myfootnote6)</sup> How we apprehend the world in this sense is not fixed but in process of endless becoming, much like software itself. Aesthetics also refers back to the critical theory of the Frankfurt School, and in particular the ideas of Theodor Adorno and Walter Benjamin, to enforce the idea that cultural production -- which would include programming for us of course -- must be seen in a social context and has a political function. Programming becomes a kind of force-field 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".<sup>[7](#myfootnote7)</sup> Technology clearly plays its part here, and the infamous artwork essay by Benjamin becomes a touchstone for dismantling some of the associated myths of artistic production including the dismantling of authenticity and the aesthetic experience of *aura* (the mark of its authenticity and originality).<sup>[8](#myfootnote8)</sup> It is 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 the destruction of aura is a kind of political emancipation, Adorno expressed the negative view that standardisation and pseudo-individuality would follow. We can clearly see these tendencies have accelerated with computational culture and 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.<sup>[9](#myfootnote9)</sup> The question remains 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. To address this difficulty we have been working with key concepts from programming as the starting point for our analysis -- such as class, function, loop -- thereby not reading cultural phenomena in relation to programming concepts but the other way around where the programming leads the discussion through a deep understanding of the way it is constructed and operationalized. This suggests practical understanding and knowledge of programming to underpin critical understanding of techno-cultural systems, often informed by expertise in both fields -- as in the case of Wendy Hui Kyong Chun.<sup>[10](#myfootnote10)</sup> We hope to encourage more and more people to defy the separation of fields in this way. // And software studies? So we draw heavily upon the field of Software Studies, and to an extent Critical Code Studies -- the work of Wendy Chun, Matthew Fuller, and others, including our own earlier selves -- 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. In terms of form we take our cue from Matthew 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.<sup>[11](#myfootnote11)</sup> In many ways, and simply put, our book can be thought of as an update of both books -- a further lexicon -- but with far more attention to the culture of software from the inside; but also like any lexicon, as a way to attest to the ways in which words exert power through meanings and also through their actions as instructions. In this respect it is also important to recognise that the book *Software Studies* derived from an earlier 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 not therefore 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."<sup>[12](#myfootnote12)</sup> Like this, we believe that paying attention to key concepts from programming offers the possibility to open up new insights into aesthetics and critical theory, and new perspectives on cultural phenomena increasingly bound to computational logic. In extending the discussion, beyond formal logic to its outside, we also emphasise the usefulness of artistic practice to open up more speculative and alternative 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 temporary holding position).<sup>[13](#myfootnote13)</sup> That we draw upon examples from artistic (and critical design) practices as part of our argument, including works by one of us (Winnie Soon), stresses our point that programming is not simply a practical tool that produces an artwork but -- like poetry or performance art -- is a critical-aesthetic object in itself.<sup>[14](#myfootnote14)</sup> As media theorist Tilman Baumgärtel once neatly clarified: "Software art is not art that has been created with the help of a computer but art that happens in the computer. Software is not programmed by artists, in order to produce autonomous work, but the software itself is the artwork. What is crucial here is not the result but the process triggered in the computer by the program code."<sup>[15](#myfootnote15)</sup> In order to discuss the expressivity and aesthetic dimensions of code and computational processes, we incorporate artistic works that explore the material conditions of software and operations of computational processes as practical and theoretical examples. They are part of our argument in other words, as well as usefully demonstrate some of the ideas in practice and unexpected epistemic insights. We might add, and repeating what has already been introduced, that we are not simply interested in a critical aesthetics of programming but also programming as critical aesthetics. // The book object 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 key programming concepts. Suffice to say for now that the book sets out to express how writing and coding are 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 to emphasise that writing a book is necessarily a work in progress. In other words, this is a book to be read and acted upon, shared and rewritten. There are clearly many precedents for such an overtly collaborative approach in software production, and clearly free and open source principles underscore our thinking. It is worth emphasising 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 -- which can be extended to the production of books and the associated reputation economy of academic publishing. But we also recognise 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 capitalise on free labour. However 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 radical open access for scholarly work.<sup>[16](#myfootnote16)</sup> As such this book can be downloaded for free or purchased as a hard copy at a reasonable price. This nothing particularly original in this. We acknowledge other numerous experimental publishing initiatives and even *anti-platforms* such as dokieli for decentralised article publishing.<sup>[17](#myfootnote17)</sup> 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). Our use of print and associated software repository is our way of managing this problem. This also has 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 it<sup>[18](#myfootnote18)</sup> -- and make all files freely available through the use of a Git versioning system that contains all the files for the project (the following chapter introduces this), distributed under the terms of the GNU General Public License version 2. The use of a Git repository for our writing further emphasises these free and open source working principles, and how by treating writing as software, or indeed software as writing, allows us to formalise the production of the book as an iterative process, in need of timely updates, forking and endless reversioning. In allowing for 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 over networks. In this way, 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, and demonstrated in the associated GitHub site for his 2017 book *Machine Learners*.<sup>[19](#myfootnote19)</sup> 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 work together, host and review code, and build software together. Git, as a dynamic repository in this way collapses the distinction between storage and production.<sup>[20](#myfootnote20)</sup> Finally we might add that the book is not simply a physical object that you might be holding in your hands as you read these words, but a computational and networked object too, distributed across various other spaces and temporalities, and made available to both readers and writers alike. In saying this we make reference to Benjamin again, and his essay “The Author as Producer": “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.”<sup>[21](#myfootnote21)</sup> (And interestingly, for Benjamin, cultural production requires a pedagogic function.) This is exactly our point. The book expresses itself as a dynamic object not fixed in terms of attribution or commodity form. It follows that, although this preface is only the beginning of the book, there can be no end: the book is purposefully stuck in an endless loop of its own becoming. ##Notes <a name=“myfootnote1”>1</a> The casual address “for dummies” could also be used but this carries the unfortunate connotation of learning disability. <a name=“myfootnote2”>2</a> Here we are making reference 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*, Vol. 14, No. 2 (Spring 1994), pp. 97-111, https://www.jstor.org/stable/43441948. <a name=“myfootnote3”>3</a> Software studies is an interdisciplinary research field, which studies software systems and their social and cultural effects, see Matthew Fuller, ed. *Software Studies: A Lexicon*, London: MIT Press, 2008. <a name=“myfootnote4”>4</a> Here we are referring to Maeda, 2004; Peppler & Kafai, 2009; Montfort 2016, Wardrip-Fruin 2012, ADD REFS, add more? <a name=“myfootnote5”>5</a> Special mention should be extended to Magda Tyzlik-Carver and Christian Ulrik Andersen who have contributed to the teaching of these courses, as well as teaching assistants... add names. <a name=“myfootnote6”>6</a> Jacques Rancière, *The Politics of Aesthetics*, London: Continuum, 2006, that investigates what aesthetics and politics have in common: the delimitation of the thinkable and the unthinkable, the possible and the impossible, according to Rancière. <a name=“myfootnote7”>7</a> The quote continues: "... which must be deciphered by means of critical analysis." (Martin Jay, *Aesthetic Theory*, 1996: 177). <a name=“myfootnote8”>8</a> 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." (ADD REF) <a name=“myfootnote9”>9</a> 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, also quoted in Jay, 1996: 179). <a name=“myfootnote10”>10</a> 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. <a name=“myfootnote11”>11</a> Fuller, ed. *Software Studies*; Raymond Williams, *Keywords: A Vocabulary of Culture and Society*, London: Fontana, 1983; in 2005 Blackwell published *New Keywords: A Revised Vocabulary of Culture and Society*. <a name=“myfootnote12”>12</a> The project workshop description an be found archived at https://web.archive.org/web/20100327185154/http://pzwart.wdka.hro.nl/mdr/Seminars2/softstudworkshop. <a name=“myfootnote13”>13</a> In particular we might cite the influence of the Readme festival... add more on this. Importantly here perhaps is to emphasise that the category of art in itself becomes inadequate to cover the kinds of creatives practices that have developed in the field. ADD REFS <a name=“myfootnote14”>14</a> Critical Code studies makes this explicit. Critical Code Studies is... coding in tradition of literary criticism [ADD MORE]. <a name=“myfootnote15”>15</a> Cited in Cox, 2007 REF???, 150. <a name=“myfootnote16”>16</a> For more on Open Humanities Press, see https://openhumanitiespress.org/. <a name=“myfootnote17”>17</a> [Note: dokieli is a clientside editor for decentralised article publishing, annotations and social interactions, see https://dokie.li/] <a name=“myfootnote18”>18</a> For more on Open Source Publishing (OSP), see http://osp.kitchen/about. <a name=“myfootnote19”>19</a> See Adrian Mackenzie’s "Preface" to *Machine Learners: Archaeology of a Data Practice*, Cambridge, Mass.: MIT Press, 2017; and on GitHub at https://github.com/datapractice/machinelearners. <a name=“myfootnote20”>20</a> For more on this, 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. <a name=“myfootnote21”>21</a> Walter Benjamin, "The Author as Producer" [1935], quoted in Geoff Cox & Joasia Krysa, eds. *Engineering Culture: On the Author as (Digital) Producer*, New York, Autonomedia, 2005: 22.
