Scott Snibbe:
Code Profiles is a self-reflexive look at code text. The program reads itself, closing the loop between reading, writing, and execution. The CODeDOC project reveals that programs are merely text files that are animated by the compiler, interpreter and computer. Most readers of code won't fully realize the multi-dimensional connections that the linear text actually represents. Code Profiles reveals the three ways of reading the code -- the linear read that most viewers will see; the developmental order -- how the writer breaks code up in their mind; and finally the execution order -- how the code actually runs. Even the code writer often has only a vague understanding of the actual execution order, so these three views are really completely distinct. Seeing all these views together is revealing for all parties -- writer, reader and the executor too -- the computer doesn't get to actually operate on its own code any more. Modern computers separate program and data memory, so that the "errors" or a program modifying itself can be avoided. Clever programmers in the early days actually wrote programs that were "self-aware" and selectively changed parts of the program memory itself to change the execution of the program on-the-fly.

Brad Paley: I'm glad that people appreciated the self-studying nature of my code, but wanted to say *why* it studies itself -- the point of the piece may have gotten lost. It wasn't written to be computer-clever, nor postmodern reflexive (though I admit I refer to those tropes). It reads itself because that was the clearest way I could address the commission's curatorial intent: to address process by focusing on code writing and reading, and almost incidentally execution. My piece simply tries to expose how my code (and Martin's, and Scott's) was written, read by others, and finally executed by the computer.





Golan Levin:
Brad has cannibalized his popular TextArc piece and come up with a few interesting variations in how it can be applied. What I like about his contribution is the fact that it's purely reflexive: a system visualizing itself. On a technical level, I also admire his homebrew implementation (and interpretation) of computational introspection. I could imagine another version of his piece in which it decompiles its own bytecodes, in order to obtain the "real" (in quotes) line numbers of its execution. His remix of Scott's piece, which portrays the live execution of Scott's simulation, is reminiscent of integrated programming environments like John Maeda's DBN and Ben Fry & Casey Reas's Processing, yet suggests an interesting extension to these in which the line-by-line execution of the code itself is visualized. There are Java compilers for Java... Brad could actually make such a thing... and then I'd have to wonder out loud how a system like that could be more completely bi-directional, where changes to the image produced changes in the code.
Brad says "look how little the filter is doing!" but I disagree, and can't let him off so easily. I think the filter is the subject here -- and there are a tremendous number of aesthetic choices in his application: his selection of colors, the use of Bezier curves, details about how the typography is layered and scaled, the rate at which things animate, etc. etc.
My only real question concerns the size of Brad's source code, which exceeds the problem statment by a factor of 5. I don't personally have a problem with this (my code is large, too, because it contains a hard-coded database); rather, I would just be curious to see the smallest possible program which could still visualize its own execution. In this regard, I think Brad's solution is attractive but baroque.

Brad Paley:I was concerned myself about running over the 8K limit and planned to squeeze the code's size down when our curator indicated there was no need to. Also, it's 18% past 8K as compiled code. I think you measured the source--our commission allowed either measurement.





Martin Wattenberg:
I decided the most natural way to comment on Brad's profiler was to profile it by creating a remix. He did a pretty amazing job of showing the sequential movement and rhythm of the execution point... so I tried to show the opposite in my remix, exploring the parallel operations happening at any given moment.
Click here to watch my program profiling his program profiling itself.
My remix is a subclass of his and follows the same protocol, so the other instrumented programs can be plugged in as well... on the page above you'll also see links to profiled versions of Scott's applet and mine. (It actually shows distinct differences between all of our approaches to threading, although this may be of interest only to programmers!)





John Klima: I love how the code "eats itself." The writing style is not as smooth as Golan's, for example -- in code, if not in drawing, I definitely favor the "easy on the eyes," but in the case of this work, it seems the only way to get the job done is through brute force. It's a fascinating piece because as I write code, I always have an image in mind of how the routines are calling each other, passing control here and there and back again, and it's great to see an actual picture of this happening. Not surprisingly, it is as boggling an image in actuality as it often is in my head.