thoughtmesh
thoughtmesh
what's this ?
what's this ?
excerpts here
excerpts out
peer review
Click on a tag above to see relevant excerpts from this site.
Click on a tag above to see relevant excerpts from other articles in the mesh.
Search this article for any word:

This is the paper I presented at the CCS@USC conference (July 23rd, 2010), in which I discuss the possibilities for critically reading code with a debugger. The paper was introduced by Paul Rosenbloom (USC) -- you can find his talk in the Conference Video section.

For Paul Rosenbloom's introductory talk, see the second video below.

Max Feinstein - Critical Code Studies from IML @ USC on Vimeo.


Paul Rosenbloom's introduction:

Paul Rosenbloom - Critical Code Studies from IML @ USC on Vimeo.

I owe many thanks to Paul Rosenbloom for so graciously agreeing to provide such an informative introduction to Soar. Although it's impossible for anyone to summarize 3 decades worth of work in 5 minutes, especially something as complex as Soar, the topics that Paul covered should be sufficient for proceeding with this discussion. And if you're still unsure about what exactly this piece of artificial intelligence software does and how it works, then you're a good candidate for listening to my presentation, so I'm glad you're here.

While Rosenbloom and other seasoned programmers may not have trouble understanding how Soar works, less experienced programmers and code readers, like myself, may benefit greatly from the use of additional resources that offer alternative ways to understand the complex processes embedded in the code. After all, Mark Marino advises scholars embarking on Critical Code Studies to explore "the code, the documentation, the comments, and the structures." All of these things are open to interpretation, says Marino, because "greater understanding of these elements will help critics build complex readings."

In the research I did with Marino, or Coach, as his students call him, I studied a smattering of artifacts in search of anthropomorphic features of Soar code. I scoured lines of commentary, code and documentation in search of the vital components of Soar that allow it to transcend, albeit subtly, the realm of the purely mechanical and lifeless, and start to take on human-like cognitive abilities.

But the tools I mentioned came with a major drawback -- unlike the software they describe, they're inanimate. The code itself is just a snapshot of a program prior to execution, a portrayal of what it should do once the user sets things in motion. Likewise, documentation is but a description of what a program does -- a narrative, and perhaps an insufficient one at that. A complex code reading demands not only an examination of stagnant text, but also a consideration for the nature of a program in motion.

This distinction between instruction and execution is carefully scrutinized by none other than today's keynote speaker Wendy Chun, who, in her forthcoming manuscript Programmed Visions: Software and Memory, investigates "the ways in which [the] simultaneous conflation and separation of instruction from execution... is constantly constructed and undone, historically and theoretically." She goes on to explain that, "this separation is crucial to understanding the power and thrill of programming, in particular the fantasy of the all-powerful programmer, a subject who magically transforms words into things."

I shall now set out to temporarily deconstruct this conflation of instruction and execution, isolate the latter, and consider its role in critical code readings. I want to understand that magical transformation of words into things, and how the thing can, in this case, possibly come to reason and think like a real live person. In order to do so, I'll use one particularly powerful tool that grants real-time access to Soar's innermost thoughts: the debugger.

The debugger is to code readers and programmers what brain-imaging techniques are to cognitive scientists. Just as an fMRI offers a glimpse of real-time brain activity in humans and animals, debuggers peer into the naturally-obfuscated space between the beginning and end of a program's execution.

Although we're blissfully unaware of the storm of neurons constantly firing away to maintain homeostasis, we depend on these subconscious workhorses to regulate our heartbeat, our emotions, our ability to walk, and myriad other features that define the human essence. Circling back to the analogy between brain-scanning and code-reading, would it not unreasonable to understand the real-time execution of code as the life force of a computer program? I assert that code readings can be greatly enhanced by a survey of real-time activity, as demonstrated by CCS working group member Stephen Ramsay in his exquisite "live reading" of a musical performance by Andrew Sorensen.

