Week 1: Where is the Critical in Critical Code Studies?

Comments

• davidmberry

  January 12 edited January 12

  Mark and Jeremy, thank you for such a generative (!!) introduction. I think you've captured something key about the stakes of CCS work, particularly in your identification of the science wars redux and the intellectual redlining Tara McPherson identified. What you've laid out is not just a problem of method, but a tension in how we understand computational culture writ large and also the additional challenges of vibe coding and LLMs.

  I think you reveal something interesting about where CCS now stands. We're not arguing for critical code studies' legitimacy anymore, we are starting to map its terrain and interrogating its methods. This seems to me to mark a shift from a kind of defensive justification to a much more productive move towards what Imre Lakatos called a research programme. The question "where is the critical in critical code studies?" assumes that the field exists, that it has accumulated enough work to justify reflection on method. I think that means CCS is maturing into a stronger disciplinary formation.

  The dialectical overview you've laid out, with synthesis generated through close reading, maps onto a deeper epistemological problem about how computational objects can be known at all. Code exists at multiple levels, as materiality (e.g. voltage states, magnetic mediums), as a formal system (e.g. the formalism of syntax, semantics), as a cultural practice (e.g. practices, norms, communities), and, of course, as political economy (e.g. labour, accumulation, power). I wonder if this is a place to ask whether the concept of totality has something to offer to CCS? How do we navigate between these levels without reducing one to another – is it possible for us to grasp the whole rather than the parts – or is this a false synthesis?

  This is why the working group has become part of the answer to your question. By bringing people with different disciplinary expertise to examine the same code objects together, we're not just combining perspectives but generating truly interdisciplinary knowledge. We might say the computer scientist sees patterns the CCS practitioner misses whereas the critical theorist asks questions the programmer takes for granted or may not realise it is a question at all.

  What's needed is not just critique but what I think of as constellational analysis, showing how technical, economic, political, cultural forces converge in particular computational assemblages. This means reading code alongside business logic, interfaces with labour, algorithms through ideology critique, code even through AI methods. We should certainly question the separation of the technical from social that your presentation of intellectual redlining lays out so well.

  But I would like to offer an additional provocation, that we need to also create new concepts and (perhaps a new set of keywords) to understand what I am increasingly thinking of as not the mediation of code and software but its intermediation (Vermittlung).
• michael.falk

  January 13 edited January 13

  I wonder how the critic fits into the "constellation" that David describes. When we talk about "close reading," we sometimes overlook the act of reading itself. Who is reading? Where? How? Jeremy mentioned an upcoming article on "Reading Code Aloud" in the plenary video. This set me thinking...

  In the meetings of my online CCS group, we read code aloud, together. This has been an interesting challenge, because there is no canonical pronunciation for code. For example, you can read the following snippet of LISP/Scheme in several ways:

  (* (/ 3 2) (+ x 7.))
  

  This could be pronounced:

  "Open parenthesis, asterisk, open parenthesis, slash, three, two, close parenthesis, open parenthesis, plus sign, x, seven dot, close parenthesis, close parenthesis."

  Many members of the group lean towards a more "orthographic" pronunciation like this. Or you might interpret the symbols:

  "The multiplication of the quotient of 3 and 2 and the sum of x and 7.0."

  Or you can read and gloss it at the same time. Let's assume that x represents the velocity of some object in a simulation.

  "Three divided by two, which are both integers, times the velocity plus 7, which are both reals."

  This problem of how to pronounce code points, I think, to the rightness of David's "constellation" idea. The meaning of the code depends entirely on its context. We are constantly negotiating the contexts of reading in our group. What contexts are necessary to recover the literal meaning of the code, so we can discuss its interpretations? How much interpretation is too much when we recite the code? Can we even agree on a "literal" level of meaning, which can then become the object of critique? We are still trying to identify the stars by which to navigate these questions.

  In answer to the question, "Where is the critical?", I would say that it lies in this "constellation" of agreements between the critics, which establish relevant contexts for discussion.
