Lost in a Maze of Code

Ok, it’s fun, but writing a lengthy article like this for that … Wait, a book?

– oelmekki, Hacker News discussion about 10 PRINT.¹

Aiming to analyze the titular Commodore 64 BASIC one-liner which draws a maze, and referred to as 10 PRINT throughout, the ten authors weave in and out of subjects at will, carefully hiding nuggets inside the book, which the reader may end up never finding due to the book’s equally maze-like quality. 10 PRINT reads like a wiki printed on paper, sometimes without clear succession between the articles or clearly identified authors. The “Introduction” ends with the following observation:

A token-by-token explanation is like a clumsy translation from BASIC into English, naively hewing to a literal interpretation of every single character.²

But this is, ironically, exactly how the authors choose to start their book. After a short and inspiring call to arms for critical code, platform and software studies, and their relevance in the world today, when so much of what we do is mediated via software, they dive into a token by token analysis, offering deep insights such as “one variant of this program, which was published in the Commodore-specific magazine RUN, uses 8 as its line number.”³

The book starts with a chapter on “Mazes”, and here the book works well giving us a tour of the history and cultural significance of the maze from Knossos via Chartres and Dungeons & Dragons, the connection with laboratory mazes, and eventually Pac-Man and Doom. This chapter is a pleasant read on its own and stretches the titular one-liner only so much while staying relevant. This can also be said for the later chapter “Randomness”, a discussion of the concept of randomness and its different forms. Leading towards 10 PRINT and the RND function, we get an overview of uncertainty, probability and chance, and eventually pseudorandom number generators in the context of computing. Similarly, a chapter on “Regularity” discusses the character-based grid of the Commodore 64 VIC-II, via textiles – including the Jacquard Loom – and modern art. Establishing putative connections between not only the modernist grid, but also programmatic patterns for stitching from the 1885’s “The Young Ladies Journal” to the BASIC programs of magazines such as Commodore RUN is an example of this book at its best.⁴

The last two chapters first discuss BASIC in a pretty traditional way, recollecting its history and role as enabler of computational literacy, and finally the Commodore 64, echoing Brian Bagnall’s Commodore: A Company on the Edge⁵ and dig into a MOS 6502 assembler version of the titular program. This chapter situates the platform in cultural terms and without trivializing the program, shows another, directly relevant, lower-level implementation on the same platform. Here the authors mention that Friedrich Kittler “famously argued that high-level languages essentially obscure the operations of the hardware.”⁶ This is undeniably true, but assembler on the other hand essentially obscures the operations of your program, so there are reasons we choose to write code in higher-level languages. But either obscured or abstracted, the lower level influence of the machine on higher level languages can always be felt, something echoed in John Backus’ sentiment that “the complacent acceptance most of us give to these enormous, weak languages has puzzled and disturbed me for a long time.”⁷

Every second chapter of this book is a “REMark”, so named after BASIC’s statement for code comments. Now, usually comments in code aim to add useful explanation to their direct surrounding code, but in this book the role is reversed, as each remark is what contains most of the code. These chapters are occasionally very interesting – especially “A port to the Atari VCS”, which echoes Nick Montfort and Ian Bogost’s excellent Racing the Beam⁸. But “Variations in Processing” drags on, making trivial observations about how to modify the program in one way or another to achieve a mildly different outcome. It would feel at home in a book entitled “Introduction to Processing”, but doesn’t add much in a book like this. The last REMark, “A Maze Walker in BASIC” manages to show, in several iterations of unreadable BASIC,⁹ a glimpse of what real world programming can actually be like, but I’m not sure this was intentional. This remark starts with a definition of software studies, “just as literary scholars study a text by generating more texts, it is productive to study software by coding new software.”¹⁰ This is not what I had assumed software studies to mean, and thought that similar to film studies critiquing existing media was the key part, not producing more. But I can see how it fits under “experimental accounts” in the definition from the series foreword:

Software studies uses and develops cultural, theoretical, and practice-oriented approaches to make critical, historical, and experimental accounts of (and interventions via) the objects and processes of software.¹¹

