Welcome to the first week of the 2020 Critical Code Studies Working Group. During this week, we’ll be introducing critical code studies in general by means of the introductory chapter to the forthcoming book Critical Code Studies (The MIT Press). We’ll also take this week as an opportunity to introduce newcomers to the field but also to take stock in where the field has come and to look forward to where it is headed next.

Critical code studies names the applications of hermeneutics to the interpretation of the extrafunctional significance of computer computer source code…. Extra here means not outside of or in addition to but instead growing out of…. CCS holds that the lines of code of a program are not value-neutral and can be analyzed using the theoretical approaches applied to other semiotic systems, in addition to particular interpretive methods developed specifically for the discussions of programs.

But what does it mean to explore culture through code?

Mark answers this question in the book, reading code as varied as the leaked software from the Climategate scandal to code written by media philosopher Friedrich Kittler. He reads art objects like the Transborder Immigrant Tool, variants of electronic literature works like Taroko Gorge, and code languages like the English-like precursor to COBOL, FLOW-MATIC. He explores low level to high level languages, from ASSEMBLY to Inform 7, including languages in Arabic (قلب or ’alb), Hawiian (in the ʻAnuʻu project), and Cree. (For much more on Indigenous Programming, look forward to our Week 2 discussion). In a medium most consider to be merely an operationalized mathematics, readings of code lead him to discuss issues of racial and ethnic bias and the gendered bias he calls encoded chauvinism. These readings have grown out of and reference discussions from past Critical Code Studies Working Groups because these collectives, these gathering of such varied minds, have the ability to identify so many complex meanings.

In the epilogue to the CCS book, Mark claims we have reached a moment where “philosophers process, poets publish, and curators collect code knowing scholars will interpret it as discourse” (227) -- in other words, where the basic tenets of critical code studies, that code is meaningful, have been widely accepted. How does that acceptance change the culture of code? How does that facilitate what we are trying to do here?

Because code has become accepted as a means of expression, we now have new works choosing code as one of their communication channels. Consider: Eugenio Tisselli's “Amazon” webpage, released over Twitter. Created in response to this summer’s devastating fires, Tisselli’s code articulated his despair over the environmental effects of globalized capitalism. Code was able to serve as his language of expression because, as, Alex McCLean and Geoff Cox have written, Code Speaks.

see related discussion: amazon.html by Euguenio Tisselli

Code is a social medium and its meaning is also social. The “critical” aspect of critical code studies looks to explore, among other aspects, this social dimension, especially as it pertains to power relations, across differences of race, gender, sexuality, and socio-economic status or class. “Critical” code studies is not technological history at the service of digital industries, it is an exploration of human culture in code complete with biases, abuses, inconsistencies, and injustices. CCS is an alternative to “uncritically documenting military-industrial-academic artifacts on behalf of those who created them to the benefit of their creators’ self-regard” (238). We aspire to more.

At the same time, it is worthwhile to look to critical theories and philosophical paradigms that you have found useful or would like to apply but perhaps can’t see how. Or maybe you have come across some code that you can’t read or can’t find a critical hand hold on. (This is a good time to introduce some of your code critique threads).

Programming has continued to evolve. New and strange languages have emerged. With the advent of contemporary machine learning algorithms, more code is being generated by software, code that programmers may never deal with directly. How does meaning change in such contexts? As more people discuss algorithms, what can the study of code add to those conversations?

So we invite the CCS community to begin this week of the Working Group with a broad, reflexive conversation, a thread that invites you to look back and forward, that invites you to express your thoughts about the potential obstacles for critical code studies as well as your own insights and inspirations.

Some questions:

• What do you want to know about CCS?
• What are the next challenges for Critical Code Studies? Current puzzles?
• What projects would we like to launch in the coming years? An edited collection? Conference?
• How has CCS been most productive?
• What are some current questions or problems that CCS is uniquely suited to addressing?
• What are the lacuna or blindspots--what should should CCS be addressing that it is not currently?

In the Week 1 Introduction to Critical Code Studies we mention Tisselli's piece amazon.html as an example of contemporary code as cultural discourse. Below is an overview and questions on amazon.html, presented in the form of a Working Group code critique for discussion.

Title: amazon.html
By: Euguenio Tisselli
Source: https://twitter.com/motorhueso/status/1157758552662040577
Code: HTML/JavaScript
Date: Aug. 3, 2019
Released via Twitter

Code:

<!doctype html><html><head><meta charset="utf-8"><title>amazon</title><style>body{margin:0;overflow:hidden;}#x{text-align:center;padding-top:30px;}.p{line-height:0.3;display:block;}.q{font-size:2em;font-family:"Courier";letter-spacing:-5px;}</style></head><body><div id="x"></div>