• AlanBlackwell

  January 13

  I’m so pleased to see this question being addressed explicitly. Although I’ve occasionally and tangentially engaged with CCS, in the past couple of years I have (like so many) had a lot of my attention taken by Critical AI studies, and have been contributing to related debate in that field. From my own perspective, as an AI researcher turned programming language designer, again turned AI commentator, I’ve never seen a clear distinction between AI and PLs, meaning that “criticality” for me applies equally to creation of code and to creation of AI systems. The commonality between AI and PLs is that these are information processing tools, requiring clarity about the distinction between critique of a tool and critique of a product. In classical domains of cultural production, we critique the painting not the paintbrush, and the carving not the chisel. (Although I have personally worked on the critical analysis of the violin, as well as analysis of music). The distinct property of both AI and PL is that the mutability of the tools requires recursive reflexivity to a degree unseen in other objects of critique, while also rendering language as tool in a way that invites many category errors. Boundaries of agency and behaviour are blurred between the mechanical and the semiotic, in a way we have not really seen before. From my own perspective, primarily as a tool-maker rather than critic, I often return to Phil Agre to ask where the practice can be located, for engagement with my own critical technical practice community. I’m looking forward to learning further critical orientations and resources, but are there any other members of this group who will be looking to applications in practice?
• iaine

  January 13

  I do agree with the point regarding legitimacy of the field being established with the various special issues and this working group. Here I think that the need to reflexively go forward with using/developing methods on code while considering the role of code and models in reading code and models.

  The constellational analytical approach is useful in bringing together the many layers and approaches to reading code. It also, to me, seems to offer an inclusionary way into CCS for interested parties. I hope that I have not misunderstood Michael Falk’s point in the reading aloud of code, but it seems to me that the differing readings offer alternative perspectives on that bit of LISP/Scheme.

  Does the critic work in concert/choreography with others within the constellation to find overlaps and gaps between perspectives? This working group, although my first time participating, seems to be an answer to developing both critique and conversations across perspectives and skills. My intuition is that there will always be gaps in analysis of code and that trying to link all the varying layers as a complete will create a false synthesis. Those gaps may either enable further work or reflection.
• jshrager

  January 13 edited January 13

  Oh. Interesting. I had read this in a completely different way. (I'm sort of out of my element here, not being a media studies person, so what I'm about to say might be just plain nonsense, and if so yo can just ignore it.) What I thought the question was asking is something like: If I was in the middle of debugging a big complex program -- like I literally was until 3am this morning -- and I had Mark Marino sitting at my elbow, what would he be asking me, and telling me, and would I find that useful or annoying? (Or perhaps a better way to put that is: What sort of things that he could tell me would I find useful, and in what way?) That is, I was reading "where is the critical" ... as "how is the criticism useful to engineers?" ... probably (now that I'm reading the other responses) not what was intended ... although I'm still interested in this question, but maybe it should be in a different thread. (BTW, it's actually not far off from near reality. I "vibe code" (although I hate that term) literally all the time, and sometimes I actually ask the LLM to criticize my code, which is does but from a narrow engineering perspective. I wonder what would happen if we added a little Mark Marino to the LLM vibe coding engines? Sounds like I'm joking. I'm not!) p.s. my 3am session was a success!
• jshrager

  January 13

  @michael.falk Re reading code (in the reading aloud sense) is a very interesting cognitive process, but it seems to me to depend completely on the meaning. Arithmetic, for example, has semi-standardized ways to read, so we tend to both read and wrwite in a way that's biased by the standard way we read math. And code is written that way too. (Something that often confuses beginning lispers is that there's no infix notation for math, although it turns out that that prefix notation is more general, so instead of a+b+c+d you can just write the more advanced: sum(a,b,c,d).)

  I read this code (from something I'm working on right now):

  (if (functionp (cell-symb (h1)))
      (cell-symb (h1))                                                                      
      (if (functionp (<== (cell-symb (h1)))) 
          (<== (cell-symb (h1))))))) 
  

  As "If H1's symbol is a function then return it, otherwise if the cell H1 is pointing to is a function then return that." But this is quite specific to my understanding of my own code. Someone without that context might read it is: "If the symbol slot of the cell resulting from calling H1 is a function then return that .... etc.", but I know that (H1) is just a macro that gives me the H1 cell, and so on.

  Here's another example from the same code base:

  (loop for (nil . getter) in *symbol-col-accessors*                                                           
           as symbol = (funcall getter cell)                                                                      
           if (local-symbol-by-name? symbol)                                                                      
           collect (cons symbol (format nil "~a-~a" top-name symbol)))
  

  which I just read as "make new local symbols for all those that don't already have them". Whereas a raw reading would be something horrific like "Loop through the symbol-col-accessors and for each cdr (which is a getter), applyit to the cell, and if ...." Often things like this are complete functions (at least in lisp), and the name of the function is just the reading.

  (In fact, I sort of decry languages that don't traditionally separate their symbol names and are case sensitive, because instead of the nice human-readable (and thinkable) names like (Make-new-local-symbols-as-needed ...) you get things like MakeNewLocalSymbolsAsNeeded and can't vary the case to work nicely in sentences.)
