1. 17

(Previously posted 3 years ago)

Code is not literature and we are not readers. Rather, interesting pieces of code are specimens and we are naturalists. So instead of trying to pick out a piece of code and reading it and then discussing it like a bunch of Comp Lit. grad students, I think a better model is for one of us to play the role of a 19th century naturalist returning from a trip to some exotic island to present to the local scientific society a discussion of the crazy beetles they found: “Look at the antenna on this monster! They look incredibly ungainly but the male of the species can use these to kill small frogs in whose carcass the females lay their eggs.”

  1.  

  2. 2

    Except we’re naturalists of specimens we ourselves created? It’s an interesting framing, but not particularly privileged compared to the ones it seeks to displace.

    My preferred framing is that code is not exactly literature, but there’s enough overlap that some lessons cross over. Literate Programming overstates the connection, yes. Code is like prose in that they have similar audiences; we’re hooking into a visual cortex and associated cognitive skills that are a good fit for reading prose. It is not like literature in having a plot and character development and whatnot. We shouldn’t be trying to replicate the experience of curling up with a novel, that’s just silly. But we should be learning from how scientific papers or mathematical proofs are structured to stage learning, to bring the reader carefully through an argument. We shouldn’t be trying to move from live IDEs to dead PDFs, that’s just cargo-culting. We need to bring the experience of staging an argument into people’s programming environments.

    I assume this is a follow-up to the recent threads on “Software is about storytelling” and the Strange Loop talk on using version control for teaching. At the risk of repeating myself, I don’t think a project has a narrative; code is much too non-linear. But I do think a single automated test has a narrative. Projects with lots of tests thus become these dense weavings of lots of closely-related narratives. Kinda like a Tibetan Thangka.

    1. 1

      The article is not about writing code with an eye to future readers, but about reading existing well-known code for pleasure/interest. Here is svrist’s excellent summary:

      Even Knuth says it makes more sense to dissect and study code as a specimen than read it like literature

      1. 2

        That is a good summary of the article, but a poor summary of Knuth’s quote. If you read Knuth’s original paper, it’s arguing for a vision, about how things should be. What the soul of programming should be, the core activity that programmers should be mastering. The article is setting itself up in opposition to that view, but all its evidence is about how things are and were. The fact that Knuth once had to reverse engineer a program doesn’t mean he thinks programming should be all about reverse engineering, for all time. The Abelson quote is similarly an attempt to explain why programmers do what they do today – without excusing it. Set all of SICP against it for his worldview of how things should be.