<script>var s=5e3;var c=["#37ae3c","#236e12","#7bab2e"];var x=document.getElementById("x");function g(y){return ~~(Math.random()*y);}var i=60;while(i--){var d=document.createElement("DIV");d.className="p";var j=50;while(j--){var t=document.createElement("SPAN");t.className="q";

http://t.style.color=c[g(c.length)];t.textContent="*";d.appendChild(t);}x.appendChild(d);}function m(){var e=x.children[g(x.children.length)];var f=e.children[g(e.children.length)];http://f.style.color="#795548";f.textContent=String.fromCharCode(g(10)+48);

s=s>100?s-100:10;setTimeout(m,s);}setTimeout(m,s);</script></body></html>

Overview

On August 3rd, 2019, Euguenio Tisselli posted “amazon.html”: a series of four plaintext code fragments of HTML with embedded JavaScript, all published as a single Twitter thread,[¹] along with instructions:

copy the following code (all of it, follow the thread), paste it on a plain text editor, save it as 'amazon.html', double click on the file so it shows in your browser... and watch #capitalocene unfold before your eyes!
#visual #code #poetry

https://twitter.com/motorhueso/status/1157758552662040577

Individually, each fragment does nothing. When one does assemble the fragments and run amazon.html in a contemporary web browser[²] the result is a large field of hundreds of asterisk characters of varying shades of green, evoking map or satellite view of a forest. Very slowly, green characters are replaced with brown numerals. Over time the process accelerates, until only a field of shifting numbers remains.

In his tweet thread, Tisselli also linked to a page where “you can see it live” (http://motorhueso.net/amazon/), however that page also did not present the running code. Instead, it offered the same code as a single text block of HTML with embedded JavaScript (a one-liner, in fact, labeled “length: 873 bytes”) along with similar instructions to cut, paste, save, and run.[³] The reader is asked to do this in order to witness what the code performs.[⁴]

Both sources (the Twitter thread and the hosting webpage) contain similar commentaries on contexts of meaning for amazon.html. The thread contains a photo of Amazon rainforest clearcutting, along with a quote on the “tipping point” of deforestation; the webpage simply links to the source 2019 EcoWatch article “Amazon Deforestation Rate Hits 3 Football Fields Per Minute, Data Confirms” while providing additional artist’s commentary on what it means to “watch the capitalocene unfold before your eyes” -- and on the role of algorithm and code in the piece.

what is destroying the forest? it is the capitalist algorithm, executed by fascist war-men/machines. remove the algorithm from bodies and minds, smash the killer machines!

code is the vector that transforms your desires into data // code extracts desires from your body, delivers them to the machine, and transports them through the full stack // code is what connects your infinite boredom to the tragedy of burning forests

Due to the nature of the piece, the code is available in three forms: as fragments, as a one-liner, and as a user-generated file necessary for the piece to run. In all cases, the code is pre-minified or compressed, as is common in both commercial HTML+JavaScript and in aesthetic code art / play practices such as quines, esoteric languages, and code golf. An interesting aspect of this minification is that it is unlikely (although not impossible) that Tisselli actually composed or revised the code in this form. Instead, there might be (or might have been) an original author’s source code that was later minified before being published. [Edit: In fact, the code was authored in minified form.]

Minified code, however, may be difficult to read (and annotate). It can largely be reversed by running it through parsers to add white space and unpack dense structures for each of the three syntax types in the document: HTML, CSS, and JavaScript. [⁵] A resulting decompressed form of amazon.html looks like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>
      amazon
    </title>
    <style>
      body {
        margin: 0;
        overflow: hidden;
      }
      #x {
        text-align: center;
        padding-top: 30px;
      }
      .p {
        line-height: 0.3;
        display: block;
      }
      .q {
        font-size: 2em;
        font-family: "Courier";
        letter-spacing: -5px;}
    </style>
  </head>
  <body>
    <div id="x"></div>
    <script>
      var s = 5e3;
      var c = ["#37ae3c", "#236e12", "#7bab2e"];
      var x = document.getElementById("x");
      function g(y) {
          return ~~(Math.random() * y);
      }
      var i = 60;
      while (i--) {
          var d = document.createElement("DIV");
          d.className = "p";
          var j = 50;
          while (j--) {
              var t = document.createElement("SPAN");
              t.className = "q";
              t.style.color = c[g(c.length)];
              t.textContent = "*";
              d.appendChild(t);
          }
          x.appendChild(d);
      }
      function m() {
          var e = x.children[g(x.children.length)];
          var f = e.children[g(e.children.length)];
          f.style.color = "#795548";
          f.textContent = String.fromCharCode(g(10) + 48);
          s = s > 100 ? s - 100 : 10;
          setTimeout(m, s);
      }
      setTimeout(m, s);
    </script>
  </body>
</html>

Questions for Discussion

How to approach such code, and what to ask about it?

• We could question its form of representation and related idioms (ASCII art, helicopter and satellite photography, et cetera).
• We could what it is and does -- is it random, is it interactive, does it change continuously or in stages, what is its model and/or what is it modeling, et cetera.
• We could talk about its aesthetics -- at run time, in its presentation, and in the way it was coded / composed.
• We could consider its intertextual references -- the related EcoWatch and Guardian articles, as well as whether its form is inspired by, an homage to, or borrowed / taken ready-made from other prior code.
• We might consider it in the context of other work by Tisselli, or other discourse on the capitaloscene.
• We could investigate about the relationships between the processes the user must perform to run the code and the code processes.
• We could consider audience and platform: for example, can amazon.html be composited, saved, and loaded easily on a contemporary smartphone, or is it primarily accessible only to laptop users, and if so how does that relate to its dissemination through Twitter?
• We might also consider questions of preservation, archiving, and dissemination. If this piece is worth talking about, is it worth keeping accessible three years, ten years, or fifty years from now? What would that accessibility look like, and what do the roles of artists, commentators, or scholars look like in that process?
• Finally, what might any of this tell us about how amazon.html relates to the Amazon rainforest, deforestation, the capitaloscene, or algorithmic culture more broadly?

Amazon rainforest clearcutting photo tweeted by Tiisselli.

// Approach 1
function anagram(text) {
  var a = text.split("");
  for (var i = 0; i < a.length; i += 1) {
    var letter = a[i];
    var j = Math.floor(Math.random() * a.length);
    a[i] = a[j];
    a[j] = letter;
  }
  return a.join("");
}

and

// Approach 2
function anagram(text) {
  return text.split("").sort(function () {return 0.5- Math.random()}).join("");
}

A thing to note about these is that they don't achieve the same thing. I initially posted a demonstration of that here.

Functionality

Firstly, note that both approaches are biased in terms of the distribution of permutations they create.

There's a simple counting argument here as to the bias in the two approaches. (Both might be suitable for a follow-up question during this hypothetical interview.)

For the first approach, we make n swaps, each picking a target from n elements. There are thus n^n potential paths through the algorithm. However, there are n! distinct permutations. Because the former value doesn't divide cleanly by the latter [example: n = 8, n! = 40320, n^n = 16777216, 16777216 isn't evenly divisible by 40320], the argument is that there must be some bias in the outcome - some "anagrams" crop up more frequently than others. (This is evident even when we're producing anagrams of a simple string like "abc", which you can try by hand.)

For the second approach, any analysis of behaviour needs to rely on the fact that the sorting algorithm is likely to have been picked with a runtime of n . log_2 n. [There are multiple ways to implement a sort, but that's a common behaviour. For n=8, a sort may make 8 . (log_2 8) = 24 comparisons.] Each time the sort algorithm makes a comparison, it'll perform one of two operations: swap, or don't swap. Thus, there are 2 ^ (n log_2 n) potential paths through the algorithm - or again, n^n. [For the case n=8, this comes out as 16777216 again.]

However, sorting algorithms try hard to not make comparisons when they "know" what the result would be; thus, this approach produces a much stronger bias in the sampled outcomes. Indeed, some potential anagrams of eight characters don't show up at all during the sample run.

[Assuming the sort function isn't broken, all permutations can turn up - we'd just require far more runs before we expected to see the extreme cases.]

On the question of which of those approaches is "stronger": the first approach produces outputs which are closer to uniform. Additionally, it requires a far smaller change to bring its output to a strictly uniform distribution. The second approach may be "clever", but it's by no means clear that it could be adjusted, should uniformity of output be desired.

If I had to interpret those two samples, I'd say it was much more likely that the second was a reproduction of a trick seen elsewhere, whereas the first seems more likely to be an on-the-spot invention.

The desirability of uniformity of distribution and the problem statement

Why desire a uniform distribution? There's certainly a certain symmetrical draw to it. At the other end of the spectrum, sorting all input characters may suffice - or simply returning the input string. (Where Unicode strings are concerned, "returning the value you've been given" is about the safest thing you can do - see below.)

If the requirement in the problem statement ["An anagram contains all the same characters of the initial string or word in a different order"] is a strong one, then the last option doesn't work - and both of the suggested approaches also have a flaw. However, under those circumstances, we should note that there are inputs where no algorithm can meet a strict interpretation of that requirement. [Examples: any single-character string, or "AAA", etc.]

There may be other, less specific versions of "better," when picking a distribution - for instance, finding letter-orderings which produce more challenging anagrams for a human solver, or ones that embed wry phrases.

Pedantry to one side, however...

Broader observation

In typical i18n-blindness, all approaches here don't deal correctly with combining characters and other tricky Unicode features.

I'd also observe that there's a western bias - perhaps even an Anglophone one - to the problem statement. I'm not sure that the notion of an anagram even applies across all the languages that Unicode covers. But the problem there can be found closer to home: if you asked Herr Gauß how many anagrams his surname generated, the answer probably wouldn't be 24. The Unicode consortium offers some partial approaches to dealing with this, but they are by no means comprehensive (and a desire for a comprehensive approach is misplaced, usually arising from an underestimation of how complex the problem space is). Software that deals with human text is notoriously hard to get even close to correct in a cross-cultural fashion. (cf. the question of "how should software handle names?" which has been the subject of a number of writeups.)