• michael.falk

  January 13 edited January 13

  Thanks Jeff and Iain!

  Indeed, I think these different pronunciations are different "perspectives" (Iain), and I agree that the pronunciation of code depends on its "meaning" (Jeff).

  On reflection, I think what I was trying to say was this:

  In our reading group, the technical/critical distinction often maps on to the literal/meaningful distinction. When we are reading, we often struggle to understand what the code does. We normally discuss this first. When we discuss what the code does, we discuss it like engineers, and it feels like we are determining the literal meaning. Only then do we move on to discussions of the metaphors, naming conventions, assumed prior knowledge and so on, which allows us to build up a critique.

  So, as I say, when we read code aloud in my group, we often act like the technical is the literal, and lies on a lower level of analysis. The critical is the meaningful, and is built "on top of" the literal level.

  This is what it seems like when I read code aloud with friends, but as Iain and Jeff observe, even just reading the code aloud requires interpretation. Our very pronunciations imply an interpretation. Reflecting on this, the mapping technical→literal/critical→meaningful breaks down... Which I think lends support to Mark and Jeffrey's basic argument, which is that the technical view and the critical view are different orientations toward reading, rather than stacked-up levels of reading.

  On the other hand, just getting "what the code does" is also essential to critical understanding...
• michael.falk

  January 13 edited January 13

  Also, I like your shorthand way of reading, Jeff. It is funny to compare

  "make new local symbols for all those that don't already have them"

  with

  "left parenthesis, loop, left parenthesis, nil, dot, getter, right parenthesis ..."

  Where is the boundary between a recitation and a description of code? How does that spectrum map onto the technical↔critical spectrum?
• jshrager

  January 14

  Well, @michael.falk , no one ever reads code at the character level unless they’re trying to dictate it over the phone to someone who literally has never seen Lisp. (Which, BTW, I’ve done on multiple occasions! :-)

  To your point that “when we read code aloud in my group, we often act like the technical is the literal, and lies on a lower level of analysis. The critical is the meaningful, and is built "on top of" the literal level.”, I think that this is very uncommon. (Or perhaps I’m mis-taking your description.) Humans have an incredible ability to jump levels nearly instantaneously and fluidly. I saw this when I was working on how molecular biologists think: In literally the same sentence they’ll connect a molecule folding in a particular way to the way the cortex of the brain gets organized, and even (still the same sentence!) to how societies are organized. Although I have in mind a particular example here, it’s extremely common, even I would say, natural and automatic. So, back to code, one never (very rarely) just read at one level at any given time. Rather one is trying to understand what’s going on at all (or at least several) relevant levels at the same time. We saw this all the time in our reading the ELIZA code. (As in writing this I’m coming to think that this is actually exactly what you said, and I’m actually agreeing with you — so much the better!)
• JudyMalloy

  January 14

  Magnificent introduction, Mark and Jeremy!

  I remember sitting in a FORTRAN class at what is now Ball Aerospace in circa 1968. The class was primarily to convert slide rule engineers to computer use, so the code examples were of little use for what I has hired for, which was to computerize the Library. Meanwhile, my immediate boss was pioneer Chicano writer José Antonio Villarreal, who was writing The Fifth Horseman, while at the same time he was hired by Ball Aerospace as a technical writer.

  To be continued....
• luisnavarrodelangel

  January 15

  Thank you for this introduction and for explaining where the field comes from and what are key questions in the field today!