As programming is an intellectually challenging discipline, it’s only natural for someone to write a few lines of code and suddenly think they have something insightful to say about the process. It’s fun to see the authors’ enthusiasm, but not enjoyable to read someone else’s BASIC in detail. Millions of man-hours are already wasted writing software, which in turn actually requires several skills associated with the humanities to do well. You need to analyze texts and “business processes”, perform software archaeology, dig through archives and understand your software’s broader function in society, if for nothing else than from a business point of view to earn money.

Platform studies unlike critical code studies is about understanding the limits and engineering feats needed to bend a platform to your will as a programmer, and essentially explores the hacker mindset. Code itself, despite its textual allure, doesn’t actually signify things at the level some people seem to wish for. As Mark C. Marino cautions when analyzing the Quicksort divide and conquer algorithm as a metaphor for social organization, “Though my analysis said something about neighborhood hierarchies, it offered little insight on Quicksort itself, nor did it draw from Quicksort a lesson about the society from which it came.”¹² An algorithm should also not be confused with a specific implementation of it. Software doesn’t constitute a fixed textual work, and one needs to take the evolution of building and running it into account. The authors acknowledge this fact at the end in the conclusion:

The view of programs as static is even less tenable when one considers the writing, running, and distribution of programs throughout the history of computing. Custom software written for businesses has long been maintained and updated – for half a century. The BASIC programs people keyed in from magazines invited users to modify them.¹³

The authors claim that “this work seeks to avoid fetishizing code”¹⁴, as Wendy Chun¹⁵ has warned them. But instead of avoiding this, they compulsively dig back into the one-liner, milking it for meaning where none further can be found. There’s something inherently compelling about the idea of analyzing a single line of BASIC, written on a platform that’s vastly easier to grasp than present day computers. It brings a level of coherence and sense of security when it comes to our ability to actually reason about software. This is rather frustrating since whilst there are many good avenues in this book worth exploring, and the overall approach is promising, they take it almost to the level of parody at times. The appendix, “Variations of 10 PRINT” states:

While the specific line of code 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 is the focus of this book, and has been treated as canonical, this program is not a simple transcription of some authoritative version.¹⁶

A few problems directly arise here. The line, despite the title, hasn’t actually been the focus of the book it has instead been a departure point, as they state in the introduction:

The eponymous program is treated as a distinct cultural artifact, but it also serves as a grain of sand from which entire worlds become visible; as a Rosetta Stone that yields important access to the phenomenon of creative computing and the way computer programs exist in culture.¹⁷

This “entire worlds” approach is good, facilitating discussion of the line around interesting things as shown in the chapters about “Mazes” and “Randomness”. The choice, in the valid name of clarity, to refer to the titular program as 10 PRINT throughout the book is problematic, as it names and tries to give importance to an artifact where there originally was none. The attempt to canonize the line and at the same time the book about it via mutual recursion rings false.

A reader might incline to feel that this book started as a fun idea but over time the authors realize that they, like the program itself, have created a replicating never ending maze of text. They seem unable to say RUN/STOP and admit to each other that turning this entire thing into a book, was it a joke? This ambivalence between computational playfulness and high-falutin’ academic prose creates an eerie read, as if you cannot really trust the author’s point of view, which I assume is an effect of ten people aiming to speak with a single voice. The text achieves, in part, the tone of Wikipedia-style prose, where a detached, faceless authority, attempts to explain various subjects with pretended objectivity. Are all the authors in on the joke or not? Or are some of them taking themselves too seriously?

It’s worth remembering that the original Ward’s Wiki¹⁸ is a community for programmers that doesn’t, despite its technical subject, try to maintain a single editorial voice, but instead works as an open forum, where anyone can edit or delete anything – not unlike how code is written and evolved in the wild. The nature of Ward’s Wiki and the programmers inhabiting it connects back to 10 PRINT’s observation that code is indeed part of a “surrounding culture of creative, exploratory computing”¹⁹. Its success comes from this open, insightful debate. I think that if the authors of 10 PRINT had clearly identified their voices, actively shown disagreement, and argued their points, perhaps regarding the entire method, it would have made a more compelling read instead of the route of anonymous verbosity taken.

