Week 4: Code + Comments

Namrata brings us this passage from Zach Whalen's piece on Travesty Generator:

In examples of poetry generated by code, poetry written as code, and code that generates poetry, it is less useful to think of a tension between the code as text and the code as preamble to its processes and more productive to consider the imbrication of those surfaces.

She asks: "I was wondering what the differences between the three would entail? What can each tell us about the relationship between code and language? Or is that not really important as stated?"

This feels like a worthwhile, if tricky, concept to unpack! Who would like to begin parsing it out?

EXT: Who is the audience for comments?

Both Namrata and Amrita draw our attention to the way Vee's introduction to (of?) Coding Literacy centers writing and its impact on society. Namrata notes that Vee's "understanding of language is based on a western notion of something which can be written and read, rather than oral"; Amrita likewise suggests that "the argument of coding as literacy [...] ignores the accessibility issues from the Western progress-oriented worldview that often marginalises other ways of knowing and universalizes a type of literacy, assuming that it is a requirement for the present world" (emphasis added; please tell me if I misread your intended emphasis?). Both invoke colonial histories and impositions, asking who gets to decide what is or is not infrastructural.

These are good observations and questions! I want to bring this back to the text to help us understand where we're arguing against Vee and where we might be arguing alongside her. Let's look at pages 27-28:

Given that any definition of literacy is one motivated by what it can illuminate, here’s the one I use in this book: Literacy is a widely held, socially useful and valued set of practices with infrastructural communication technologies. This definition takes into account the current consensus in literacy studies that literacy is a combination of individual communication skills, a material system, and the social situation in which it is inevitably embedded. It also assumes that literacy refers to something like mass literacy; that is, a skill can do all of the things literacy does, but if it’s not being practiced by a wider variety of people, I don’t think of it as literacy. Literacy according to this book has both functional and rhetorical components—what makes it both “socially useful and valued.” Literacy reflects real knowledge requirements (its functional component) as well as the perception of what kind of knowledge is required to get around in society (its rhetorical component). These components are entangled: what people perceive as literacy affects not only its social value but also its social utility. In other words, if a skill is believed to be more useful, it is more useful, in part because of the social cachet accorded to it.

A focus on an “infrastructural communication technology” is meant to draw attention to literacies connected to power and to differentiate them from other useful skills. Susan Leigh Star describes “infrastructure” as a comprehensive, societally embedded, structural standard that is largely transparent to insiders. [...] To become more widely held and useful and valued, the practices of writing and programming both had to be done with technologies that were infrastructural and thus suited for more people to use: not too expensive, unwieldy, or prone to break down.

Where does this definition single out writing, and where is it flexible enough to go beyond it? What kinds of orality does it include or exclude?

Yixuan points us to this passage from Annette Vee:

Programming is a literacy we can build other activities and knowledge on, as we have done with reading and writing in human languages. Because of its affordances for information creation, organization, and dissemination, the practice of programming bears other significant similarities to reading and writing. Programming and writing are both socially inflected by the contexts in which they are learned and circulated and are materially shaped by the technologies that support and distribute them. (3-4)

Yixuan also highlights that "writing was once a skill reserved for elites but eventually became a basic competency for everyone." Given the other parallels between writing and coding, she writes (paraphrasing Vee?) "perhaps programming is following a similar path." If so, "does that mean the humanities also have a responsibility to incorporate programming into their core training? Or can it remain an auxiliary skill?"

To begin answering Yixuan's question here, I'd like to press on where the parallels lie, especially in writing or programming's status as platforms: Is programming the equivalent of handwriting? Typing? Fixing a typewriter? Operating a printing press? A publishing house? On the other side of things, what kind of reading knowledge counts as "literate"? How much writing must one do to be able to read sufficiently? (And of course it might change...)

As a follow-up, Yixuan also asks: "if code itself structures communication and cultural production, should those who write or even modify code be regarded as authors in the same sense as traditional writers?" What do you all think, in light of the discussion?

Yanni points out that a lot of Lillian-Yvonne Bertram's procedurally generated poetry isn't available online – even though they still link to it from their site. What remains consists of HTML, CSS, and JavaScript: the kind of standard lo-fi formats that Stolley extols as the key to digital longevity. Do we expect that the missing works were composed otherwise? Or is lo-fi not enough to keep works around? What else should we be thinking about in terms of digital preservation and access?

Yanni poses the question also in terms of Risam and Gil's guidance for minimal computing: "[W]hatever Bertram was prioritizing and willing to give up has rhetorical implications for the circulation of the information they wished to spread. [...] who should think in terms of minimal computing or lo-fi production? Is there anyone we might say has to? Us as scholars? But only in our role as scholars, not when we’re creating art? What about when there is tension between these two roles and the way we view what we’re creating? Does everybody need to be taking these approaches? Or who doesn’t? Why not?"

The authors of 10 PRINT, as Li points out in his post, see historical significance in every term of the code they examine, sometimes down to individual characters. But as John suggests, most of the time people writing code aren't thinking primarily of the backstory of the functions they call; they just want the practical effect of calling the function.

What's the point of reading this way? Who is it for, and when is it relevant? In Li's words: "Is this method effective for you?"

Last week, I told you that for a given public repository, we can...

• fork it, creating a linked copy we control
• clone it, downloading the full contents and all the file history
• or just download the contents as a .zip archive. This strips out the history, but means we could also start over clean in an unlinked repo if we want.

Fork is great if you want to keep receiving updates from other developers: you'll be alerted when you're "behind the upstream repo." But one reason you might want to use the zip download instead is that GitHub assumes forks are meant to contribute to the "upstream" project – and therefore bills all file storage to the root project's owner. If you're actually working on your own, .zip lets you use the project as a template without assuming you want to maintain a shared history.