Howdy, Stranger!

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

Participants: Derya Akbaba * Ben Allen * Natalia-Rozalia Avlona * Kirill Azernyi * Erin Kathleen Bahl * Natasha Bajc * Lucas Bang * Tully Barnett * Ivette Bayo * Eamonn Bell * John Bell * kiki benzon * Liat Berdugo * Kathi Berens * David Berry * Jeffrey Binder * Philip Borenstein * Gregory Bringman * Sophia Brueckner * Iris Bull * Zara Burton * Evan Buswell * Ashleigh Cassemere-Stanfield * Brooke Cheng* Alm Chung * Jordan Clapper * Lia Coleman * Imani Cooper * David Cuartielles * Edward de Jong * Pierre Depaz * James Dobson * Quinn Dombrowski * Amanda Du Preez * Tristan Espinoza * Emily Esten * Meredith Finkelstein * Caitlin Fisher * Luke Fischbeck * Leonardo Flores * Laura Foster * Federica Frabetti * Jorge Franco * Dargan Frierson * Arianna Gass * Marshall Gillson * Jan Grant * Rosi Grillmair * Ben Grosser * E.L. (Eloisa) Guerrero * Yan Guo * Saksham Gupta * Juan Gutierrez * Gottfried Haider * Nabil Hassein * Chengbo He * Brian Heim * Alexis Herrera * Paul Hertz * shawné michaelain holloway * Stefka Hristova * Simon Hutchinson * Mai Ibrahim * Bryce Jackson * Matt James * Joey Jones * Masood Kamandy * Steve Klabnik * Goda Klumbyte * Rebecca Koeser * achim koh * Julia Kott * James Larkby-Lahet * Milton Laufer * Ryan Leach * Clarissa Lee * Zizi Li * Lilian Liang * Keara Lightning * Chris Lindgren * Xiao Liu * Paloma Lopez * Tina Lumbis * Ana Malagon * Allie Martin * Angelica Martinez * Alex McLean * Chandler McWilliams * Sedaghat Payam Mehdy * Chelsea Miya * Uttamasha Monjoree * Nick Montfort * Stephanie Morillo * Ronald Morrison * Anna Nacher * Maxwell Neely-Cohen * Gutierrez Nicholaus * David Nunez * Jooyoung Oh * Mace Ojala * Alexi Orchard * Steven Oscherwitz * Bomani Oseni McClendon * Kirsten Ostherr * Julia Polyck-O'Neill * Andrew Plotkin * Preeti Raghunath * Nupoor Ranade * Neha Ravella * Amit Ray * David Rieder * Omar Rizwan * Barry Rountree * Jamal Russell * Andy Rutkowski * samara sallam * Mark Sample * Zehra Sayed * Kalila Shapiro * Renee Shelby * Po-Jen Shih * Nick Silcox * Patricia Silva * Lyle Skains * Winnie Soon * Claire Stanford * Samara Hayley Steele * Morillo Stephanie * Brasanac Tea * Denise Thwaites * Yiyu Tian * Lesia Tkacz * Fereshteh Toosi * Alejandra Trejo Rodriguez * Álvaro Triana * Job van der Zwan * Frances Van Scoy * Dan Verständig * Roshan Vid * Yohanna Waliya * Sam Walkow * Kuan Wang * Laurie Waxman * Jacque Wernimont * Jessica Westbrook * Zach Whalen * Shelby Wilson * Avery J. Wiscomb * Grant Wythoff * Cy X * Hamed Yaghoobian * Katherine Ye * Jia Yu * Nikoleta Zampaki * Bret Zawilski * Jared Zeiders * Kevin Zhang * Jessica Zhou * Shuxuan Zhou

Guests: Kayla Adams * Sophia Beall * Daisy Bell * Hope Carpenter * Dimitrios Chavouzis * Esha Chekuri * Tucker Craig * Alec Fisher * Abigail Floyd * Thomas Forman * Emily Fuesler * Luke Greenwood * Jose Guaraco * Angelina Gurrola * Chandler Guzman * Max Li * Dede Louis * Caroline Macaulay * Natasha Mandi * Joseph Masters * Madeleine Page * Mahira Raihan * Emily Redler * Samuel Slattery * Lucy Smith * Tim Smith * Danielle Takahashi * Jarman Taylor * Alto Tutar * Savanna Vest * Ariana Wasret * Kristin Wong * Helen Yang * Katherine Yang * Renee Ye * Kris Yuan * Mei Zhang
Coordinated by Mark Marino (USC), Jeremy Douglass (UCSB), and Zach Mann (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.