Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

2026 Participants: Martin Bartelmus * David M. Berry * Alan Blackwell * Gregory Bringman * David Cao * Claire Carroll * Sean Cho Ayres * Hunmin Choi * Jongchan Choi * Lyr Colin * Dan Cox * Christina Cuneo * Orla Delaney * Adrian Demleitner * Pierre Depaz * Mehulkumar Desai * Ranjodh Singh Dhaliwal * Koundinya Dhulipalla * Kevin Driscoll * Iain Emsley * Michael Falk * Leonardo Flores * Jordan Freitas * Aide Violeta Fuentes Barron * Erika Fülöp * Tiffany Fung * Sarah Groff Hennigh-Palermo * Gregor Große-Bölting * Dennis Jerz * Joey Jones * Titaÿna Kauffmann * Haley Kinsler * Todd Millstein * Charu Maithani * Judy Malloy * Eon Meridian * Luis Navarro * Collier Nogues * Stefano Penge * Marta Perez-Campos * Arpita Rathod * Abby Rinaldi * Ari Schlesinger * Carly Schnitzler * Arthur Schwarz * Haerin Shin * Jongbeen Song * Harlin/Hayley Steele * Daniel Temkin * Zach Whalen * Zijian Xia * Waliya Yohanna * Zachary Mann
CCSWG 2026 is coordinated by Lyr Colin-Pacheco (USC), Jeremy Douglass (UCSB), and Mark C. Marino (USC). Sponsored by the Humanities and Critical Code Studies Lab (USC), the Transcriptions Lab (UCSB), and the Digital Arts and Humanities Commons (UCSB).

Palimpsest vs Sketchpad

Mark and co. have asked me to suggest a code critique linked to my book Moral Codes.

First is an excerpt from the utility file “BoundingBox.java", which is part of ~60k lines of Java source code that implemented my Palimpsest language and environment (discussed in Moral Codes chapter 8, pp 112-113).

public void alignBottomLeft(BoundingBox destination) {
x = destination.x;
y = destination.getBottom() - height;
}

public void alignLeftCentre(BoundingBox destination) {
int newX = destination.x;
alignCentreTo(destination);
x = newX;
}

public void alignTopRight(BoundingBox destination) {
x = destination.getRight() - width;
y = destination.y;
}

public void alignCentreTo(BoundingBox destination) {
Location newCentre = destination.getCentre();
setLocation(newCentre.withoutOffset(new Offset(getSize().scaledBy(0.5))));
}

I’d like to contrast that snippet with two short passages from Ivan Sutherland’s Sketchpad thesis (discussed in Moral Codes chapter 6, pp 80-83):

From Chapter III, p. 42:

HUMAN REPRESENTATION OF RING STRUCTURE
In representing ring structures the chickens should be thought of as beside the hens, and perhaps slightly below them, but not directly below them. The reason for this is that in the ring registers, regardless of whether in a hen or a chicken, the left half of one register points to another register whose right half always points back. By placing all such registers in a row, this feature is clearly displayed. Moreover, the meaning of placing a new chicken “to the left of” an existing chicken or the hen is absolutely clear. The convention of going “forward” around a ring by progressing to the right in such a representation is clear, as is the fact that putting in new chickens to the left of the hen puts them “last,” as shown in Figure 3.2. Until this representation was settled on, no end of confusion prevailed because there was no adequate understanding of “first,” “last,” “forward,” “left of,” or “before.”

And from Appendix D, p. 127

The macro instructions listed in this appendix are used to implement the basic ring operations listed in Chapter III. Only the format is given here since to list the machine instructions generated would be of value only to persons familiar with the TX-2 instruction code.

[…]

Take N of XR out of whatever ring it is in. The ring is reclosed. If N of XR is not in a ring, LTAKE does nothing. N of XR must not be a hen with chickens.
PUTL ≡ N×XR→M×XR2
PUTR ≡ N×XR→M×XR2

Put N of XR into the ring of which Mof XR2 is a member. N of XR is placed to the left (PUTL) or right (PUTR) of M of XR2. M of XR2 may be either a hen or a chicken. N of XR must not already belong to a ring.
MOVEL ≡ N×XR→M×XR2
MOVER ≡ N×XR→M×XR2

The Sketchpad quotes are taken from my online edition of Sutherland's thesis:

Sutherland, I.E. (1963/2003). Sketchpad, A Man-Machine Graphical Communication System. PhD Thesis at Massachusetts Institute of Technology, online version and editors' introduction by A.F. Blackwell & K. Rodden. Technical Report 574. Cambridge University Computer Laboratory

Comments

  • @AlanBlackwell Is the contrast you are trying to make here to do with uncommented, almost self-documenting “high level” code v low level code that requires elaborate explanation?

  • What mainly interests me here is the reflections on dimensionality of representation. "Code" in CCS is understood to mean linear streams of symbols, and the syntax specification of languages is uni-dimensional, describing the before and after, but not the above and below. Yet every computer screen has two dimensions. These fragments of code express the tension between the two-dimensional experience of our screen life, and the one-dimensional language modes that fail to adequately describe this. The vivid pictorial imagery of Sutherland's hens and chickens is an intriguing insight into the mental life of the man often credited with inventing the graphical user interface. My own code compensates for the lack of consideration given to natural expressions of spatial language, requiring the careful mathematical definition of relations that even a child understands.

  • @AlanBlackwell

    "Code" in CCS is understood to mean linear streams of symbols, and the syntax specification of languages is uni-dimensional, describing the before and after, but not the above and below.

    Really? I thought that the linear stream of symbols was just the convenient rendering of code. (I guess we could argue about the specific meaning of the word in the phrase "CCS", but that's presumably neither here nor there.)

    Code is the stuff that makes a machine (perhaps a meat machine) behave. Linear streams of symbols are a common rendering for code as it's easier for us to critique those, and easier to write editors for them, because we can put them on paper (originally punch cards), but the code in the mind of the programmer (and certainly in the machine) is, to your point, a complex web of machinery. One of the many reasons that Lisp is so wonderful (and probably other languages as well) is precisely that the linear stream of symbols -- the syntax -- doesn't get in your way as there pretty much is no syntax (well, not too much, as long as you have a paren balancer in your editor :-) and what syntax is there you can fix if you don't like it, and add your own. It's a meta programming language that relieves the programmer from having to think in its terms.

    Programmers almost never think of a linear stream of symbols, even if we eventually have to put it into that form, but that's just the rendering of the program, not really the program. If "code" in CCS is just a linear stream of symbols then this field is focused in the wrong place....but I don't think it is -- although it might be mis-named. Maybe it should be Critical Computing Studies and avoid folks thinking we're talking about linear streams of symbols.

Sign In or Register to comment.