As Rosenbloom explained, Soar generates a massive number of possible solutions as it works through a given problem for the first time. Much like a novice programmer who uses trial-and-error to produce his desired software, Soar experiments with potentially effective approaches to overcome a given obstacle. As Soar discovers what works and what does not, it eventually internalizes the appropriate steps to work through familiar scenarios; it learns. Although fascinating in its own right, the learning mechanism is not the object of my concern. Rather, my interest is in uncovering and understanding the behind-the-scenes activity that enables Soar to solve complicated logic problems and animate pseudo-sentient robots.

If you're still with me, and you're convinced (or at least feigning contentment for the sake of my presentation) -- if you're convinced that a debugger can help in our pursuit to read code critically, then you're probably still curious as to what exactly we're looking at in the debugger, and how it will be of use to us. The answer to the first question is relatively straight-forward: this particular debugger provides users with a suite of tools to pinpoint bugs, interface with other software, and get detailed insight into Soar's run-time activity. More consideration for the latter question of how the debugger is useful, in just a minute. First, let's take a peak at what the debugger looks like as Soar runs through the Towers of Hanoi puzzle.

I must confess that the debugger's output doesn't resemble code in the traditional sense. But the question of what code is, and perhaps more importantly, what counts as text worth reading, is essential to Critical Code Studies. In his eloquent and thought-provoking presentation to the working group last spring, Jeremy Douglass urged CCS practitioners to consider the question, "how do we read code?" In the lengthy and productive conversation that followed, participants discussed the ways in which a multiplicity of tools and approaches can enhance code readings. This is the point that I wish to demonstrate now, using the debugger's output as an example of one of many useful tools in the code reader's arsenal. And it's through this reading that I hope to answer the question of how a debugger may be useful.

My reading starts with an idea that harks back to the analogy between code and brain, between debuggers and fMRI's: A crucial component of the debugger's vocabulary, at least on this particular occasion, is the word firing, which represents instances of activity. In this case, Soar fires a certain production to move a piece of the puzzle from one location to the next, presumably in an attempt to edge closer to finding the puzzle's solution. Although this firing appears to be a straightforward procedure upon first glance, it strikes me as especially salient when considering the role of the same word in the neuroscientist's lexicon. And while the use of the word firing may or may not be functionally significant in Soar, and I'm inclined to think that it's not, it nevertheless establishes an essential connection between the execution of code and neuronal activity in humans.

Another point I'd like to make is intended to demonstrate that reading code with a debugger need not be restricted to purely semantic interpretations. I turn next to semiotics, which play an equally important role in understanding what happens during Soar's execution. Under the headline "Change Working Memory," simple arrows consisting of an equals sign juxtaposed with a carrot indicate the directional flow of information in and out of the working memory.

This is precisely the activity that's camouflaged by complex functions and algorithms, obscured from view when the average code reader peruses the source files. Fortunately for the veteran code reader equipped with a debugger, these semiotic roadsigns serve as navigational tools for understanding and interpreting what happens as the program runs. Thus, I can now analyze how Soar moves information in and out of its short term memory - six elements at a time, in this case. Perhaps it's no coincidence that the average number of objects a person can hold in his short term memory is 7, plus or minus 2. This is called the "magic number" in psychology, and was discovered by George Miller in 1956.

I can only assume that Soar's manipulation of 6 objects at a time was not implemented to mimic Miller's findings -- although Dr. Rosenbloom can correct me now if I'm wrong. Instead, I imagine that this phenomenon is a result of some underlying algorithmic constraint, or perhaps something more simple like the layout of the puzzle. Regardless of the origins of this strange coincidence, the fact of its existence is a fascinating point at which we can witness Soar behaving in a truly human-like way, a fact which we likely would have missed simply by browsing through motionless code.

In conclusion, I believe that Critical Code Studies demands a multifaceted approach to reading and understanding code, for the essence of software emanates not only from written instruction, but also from an unbounded variety of other media.