Commit f5892251 authored by Geoff Cox's avatar Geoff Cox
Browse files

Update readme.md

parent aba8c216
......@@ -37,30 +37,21 @@ So we draw heavily upon the field of Software Studies, and to an extent Critical
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. This comes with a challenge over language as has also been expressed thus far, or what we might call an *expanded literacy* as the ability to read, write, *and program*.
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.
// Programming literacy
// The book object
Literacy is important here to explain how new kinds of reading and writing are required to account for significant cultural and technical changes. To clarify we can refer back to the beginnings of cultural studies as a field, and Richard Hoggart's *Uses of Literacy* (published in 1957) that included working class (or mass) cultures as part of what we call *culture*, previously the preserve of an elite, and thereby introducing an expanded notion of literacy. [Note: Richard Hoggart, *The Uses of Literacy: Aspects of Working Class Life*, London: Penguin, 2009 [1957].] Clearly literacy is a shifting notion, changing across cultures and underpinned by the changing relations between speaking and writing, also explored by Walter J. Ong in *Orality and Literacy*, who argued that the electronic age has sharpened our understanding through the "secondary orality" of media that all depend on writing in various ways.[Note: Walter J. Ong, *Orality and Literacy: The Technologizing of the Word*, London: Routledge, 2002 [1982].] The written words of programming, for instance, demonstrate how our language has been further enhanced by new forms, and how writing is a form of action and not simply a referent of thinking.[Note: We will return to the analogy between speech and programming in later chapters; see also Geoff Cox & Alex McLean, *Speaking Code: Coding as Aesthetic and Political Expression*, Cambridge, Mass.: MIT Press, 2013).] In this book we weave together the words and actions of human and computer languages although recognise that they are not equivalents as such. The syntax of JavaScript, that we use in this book is one particular instance of this -- useful to learn programming fundamentals and basic object-oriented concepts -- but also allowing for experimentation with *seconday notation*. By this, we mean adjusting the formal notation to allow it to be more easily understood and offer the opportunity for other creative expression through semantic ambiguity; as, for instance, using 'class' to describe one or more objects in object-oriented programming as well as to stratefications in society based on economic and social status. An excellent example of this is Harwood's codework "Class Library", a combination of program code and written text to stress the material conditions of working with code and the possibility of class action.[Note: See Harwood's "Class Library", in Fuller ed., *Software Studies*, 37-39.]
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.
This discussion of programming or coding as a necessary skill for contemporary life seems indisputable, and there are plenty of examples of initiatives related to computational literacy and thinking, from online tutorials to websites such as Codecademy.org and Code.org. *Coding Literacy* by Annette Vee is an attempt to grapple with these connections, arguing how the concept of literacy underscores the importance, flexibility, and power of writing for and with computers (we also refer to this in the following chapter).[Note: Annette Vee, *Coding Literacy: How Computer Programming Is Changing Writing*, Cambridge, MA: MIT Press, 2017.] An important aspect of this is that not only does this help us to better understand the social, technical and cultural dynamics of programming but also expands our very notion of literacy and its connection to a politics of exclusion (as with other literacies). Furthermore, and given that programming like other forms of writing performs actions, it presents itself as way to reconceive politics too: not simply writing or speaking, arguing or protesting, but also demonstrating the ability to modify the technical layer through which the action is performed, in recognition of the ways in which power and control are now structured. [Note: This point largely derives from Christopher Kelty's *Two Bits: the Cultural Significance of Free Software*, Durham: Duke University Press, 2008; he uses the phrase "running code" to describe the relationship between "argument-by-technology and argument-by-talk" (58). Clearly programmers are able to make arguments like other rhetorical forms, see Kevin Brock, *Rhetorical Code Studies: Discovering Arguments in and around Code*, Ann Arbor, Michigan: University of Michigan Press, 2019.]
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.
// The book
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).
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. The structure into ten chapters follows the logic of introducing key programming concepts: getting started...
[[[[[[[Winnie: MORE ON JAVASCRIPT? MAYBE STRUCTURE OF CHAPTERS IN TERMS OF INTRODUCTION OF KEY PROGRAMMING IDEAS]]]]]]]
The use of a Git repository for our writing further emphasises these 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>
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.
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.)
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 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. [Note: https://openhumanitiespress.org/] As such this book can be downloaded for free or purchased as a hard copy at a very 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.[Note: dokieli is a clientside editor for decentralised article publishing, annotations and social interactions, see https://dokie.li/] 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[See http://osp.kitchen/about] -- and make all files freely available through the use of a versioning system that contains all the files for the project.
The use of a Git repository for our writing further emphasises these 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 GitLab site to his 2017 book *Machine Learners*. [See Adrian Mackenzie’s "Preface" to *Machine Learners: Archaeology of a Data Practice*, Cambridge, Mass.: MIT Press, 2017; on GitLab at https://github.com/datapractice/machinelearners.] 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.[Note: 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.]
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 refer to Benjamin again, from 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.”[Note: 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.] (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 authorship 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.
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 [IN PROCESS]
......@@ -94,3 +85,16 @@ This is exactly our point. The book expresses itself as a dynamic object not fix
<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.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment