Howdy, Stranger!

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

2024 Participants: Hannah Ackermans * Sara Alsherif * Leonardo Aranda * Brian Arechiga * Jonathan Armoza * Stephanie E. August * Martin Bartelmus * Patsy Baudoin * Liat Berdugo * David Berry * Jason Boyd * Kevin Brock * Evan Buswell * Claire Carroll * John Cayley * Slavica Ceperkovic * Edmond Chang * Sarah Ciston * Lyr Colin * Daniel Cox * Christina Cuneo * Orla Delaney * Pierre Depaz * Ranjodh Singh Dhaliwal * Koundinya Dhulipalla * Samuel DiBella * Craig Dietrich * Quinn Dombrowski * Kevin Driscoll * Lai-Tze Fan * Max Feinstein * Meredith Finkelstein * Leonardo Flores * Cyril Focht * Gwen Foo * Federica Frabetti * Jordan Freitas * Erika FülöP * Sam Goree * Gulsen Guler * Anthony Hay * SHAWNÉ MICHAELAIN HOLLOWAY * Brendan Howell * Minh Hua * Amira Jarmakani * Dennis Jerz * Joey Jones * Ted Kafala * Titaÿna Kauffmann-Will * Darius Kazemi * andrea kim * Joey King * Ryan Leach * cynthia li * Judy Malloy * Zachary Mann * Marian Mazzone * Chris McGuinness * Yasemin Melek * Pablo Miranda Carranza * Jarah Moesch * Matt Nish-Lapidus * Yoehan Oh * Steven Oscherwitz * Stefano Penge * Marta Pérez-Campos * Jan-Christian Petersen * gripp prime * Rita Raley * Nicholas Raphael * Arpita Rathod * Amit Ray * Thorsten Ries * Abby Rinaldi * Mark Sample * Valérie Schafer * Carly Schnitzler * Arthur Schwarz * Lyle Skains * Rory Solomon * Winnie Soon * Harlin/Hayley Steele * Marylyn Tan * Daniel Temkin * Murielle Sandra Tiako Djomatchoua * Anna Tito * Introna Tommie * Fereshteh Toosi * Paige Treebridge * Lee Tusman * Joris J.van Zundert * Annette Vee * Dan Verständig * Yohanna Waliya * Shu Wan * Peggy WEIL * Jacque Wernimont * Katherine Yang * Zach Whalen * Elea Zhong * TengChao Zhou
CCSWG 2024 is coordinated by Lyr Colin (USC), Andrea Kim (USC), Elea Zhong (USC), Zachary Mann (USC), Jeremy Douglass (UCSB), and Mark C. Marino (USC) . Sponsored by the Humanities and Critical Code Studies Lab (USC), and the Digital Arts and Humanities Commons (UCSB).

Code Critiques: Jupyter Notebooks/Taroko Gorge/Flight of the CodeMonkeys

I'm launching this as a code critique thread, but really it's more about tools for studying code. We're always on the lookout for new environs for Critical Code Studies. We've used Scalar combined with a code repository, Google Docs, Wordpress plugins, and others. Lately, I've been excited about Google's instantiation of Jupyter Notebooks.

In Colaboratory, code readers can share python code in a Google Doc-like setting. The code in those docs can be compiled, altered, and run.

I'd like to use this thread as a place to discuss Colaboratory/Jupyter Notebooks as a venue or workspace for Critical Code Studies.

Taroko Gorge is here for our collective annotation.

For another example, I offer my own interactive fiction Flight of the CodeMonkeys as another example of using Colaboratory/Jupyter Notebooks. In that story, the reader plays by interacting with the code.

I could also imagine using Colaboratory/Jupyter Notebooks to teach lessons in CCS, inviting students to interact with, annotate, and alter code in this shared environment?

