Translating Reality

Along with programming languages and algorithmic problem solving, students learn various forms of representation for both code and for reality. At first, students learn how to trace through the operation of code, to model by hand what would happen if the code runs. This is displayed in various diagrams drawn on whiteboards, printed on PowerPoint slides, or scribbled on pieces of paper when answering an exam question or trying to figure out why a program is not working. Generally variables are given little boxes. A string of characters has multiple little boxes beside each other. A particular variable type, known as a “pointer,” refers to other variables. In terms of computer operation, pointers contain the address of another variable in the computer’s memory, but when tracing a program these are represented by their own little boxes with arrows that point to the boxes of other variables. Arrays, essentially lists of elements, are represented similar to strings of characters with multiple boxes beside each other. Arrays can be multi-dimensional, however, so a two-dimensional array is then represented by a table or matrix.

The representations become more complex as the data structures that computer scientists conceptualize become more complex. Tree elements, known as nodes, gain colours. Variables are no longer small boxes, but Objects represented by large boxes with other smaller variable boxes inside of them. When tracing a program, the contents of a variable are scratched out, and replaced with the new values reached after an operation such as an addition or subtraction. As mentioned in relation to the discussion of spatial metaphors, these representations go beyond the physical form of data in the computer and work as abstractions and representations that help programmers and computer scientists conceptualize the data and their programs.

Both the variables and their representations often stand in, not just for a data structure or an extra-local abstract representation of machine operations, but also for actual world constructs. As seen in Figure 3-2, variables stand in for various concepts such as a principal amount of money, a rate of interest, and the number of years for an investment. Students later learn to model relationships between variables, and between such actual world constructs. Figure 3-3, for example, shows a representation of Marriage in Unified Modelling Language (UML), which all students learn over the course of their studies. UML provides a representation of the various objects, variables, and functions, and how they interact, within a program. This example was given to students in course notes to show them how to model relationships between classes (abstract versions of objects), such as the “married to” association embodied in the Marriage class between the Man and Woman classes. In the UML representation there is a Man, Woman, and

class “Marriage” is created because a marriage has properties and operations that are distinct from either Man or Woman.

It is also an over-simplification of how such relationships would likely be modelled in a working program, provided in this way to illustrate a concept.

Nevertheless, it clearly shows how particular assumptions about the construction of reality can be written into programs. Marriage is represented here as occurring only between a man and a woman and each Man or Woman can only have one Marriage to one entity of the “opposite” gender.

Figure 3-3: UML representation of marriage from second-year course notes

A great deal of research has explored and critiqued the ways in which particular biases and assumptions are both implicitly and explicitly built into the design of

technologies, often in relation to gender but also considerations such as how human emotions are constituted and represented, physical abilities and disabilities, and the constitution of expertise and knowledge (Alsheikh, Rode, and Lindley 2011; Berg 1999; Forsythe 2001; Huff and Cooper 1987; Oudshoorn, Rommes, and Stienstra 2004; Suchman 2011a; van Oost 2003). Much of this research focuses on Human Computer

human users, and computers and other technologies. Yet, as seen in the example above and shown by science and technology studies scholars, the underlying theories, designs, and code developed by scientists, engineers, and computer scientists also render the world in particular ways (Keller 1985; Li 2007; Martin 1991; Myers 2014, 2015).

Representing “nature” and “reality” is an integral part of scientific and technological practice (Coopmans et al. 2014; Lynch and Woolgar 1990). Computer science students are taught how UML diagrams such as the ones above are important for planning and designing large programs and specifying their functionality.

Representations in UML, algorithms, data structures, code, however, are also all performative renderings (Mackenzie 2005). In particular, many (although not all) computer languages abstract and objectify facets of the actual world constructs. Every entity represented is turned into an object in Java and in other object-oriented languages, for example, similarly seen in UML. Through these modular computational worlds, things and relationships become explicitly specified and solidified into stable representations.

Moreover, these representations work as ways of developing “solutions” to predefined “problems.” Horst W. J. Rittel and Melvin M. Webber identify “wicked” versus “benign” problems in relation to the politically and socially complex challenges that face planning and policy work (Rittel and Webber 1973).32 _{John Law further}

32 _{They outline ten properties of “wicked” problems, which essentially explain the ways that such problems}

cannot and should not be rendered technical. Their sixth property, for example, states that “wicked problems do not have enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-describable set of permissible operations that may be incorporated into the plan” (Rittel and Webber 1973, 162). While programming languages do have a clear and describable set of operations, in their

suggests that “the problems of the world are always wicked” and that the only way to handle or “tame” them is to treat them as benign, and so the interesting question is how wicked problems are rendered benign (Law 2014, 9–11). In this regard, defining a problem is for computer science the first step of this “taming,” which is done, in part, through these various forms of representation. Ultimately, these representations – and the computational worlds that they produce – become the solutions to the problems that were defined and created through their making.

There are multitudes of technological “products” that address “problems” of varying complexity that exemplify the results of this process; examples from

international and Singaporean news media include programs/apps that are meant to eliminate unconscious bias through creating anonymity (Bereznak 2017); that stop women from apologizing frequently and thus undermining their authority (Cauterucci 2015); that help women walk home safely at night (Russon 2015); that address issues related to haze (Chia 2015); and that determine when laundry machines are free in a dorm or apartment (Jeffrey 2016). The preponderance of “solutions” relating to women listed here is largely due to my interest in the topic. However, the framing of these solutions as intervening in or helping women’s identities or behaviours illustrates the ways

“problems” and “solutions” become defined through technical renderings as based on individual encounters mediated by technologies or programs, treating symptoms rather than addressing underlying causes such as patriarchal norms or, in another case, the

social, political, and economic circumstances that lead to the production of environmental haze.

Additionally significant here is how these diagrams, code, and programs are meant to represent both machine and human practice and language. It is a mediation and a translation between the complexity, nuance, ambiguity, and detail of human life, captured and modelled in variables, classes, objects, and relationships that can ultimately be translated into series of binary instructions that are transmitted through multiple circuits to produce computations that are then retranslated by computer hardware and software to register a marriage in a database, display a congratulations message on a screen, or print out a marriage certificate. In other words, the worlds that computer scientists build are both filtered reflections of constructions in the actual world and performances that constitute part of that world; these worlds intra-actively constitute reality as it is being represented, the technologies involved, and the persons developing and using them.

Following Donna Haraway, these worlds are diffractions: “the noninnocent, complexly erotic practice of making a difference in the world, rather than displacing the same elsewhere” (Haraway 1994, 63). Tara McPherson (2012), for example, suggests that the tendency towards modularity embedded in computing, and stemming in part from the development of the UNIX operating system, is intertwined with the constitution of race in the US. Computer scientists learn to sit at the middle of and orchestrate this mediation, manipulating the representation of reality and then its reconstruction through computer operations rendered into computing worlds. Feminist scholars have thus argued

that computing practices and the technologies they create need to be accountable to the worlds they produce (Rommes, Bath, and Maass 2012; Suchman 2002; van der Velden and Mortberg 2014). I discuss in the next chapter the gendered renderings of computer science knowledge and practice. Here, I consider the implications of this world-building in relation to how the history of computers and computer languages are taught and experienced by computer students.