But my main concern lies with statements like the following, when discussing a perl one-liner that deals with dates:

perl -MPOSIX -le’@now = localtime; $now[0] -= 7;
$now[4] -= 14; $now[7] -= 9; print scalar localtime
mktime @now’

…

That code snippet could be useful, for example, in a vacation scheduling or beer fermentation system.²⁰

No, it couldn’t, actually. I don’t mean that it’s technically impossible, but their casual use of the word “useful” doesn’t imply any deep thoughts around the engineering trade-offs involved backing up such a claim. While stitching small programs together via one-liners is a key part of the UNIX philosophy,²¹ this is not how you go about to write an actual beer fermentation system, unless already drunk. This is painful to watch. This wish to critically study code, while at the same time trivializing the engineering, craft and art of programming (pick 2). Programming, in my experience, is very hard. Rich Hickey’s talk “Simple Made Easy”²² is an example of the form of critique happening within the field of software. I would like nothing more than help from the humanities to make things simpler, and not by making them seem easier, but by fully understanding the complexities of what we’re dealing with when developing software. Remember, unlike one-liners, which is where we all start – but only people playing code golf end up – real systems have impact on our daily lives and society, and understanding this complexity is not well served by folding it into a single line of code and obscurity. As Adrian Mackenzie notes, “in many instances software is so complicated, distributed and convoluted in architecture that it defeats comparison with any other technical object.”²³

There’s obviously nothing wrong with studying the kind of programs this book does, and geek out totally over a single line. Programming can, and should more often than it is, be creative and fun. Michael Fogus’ “BAYSICK – an embedded Insane-specific Language for Scala implementing a subset of BASIC”²⁴ is a directly relevant example. But I think there’s a lot of more interesting work to be done on the critical side, and more fruitful avenues to take if one wants to actually say something about software’s role in society itself. I look forward to critical code studies moving on from toy examples to take on real world code, where the subject easily actually can fill many books.

Bio
Håkan Råberg is an independent software consultant living in London. He has a BA in Cinema Studies from Stockholm University. These days he primarily writes code in Clojure, a modern dialect of Lisp for the JVM. He has been programming professionally since 1997. During 2005 to 2011 he worked for ThoughtWorks, a global consulting firm, in London, Bangalore and San Francisco. https://github.com/hraberg/

References

Backus, John. “Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs.” Commun. ACM 21 (aug 1978): 613–641. http://doi.acm.org/10.1145/359576.359579.

Bagnall, Brian. Commodore: a Company on the Edge. Winnipeg: Variant Press, 2010.

Chun, Wendy. Programmed Visions Software and Memory. Cambridge, Mass: MIT Press, 2011.

Cunningham, Ward. “WikiWikiWeb,” 1995. http://c2.com/cgi/wiki.

Fogus, Michael. “Baysick: A Scala DSL Implementing BASIC.” Send More Paramedics (2009). http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implementing-basic/.

Hickey, Rich. “Simple made easy.” In Strange Loop 2011. InfoQ, 2011. http://www.infoq.com/presentations/Simple-Made-Easy.

Mackenzie, Adrian. Cutting Code: Software and Sociality. New York: Peter Lang, 2006.

Marino, Mark C. “Critical Code Studies.” Electronic Book Review (dec 2006). http://www.electronicbookreview.com/thread/electropoetics/codology.

Montfort, Nick, Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mark C. Marino, Michael Mateas, Casey Reas, Mark Sample, and Noah Vawter. 10 PRINT CHR$(205.5+RND(1));:GOTO 10. Cambridge, Mass: MIT Press, 2013.

Montfort, Nick, and Ian Bogost. Racing the Beam: the Atari Video Computer System. Cambridge, Mass: MIT Press, 2009.

Raymond, Eric. The Art of Unix Programming. Boston: Addison-Wesley, 2004.

oelmekki. “A single line of Basic sends readers into a labyrinth.” Hacker News, 2012. https://news.ycombinator.com/item?id=4856207.

Footnotes