What do you think about the possibilities for this tool? I invite you also to try experiments and share them here.


  • I'm really rather taken with "Flight of the Code Monkeys". However, the reason I'm posting is to ask a specific question about the (at time of writing, current) annotation on "Taroko Gorge".

    Specifically, "elegance" is mentioned twice.

    Clearly, there's an evolutionary advantage in us having an emotional response to things (better to jump directly to fearing a lion than to begin to work through the syllogism, "all lions eat people, I am a person, therefore I'd better scarper."). What is quite amazing is how that mechanism seems also capable of giving rise to aesthetic responses to some incredibly abstract things: ask any mathematician why a particular proof is considered elegant for a demonstration.

    What I want to ask is, can you describe what you find elegant about

    def x(s): return s.split(',')

    Defining the functions to single letters for elegance.

    and particularly,

    def site():
        return f(c(x('a,b')))+'s '+c(x('linger,dwell,rest,relax,hold,dream,hum'))

    The site format demonstrates elegant recursion.

    (I can say more about this from my own perspective but I'd like to see this through the eyes of the annotator first, if possible.)

  • @jang , I've got to apologize. I made a lot of these comments very quickly just (to put some in as placeholders), so we don't need to hold on to them. Just replace them with whatever you'd like.

  • No apology needed! I'm interested in this from a pedagogical stance. One of the things students do is mimic various behaviours as they try to approximate "elegance" - the development of an aesthetic response is part of learning the craft. At the same time, they refine mental models of computation.

    So I'm very interested to hear people describe perceived elegance. What jumps out at one person differs from the next; it's that notion I'm keen to hear people talk about.

  • I don't want to be overly coy, though.

    def x(s): return s.split(',')

    The split that happens here is what I consider elegant because that's what allows @nickm to create an easily human-readable list of possible variables, rather than have lists that look something more like this:

    b=x('flow', 'basin', 'shape', 'vein', 'rippling', 'stone', 'cove', 'rock')

    This goes along with my further sense that @nickm has human readers in mind for this code.

  • One of the ideas we try to introduce to programmers is that all code should be written with human readers in mind - it's seldom the case that anything is written once and never looked at again. It's a vital skill to communicate effectively; the desire is that a stranger looking at your code will find it straightforward to follow. (Three days after you write the code, you will be that stranger! :-) )

    So yes, there's a natural tension between the machinery and paraphernalia of a language required to get the job done (the "ceremony"), and the clear exposition of the solution. As we gain familiarity with a language, we learn standard idioms - and then tend to become "blind" to the use of these idioms; they no longer obscure the meaning of code.

    So you might see

    b = ['flow', 'basin', ...] # etc

    in common Python - or even

    b = "flow basin ...".split()

    which cuts down on some of the repetitive punctuation. (The use of a different delimiter from the default - whitespace - permits embedded spaces in the resulting items.) A Python programmer would barely notice these - although they jump out of the page obtrusively, perhaps, to a reader of the code not immersed in the language. (The former, maybe, less intrusive than the latter, although still a pain to type.) The desire to remove extraneous clutter is a good one.

    Probably the most extreme example of this in common use is in the gettext library - which supports the localisation of strings in code. Instead of writing

    printf("Shall I compare thee to a summer's day?\n");

    the strings are wrapped in a call to _:

    printf(_("Shall I compare thee to a summer's day?\n"));

    and the machinery of the gettext system can extract these strings for external localisation. The choice of _ - the smallest legal identifier - is to minimise the visual clutter of the application of that function call.

    Attempts to get the language details out of the way can lead to other constructs, too. You'll see this in fluent APIs - where the underlying implementation of an API may be complicated by the approach, but the use of that interface, by client code, reads more naturally. At the extreme end of the scale we find DSLs (domain-specific languages) - new syntax that lets us focus on solutions to the problem space by using the language of the problem domain.

    So that certainly explains the desire to use a short identifier. Why x though? Oddly enough, it seems an appropriate choice. It's small, square, and fits in nicely with other necessary punctuation. c was obviously chosen for its mnemonic effect. Is there some other glyphic significance to the x? A "cut here" icon perhaps?

  • which cuts down on some of the repetitive punctuation. (The use of a different delimiter from the default - whitespace - permits embedded spaces in the resulting items.) A Python programmer would barely notice these - although they jump out of the page obtrusively, perhaps, to a reader of the code not immersed in the language. (The former, maybe, less intrusive than the latter, although still a pain to type.) The desire to remove extraneous clutter is a good one.

    Your comment has me reflecting further on the choice of the split at the comma. On second glance, what's notable is not the way that choice makes the code easier to read -- because as you note, the abbreviations make this code more challenging to read (and I suspect the aesthetics of a kind of minimalism drove that -- creating a simple looking passage of code, or perhaps the word is "spare.")

    Instead, the split at the comma makes instead the data portion of the code easier to read for those, as you say, who are not immersed in the language. Keeping in mind that this is work of electronic literature has been remade or remixed by many artists. Taking the quotation marks out from each item, leaves the remixer only to worry about one punctuation mark, the comma, one that seems to be used as it is in natural language. Thinking about my students working yesterday in tracery, trying to keep track of their # and " I see how this particular choice facilitated these adaptations, especially by those who may not have coded much before. (Of course, many of the remixers are experienced programmers).

  • In the annotatable code, I just commented:

    MM: The arrays separated out for easy examination.

    RJ: But what about these pastoral objects. Are we returning to Romantic or trasncendental literature? Is this a retreat?

    JD: It is a certain kind of attention, certainly. The dateline is not very pastoral at all (a plane flight), the comments acknowledge the human infrastructure (caves are carved tunnels, sites are viewing platforms), then the function names themselves become more abstract (only path() recalls a built environment) and finally, the output itself contains none of these. That said, the output is focused on a lot of things that aren't objects, and the design might be maximizing interplay in the generated text between descriptions of the landscape and of the traveler / travel experience -- the fact that this strategy eliminates anything that cannot refer to both/either a mountain or a person (like "railing") might just be a side-effect of targeting that Venn diagram, rather than the goal.

    To continue here: I think I'm even more interested in how Taroko Gorge might relate to contemporary thinking on pastoral modes, such as the pastoral seen through ecocriticism. In particular, I find myself wondering if string-data vocabularies and / or algorithms can constitute forms of ecological attention in a way that makes the pastoral relevant?

    As a thought experiment, what might happen if we ran an image search for photographs of "Taroko Gorge" gorge&tbm=isch and then ran those images through an object detection algorithm (such as R-CNN or Yolo). We would get a list of word labels for objects -- some of which might be things like "rock, trees, water", and others of which might be things like "person, backpack, fence, railing, bridge, rope, light, sign" (and some of which might surprise us).

    We could then explore contrasts between those two modes of describing / apprehending / evoking Taroko Gorge -- the generator wrapped around carefully minimal hand-curated word lists to produce a class of outputs and the processor using a model to react to a class of inputs. Some words or concepts might appear in both the detection list and Montfort's code / output, some might appear in only one or the other. (Additionally, a multitude of things that are present in Taroko Gorge would appear in neither list.)

    We might then think about what relation these two things have to the pastoral as a mode of experiencing national park visits. For example, parks may invite visitors to contemplate spectacular "nature" while ignoring the built infrastructure that makes the parks accessible and enables visitors to do their contemplating. Parks may also / simultaneously valorize their infrastructure. What do we see here that works with or against such form of imagination?

Sign In or Register to comment.