• JudyMalloy

  January 15

  It is of interest in this group that we have participants who are early examples of the humanities and changing computer science culture. LinkedIn just informed me that in November 1993 – December 1994, jshrager and I were both employed at Xerox PARC. But otherwise our very different bios reflect radical changes in comp sci culture between the 1960s and the 1970s and onward.

  The Interview “The Influence of Algorithmic Thinking: Judy Malloy and Julianne Nyhan”
  in J. Nyhan, A. Flinn, Computation and the Humanities, Springer Series on Cultural Computing, 2016

  https://link.springer.com/content/pdf/10.1007/978-3-319-20170-2_7.pdf

  very thoroughly covers my experience and is interesting as regards the CCSWG call for examples. Perhaps what we were both doing at PARC is relevant as regards this discussion. Jeff?
• JudyMalloy

  January 16

  Continuing Mark and Jeremy’s interest in bringing culture into places where culture was not expected and examples from one side or the other -- and davidmberry's response:

  “By bringing people with different disciplinary expertise to examine the same code objects together, we're not just combining perspectives but generating truly interdisciplinary knowledge.”

  -- re the Xerox PARC program , I first worked with Pavel Curtis and Rich Gold in Computer Science Lab ( CSL only hired artists with programming skills) This book covers all the work in the program:

  Craig Harris, ed, Art and Innovation: The Xerox PARC Artist-in-Residence Program, MIT Press, 1999

  https://direct.mit.edu/books/book/2566/Art-and-InnovationThe-Xerox-PARC-Artist-in

  “The idea behind Xerox's interdisciplinary Palo Alto Research Center (PARC) is simple: if you put creative people in a hothouse setting, innovation will naturally emerge. PARC's Artist-in-Residence Program (PAIR) brings artists who use new media to PARC and pairs them with researchers who often use the same media, though in different contexts. This is radically different from most corporate support of the arts, where there is little intersection between the disciplines. The result is both interesting art and new scientific innovations. Art and Innovation explores the unique process that grew from this pairing of new media artists and scientists working at the frontier of developing technologies. In addition to discussing specific works created during several long-term residencies, the artists and researchers reveal the similarities and differences in their approaches and perspectives as they engage each other in a search for new methods for communication and creativity…”

  Contents: Series Foreword / Roger F. Malina -Preface / Craig Harris -- Introduction / John Seely Brown -- 1. The Xerox Palo Alto Research Center Artist-in-Residence Program Landscape / Craig Harris -- 2. PAIR: The Xerox PARC Artist-in-Residence Program / Rich Gold -- 3. The PARC PAIR Process / Craig Harris. Cultural Repulsion or Missing Media? / David Biegelsen. An EAP Perspective / Constance Lewallen -- 4. The Place of the Artist / Steve Harrison -- 5. O Night Without Objects / Jeanne C. Finley, John Muse and Lucy Suchman / [et al.] -- 6. Public Literature: Narratives and Narrative Structures in LambdaMOO / Judy Malloy -- 7. Forward Anywhere: Notes on an Exchange Between Intersecting Lives / Judy Malloy and Cathy Marshall -- 8. Endless Beginnings: Tales from the Road to "Now Where?," / Margaret Crane, Dale MacDonald and Scott Minneman / [et al.] -- 9. An Archeology of Sound: An Anthropology of Communication / Paul De Marinis -- 10. Reflections on PAIR / Stephen Wilson -- 11. Artscience Sciencart / Michael Black, David Levy and Pamela Z. -- 12. Conduits / Joel Slayton -- 13. Art Shows at PARC / Marshall Bern.
• markcmarino

  January 17 edited January 17

  Thanks for all of this so far, everyone.

  I want to raise a different question. Is it possible that the "critical" is tied not just the way we approach and object of study but also the reason we chose that object of study in the first place. Again, keeping in mind that this working group has investigated a single line of code that creates a maze-like pattern on the screen of a Commodore 64, is it more likely that a critical reading will follow the selection of a code object with a particular hermeneutic question in mind? For example, our discussions of the Transborder Immigrant Tool. Another example would be our discussion of the code of the Apollo Lunar Lander, starting from Judy's framing of the project as a mission of recovery of the work of women in computer science and particularly in space exploration, starting with crediting Margaret Hamilton. In that discussion, we found ourselves following @JudyMalloy's lead into questions of race inequity back on earth and other more social issues, not that all of the "critical" is social?

  Let me offer for consideration this code critique thread on the ICE data appendix, a Freedom of Information Act project to scrutinize the deportations by the Immigration Control and Enforcement. Do those kinds of code snippets or code objects framed with certain critical questions yield more critical readings?