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

Comments

• jang

  January 2020

  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.)
• markcmarino

  January 2020

  @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.
• jang

  January 2020

  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.
• markcmarino

  January 2020

  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.
• jang

  January 2020

  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?
• markcmarino

  January 2020

  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).
• jeremydouglass

  January 2020

  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" https://www.google.com/search?q=taroko 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?