Reading, Writing, and/or Coding

Writing in Code (AKA Coding)

Often, when we think about coding, or the act of writing code, the idea of writing often gets lost in translation. The term “writing” is reserved for putting pen to paper, or even hand to keyboard, while coding is…well…coding. It is often considered an entirely different process, and in many, it is. But like language, code, even the bits of it that are numbers or symbols, needs to be written. The ways in which code is, and is not, like a writing system is a topic worth deeper exploration. Code is, at its core, built on language; but, that language is not necessarily built on an alphabet. Often, it is comprised more of symbols than it is of letters. Sometimes, its even built through a hand-held hole-puncher.

R (u kidding me?)

Working through the in-class Computational Reading lab was interesting, at its best moments, but mostly infuriating. I like to think that I’m relatively tech-savvy - I know how to write and read basic HTML, can maneuver my way through some Adobe products, and keep up on all things IoT-related. Jumping into R, however, was like playing a whole new ballgame. I actually had a much easier time reading the printed out Mystery Code in class than I did reading the code intermingled with text during the lab through RStudio.

My lowest point in the lab came from this tiny, but powerful, few lines of code:


Whichever “run” button I clicked, rather than running the code to read the entirety of In the Cage in the console, to my dismay, ran the code up in the actual writing area of my window. I still have yet to figure out how to make it go away, and thus, am forced to scroll through a few hundred lines of Henry James to read the latter half of the lab lesson. I’ll fix it, eventually.

There were more ups than downs, however, particularly surrounding our conversation on words and mapping their frequency in a text using code. Particularly, this fragment of code about Jane Austen:

book_words <- austen %>%
  unnest_tokens(word, text) %>%
  count(title, word, sort = TRUE) %>%
  rename(count = n)
total_words <- book_words %>%  
  group_by(title) %>%

book_words <- left_join(book_words, total_words)

Running this code and seeing the way that words were operationalized was illuminating. Words are data, much in the same way that code is data (and, in the same way that words are code, though not necessarily vice versa). With a few lines of key phrasing and carefully-written code, the most popular words of Austen’s fiction can be streamlined into consumable, traceable data.

The idea that words are data, and data can be coded, is nothing new. Like the way 19th century newspapers are run through OCR programs to copy the paper printed text onto a computer so it can be stored, searched, found, and archived is incredibly similar to what the code above was able to accomplish with Austen’s full repertoire of novels. By turning the individual words into data, literature takes on a new life form: “unnest_tokens” is like command + F on crack. We can find things we didn’t even know we were looking for buried in the text, or rather in the data of the text, and illuminated by the code.

Words as Code, Code as Holes

In Chapter 5 of Gleick’s The Information titled “A Nervous System for the Earth,” he explains the history of the telegraph. But, more importantly, the way that the telegraph contributed to the history of writing in code.

“…So code books became phrase books. Their object was a sort of packing of messages into capsules, impenetrable to prying eyes and suitable for transmission. And of course, at the recipient’s end, for unpacking (155).”

While the code Gelick is talking about is more in the realm of cryptographers than in the world of programming, the idea of packing messages into capsules that are hard to read by an untrained eye is a vital common thread. Code like R or HTML is a language, built on grammar and syntax and slang, that can be learned and understood, much in the same way that code phrases like “gmlt” (Give my love to) or “ymir” (Your message is received) are codes built on the language of the time, meant to be understood only by those who were trained to read them. In this way, cryptographers of the late 19th century were coders in the very essence of the word. Code books helped to encourage and enable an unprecedented code literacy.

In RStudio, we can take a bit of code, encapsulated by the {r} / at its beginning and end, write in a language only those taught how to read and understand it can decipher fully, and click a button to “read” the code and transmit its message into something bigger than itself. The lines of cryptography and programming, in this sense, heavily overlap.

In the same way that cryptographers could assign meaning to the variables of code that were being written, so, too, can programmers assign meaning to their code with written processes:

cage <- data_frame(text=read_file(""))

Though the name of the variable is inherently arbitrary, it still holds a great amount of importance - it’s how we assign data, and therefore meaning, even if only temporarily. Making meaning out of letters, phrases, symbols, and their various combinations, is the driving idea behind how code is read. When we create a variable, we create meaning.

As I mentioned earlier, not all of coding language is built on an alphabetized language like the code of telegraphy. Sometimes, it is built on - or, rather, in - the holes of punch cards.

One of my favorite pages of Padua’s The Thrilling Adventures of Lovelace and Babbage comes on page 90. Here, the author explains the idea behind the Analytical Engine’s use of punch cards to run its program. Number Cards, Variable Cards, and Operational Cards - these punch cards made of carefully places holes were the data and the code “written” to enable the machine to run. Each type of card holds a particular function, much like the way coding phrases such as ‘view’ initiate a particular function within the code. Each function allows the Analytical Engine to operate as a (relatively) well-oiled machine, working together to compute and analyze the data being punched/written/coded/compiled.

In Padua’s Pocket Universe, Lovelace writes her programming code with a Compiler Organ. In this way, the code of the punch cars is composed, rather than written - it is music, rather than language. The 0s and 1s were formed a melody that results in the sweet, sweet sound of mathematical accuracy. Or, when all else fails, a picture of a kitten (80).

Reading Code

One of my favorite bits of code came up during our discussion of creating concordances of texts using code:

austen_words %>% mutate(word2 = lead(word,1)) %>% head

Through mapping Jane Austen’s works, word-by-word, this particular slice of code allows us to read the novel in a new way - we can think about the novel and its use of language in a way that would have required hours of tedious labor without the power of code. When we learn to work with and read code, we can learn to read literature with a new, more analytic lens.

In the case of Lovelace and Babbage, the code of the Analytical Engine was made up of the empty space of a hole punched into cards, created in a particular pattern to hold meaning when ran through the machine. For people in the 19th century communicating via the telegraph, abbreviated letters and numbers in the place of full phrases only held meaning for those who knew the code they had been abbreviated in. And for modern day computer programmers, writing in HTML or CSS requires an in-depth understanding of the way that phrases are used to start certain tasks, to mean certain things, and to produce certain outcomes. No matter how code is written, whether as a language or not, there is an inherent need for literacy that comes with it, both to write it and to understand it.

In the same way that telegraphy coding systems “required prearrangement between sender and recipient,” so, too, does the coding of the Analytical Engine and the programmer (Gleick, 154). The only difference is who - or what - is doing the reading.