Why Are the Digital Humanities So White? or Thinking the Histories of Race and Computation
In mid-October 2008, the American Studies Association (ASA) hosted its annual conference in Albuquerque, New Mexico. According to its website, the ASA “is the nation’s oldest and largest association devoted to the interdisciplinary study of American culture and history.” Over the past two decades, the ASA conference has emerged as a leading venue for vibrant discussions about race, ethnicity, transnationalism, gender, and sexuality. While the ASA represents scholars with a diverse array of methodological approaches from a variety of disciplines, the society is a welcome home to academics whose work is interpretative and theoretical. During the meeting, I attended a variety of panels engaging such issues and approaches and came away feeling energized and refreshed, my intellectual imagination stoked by the many ways in which race and ethnicity were wielded as central terms of analysis throughout the long weekend.
The following week, I was off to Baltimore where I attended “Tools for Data-Driven Scholarship,” a workshop funded by the National Science Foundation (NSF), the National Endowment for the Humanities, and the Institute of Museum and Library Services. This invitation-only event was cohosted by George Mason University’s Center for History and New Media (CHNM) and the Maryland Institute for Technology in the Humanities (MITH), two pioneering centers of what we have recently begun to call the “digital humanities.” This workshop built upon several years’ conversation (particularly following the 2003 NSF Atkins Report on cyberinfrastructure) about the need for a digital infrastructure for humanities computing. The goal of the workshop was defined in the e-mail invite as a report “that discusses the needs of tools developers and users; sets forth objectives for addressing those needs; proposes infrastructure for accomplishing these objectives; and makes suggestions for a possible RFP.” This meeting was also lively, full of thoughtful discussions about the possibilities for (and obstacles in the way of) a robust infrastructure for scholars engaged in computation and the humanities. The conversation certainly fired up my technological imagination and subsequently led to useful discussions with my collaborators in technological design.1
As I flew home following this second event, I found myself reflecting on how far my thoughts had ranged in the course a mere week: from diaspora to database, from oppression to ontology, from visual studies to visualizations. And, once again, I found myself wondering why it seemed so hard to hold together my long-standing academic interests in race, gender, and certain modes of theoretical inquiry with my more recent (if decade-old) immersion in the world of digital production and design.
While the workshop I participated in at ASA was titled “American Studies at the Digital Crossroads” and drew a nice crowd, the conference as a whole included remarkably little discussion of digital technologies (although there were some analyses of digital texts such as websites and video games.)2 It is largely accurate, if also a generalization, to say that many in the membership of the ASA treat computation within the humanities with some level of suspicion, perceiving it to be complicit with the corporatization of higher education or as primarily technological rather than scholarly.3 (Indeed, this attitude is shared by a large number of “traditional” humanities scholars across any number of fields or professional societies who do not work with digital media.) In a hallway chat following our workshop, one scholar framed his dis-ease as a question: “Why are the digital humanities, well, so white?” And while my memory is far from perfect, I think it is safe to say that the Baltimore workshop included no discussion of many topics much in evidence at ASA, topics including immigration, race, and neoliberalism. To be fair, this was a workshop focused on the notion of tools and infrastructure, so one might not expect such discussions. Nonetheless, this essay will argue that we desperately need to close the gap between these two modes of inquiry. Further, I will argue that the difficulties we encounter in knitting together our discussions of race (or other modes of difference) with our technological productions within the digital humanities (or in our studies of code) are actually an effect of the very designs of our technological systems, designs that emerged in post–World War II computational culture. These origins of the digital continue to haunt our scholarly engagements with computers, underwriting the ease with which we partition off considerations of race in our work in the digital humanities and digital media studies.
U.S. Operating Systems at Midcentury: The Intertwining of Race and UNIX
Let us turn to two fragments cut from history, during the 1960s.
In the early 1960s, computer scientists at MIT were working on Project MAC, an early set of experiments in Compatible Timesharing Systems for computing. By 1965, MULTICS (Multiplexed Information and Computing Service), a mainframe timesharing operating system, was in use, with joint development by MIT, GE, and Bell Labs, a subsidiary of AT&T. The project was funded by ARPA (Advanced Research Projects Agency) of the Defense Department for two million dollars a year for eight years. MULTICS introduced early ideas about modularity in hardware structure and software architecture.
In 1969, Bell Labs stopped working on MULTICS, and that summer one of their engineers, Ken Thompson, developed the beginning of UNIX. While there are clearly influences of MULTICS on UNIX, the later system also moves away from the earlier one, pushing for increased modularity and for a simpler design able to run on cheaper computers.
In simplest terms, UNIX is an early operating system for digital computers, one that has spawned many offshoots and clones. These include MAC OS X as well as LINUX, indicating the reach of UNIX over the past forty years. The system also influenced non-UNIX operating systems like Windows NT and remains in use by many corporate IT divisions. UNIX was originally written in assembly language, but after Thompson’s colleague Dennis Ritchie developed the C programming language in 1972, Thompson rewrote UNIX in that language. Basic text-formatting and editing features were added (i.e., early word processors). In 1974, Ritchie and Thompson published their work in the journal of the Association for Computing Machinery, and UNIX began to pick up a good deal of steam.4
UNIX can also be thought of as more than an operating system, as it also includes a number of utilities such as command line editors, APIs, code libraries, and so on. Furthermore, UNIX is widely understood to embody particular philosophies and cultures of computation, “operating systems” of a larger order that we will return to.
Of course, for scholars of culture, of gender, and of race like the members of the ASA, dates like 1965 and 1968 have other resonances. For many of us, 1965 might not recall MULTICS but instead the assassination of Malcolm X, the founding of the United Farm Workers, the burning of Watts, or the passage of the Voting Rights Act. The mid-1960s also saw the origins of the American Indian Movement (AIM) and the launch of the National Organization for Women (NOW). The late 1960s mark the 1968 citywide walkouts of Latino youth in Los Angeles, the assassinations of Martin Luther King Jr. and Robert F. Kennedy, the Chicago Democratic Convention, the Stonewall Riots, and the founding of the Black Panthers and the Young Lords. Beyond the geographies of the United States, we might also remember the Prague Spring of 1968, Tommie Smith and John Carlos at the Mexico Summer Olympics, the Tlatelolco Massacre, the execution of Che Guevara, the Chinese Cultural Revolution, the Six-Day War, or May ’68 in Paris. On the African continent, thirty-two countries gained independence from colonial rulers. In the United States, broad cultural shifts emerged across the decade, as identity politics took root and countercultural forces challenged traditional values. Resistance to the Vietnam War mounted as the decade wore on. Abroad, movements against colonialism and oppression were notably strong.
The history just glossed as “Fragment One” is well known to code junkies and computer geeks. Numerous websites archive oral histories, programming manuals, and technical specifications for MULTICS, UNIX, and various mainframe and other hardware systems. Key players in that history, including Ken Thompson, Donald Ritchie, and Doug McIlroy, have a kind of geek-chic celebrity status, and differing versions of the histories of software and hardware development are hotly debated, including nitty-gritty details of what really counts as “a UNIX.” In media studies, emerging work in “code studies” often resurrects and takes up these histories.5
Within American, cultural, and ethnic studies, the temporal touchstones of struggles over racial justice, antiwar activism, and legal history are also widely recognized and analyzed. Not surprisingly, these two fragments typically stand apart in parallel tracks, attracting the interest and attention of very different audiences located in the deeply siloed departments that categorize our universities.
In short, I suggest that these two moments are deeply interdependent. In fact, they coconstitute one another, comprising not independent slices of history but instead related and useful lenses into the shifting epistemological registers driving U.S. and global culture in the 1960s and after.
This history of intertwining and mutual dependence is hard to sketch. As one delves into the intricacies of UNIX (or of XML), race in America recedes far from our line of vision and inquiry. Likewise, detailed examinations into the shifting registers of race and racial visibility post-1950 do not easily lend themselves to observations about the emergence of object-oriented programming or the affordances of databases. Very few audiences who care about one lens have much patience or tolerance for the other.
Early forays into new media theory in the late 1990s and much concurrent work in the computational humanities rarely helped this problem. Theorists of new media often retreated into forms of analysis that Marsha Kinder has critiqued as “cyberstructuralist,” intent on parsing media specificity and on theorizing the forms of new media while disavowing twenty-plus years of critical race theory, feminism, and other modes of overtly politicized inquiry. Much of the work in the digital humanities also proceeded as if technologies from XML to databases were neutral tools.6 Many who had worked hard to instill race as a central mode of analysis in film, literary, and media studies throughout the late twentieth century were disheartened and outraged (if not that surprised) to find both new media theory and emerging digital tools seem indifferent to those hard-won gains.
Early analyses of race and the digital often took two forms: first, a critique of representations in new media or the building of digital archives about race, modes that largely were deployed at the surface of our screens, or, second, debates about access to media—that is, the digital divide. Such work rarely tied race to the analyses of form, phenomenology, or computation that were so compelling in the work of Lev Manovich, Mark Hansen, or Jay Bolter and Richard Grusin. Important works emerged from both “camps,” but the camps rarely intersected. A few events attempted to force a collision between these areas, but the going was tough. For instance, at the two Race and Digital Space Conferences colleagues and I organized in 2000 and 2002, the vast majority of participants and speakers were engaged in work in the two modes mentioned earlier. The cyberstructuralists were not in attendance.
But what if this very incompatability is itself part and parcel of the organization of knowledge production that operating systems like UNIX helped to disseminate around the world? Might we ask whether there is not something particular to the very forms of electronic culture that seems to encourage just such a movement, a movement that partitions race off from the specificity of media forms? Put differently, might we argue that the very structures of digital computation develop at least in part to cordon off race and to contain it? Further, might we come to understand that our own critical methodologies are the heirs to this epistemological shift?
From early writings by Sherry Turkle and George Landow to more recent work by Alex Galloway and others, new media scholars have noted the parallels between the ways of knowing modeled in computer culture and the greatest hits of structuralism and poststructuralism. Critical race theorists and postcolonial scholars like Chela Sandoval and Gayatri Spivak have illustrated the structuring (if unacknowledged) role that race plays in the work of poststructuralists like Roland Barthes and Michel Foucault. We might bring these two arguments together, triangulating race, electronic culture, and poststructuralism, and, further, argue that race, particularly in the United States, is central to this undertaking, fundamentally shaping how we see and know as well as the technologies that underwrite or cement both vision and knowledge. Certain modes of racial visibility and knowing coincide or dovetail with specific ways of organizing data: if digital computing underwrites today’s information economy and is the central technology of post–World War II America, these technologized ways of seeing and knowing took shape in a world also struggling with shifting knowledges about and representations of race. If, as Michael Omi and Howard Winant argue, racial formations serve as fundamental organizing principles of social relations in the United States, on both the macro and micro levels (55), how might we understand the infusion of racial organizing principles into the technological organization of knowledge after World War II?
Omi and Winant and other scholars have tracked the emergence of a “race-blind” rhetoric at midcentury, a discourse that moves from overt to more covert modes of racism and racial representation (e.g., from the era of Jim Crow to liberal colorblindness). Drawing from those 3-D postcards that bring two or more images together even while suppressing their connections, I have earlier termed the racial paradigms of the postwar era “lenticular logics.” The ridged coating on 3-D postcards is actually a lenticular lens, a structural device that makes simultaneously viewing the various images contained on one card nearly impossible. The viewer can rotate the card to see any single image, but the lens itself makes seeing the images together very difficult, even as it conjoins them at a structural level (i.e., within the same card). In the post–civil rights United States, the lenticular is a way of organizing the world. It structures representations but also epistemologies. It also serves to secure our understandings of race in very narrow registers, fixating on sameness or difference while forestalling connection and interrelation. As I have argued elsewhere, we might think of the lenticular as a covert mode of the pretense of separate but equal, remixed for midcentury America (McPherson, 250).
A lenticular logic is a covert racial logic, a logic for the post–civil rights era. We might contrast the lenticular postcard to that wildly popular artifact of the industrial era, the stereoscope card. The stereoscope melds two different images into an imagined whole, privileging the whole; the lenticular image partitions and divides, privileging fragmentation. A lenticular logic is a logic of the fragment or the chunk, a way of seeing the world as discrete modules or nodes, a mode that suppresses relation and context. As such, the lenticular also manages and controls complexity.
And what in the world does this have to do with those engineers laboring away at Bell Labs, the heroes of the first fragment of history this essay began with? What’s race got to do with that? The popularity of lenticular lenses, particularly in the form of postcards, coincides historically not just with the rise of an articulated movement for civil rights but also with the growth of electronic culture and the birth of digital computing (with both—digital computing and the civil rights movement—born in quite real ways of World War II). We might understand UNIX as the way in which the emerging logics of the lenticular and of the covert racism of color blindness get ported into our computational systems, both in terms of the specific functions of UNIX as an operating system and in the broader philosophy it embraces.
In moving toward UNIX from MULTICS, programmers conceptualized UNIX as a kind of tool kit of “synergistic parts” that allowed “flexibility in depth” (Raymond, 9). Programmers could “choose among multiple shells…. [and] programs normally provide[d] many behavior options” (6). One of the design philosophies driving UNIX is the notion that a program should do one thing and do it well (not unlike our deep disciplinary drive in many parts of the university); this privileging of the discrete, the local, and the specific emerges again and again in discussions of UNIX’s origins and design philosophies.
Books for programmers that explain the UNIX philosophy revolve around a common set of rules. While slight variations on this rule set exist across programming books and online sites, Eric Raymond sets out the first nine rules as follows:
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. (13)
Other rules include the Rules of Least Surprise, Silence, Repair, Economy, Generation, Optimization, Diversity, and Extensibility.7
These rules implicitly translate into computational terms the chunked logics of the lenticular. For instance, Brian Kernighan wrote in a 1976 handbook on software programming that “controlling complexity is the essence of computer programming” (quoted in Raymond, 14). Complexity in UNIX is controlled in part by the Rule of Modularity, which insists that code be constructed of discrete and interchangeable parts that can be plugged together via clean interfaces. In Design Rules, Vol. 1: The Power of Modularity, Carliss Baldwin and Kim Clark argue that computers from 1940 to 1960 had “complex, interdependent designs,” and they label this era the “premodular” phase of computing (149). While individuals within the industry, including John von Neumann, were beginning to imagine benefits to modularity in computing, Baldwin and Clark note that von Neumann’s ground-breaking designs for computers in that period “fell short of true modularity” because “in no sense was the detailed design of one component going to be hidden from the others: all pieces of the system would be produced ‘in full view’ of the others” (157). Thus one might say that these early visions of digital computers were neither modular nor lenticular. Baldwin and Clark track the increasing modularity of hardware design from the early 1950s forward and also observe that UNIX was the first operating system to embrace modularity and adhere “to the principles of information hiding” in its design (324).
There are clearly practical advantages of such structures for coding, but they also underscore a worldview in which a troublesome part might be discarded without disrupting the whole. Tools are meant to be “encapsulated” to avoid “a tendency to involve programs with each others’ internals” (Raymond, 15). Modules “don’t promiscuously share global data,” and problems can stay “local” (84–85). In writing about the Rule of Composition, Eric Raymond advises programmers to “make [programs] independent.” He writes, “It should be easy to replace one end with a completely different implementation without disturbing the other” (15). Detachment is valued because it allows a cleaving from “the particular …conditions under which a design problem was posed. Abstract. Simplify. Generalize” (95). While “generalization” in UNIX has specific meanings, we might also see at work here the basic contours of a lenticular approach to the world, an approach that separates object from context, cause from effect.
In a 1976 article, “Software Tools,” Bell Lab programmers Kernighan and P. J. Plauger urged programmers “to view specific jobs as special cases of general, frequently performed operations, so they can make and use general-purpose tools to solve them. We also hope to show how to design programs to look like tools and to interconnect conveniently” (1). While the language here is one of generality (as in “general purpose” tools), in fact, the tool library that is being envisioned is a series of very discrete and specific tools or programs that can operate independently of one another. They continue, “Ideally, a program should not know where its input comes from nor where its output goes. The UNIX time-sharing system provides a particularly elegant way to handle input and output redirection” (2). Programs can profitably be described as filters, even though they do quite complicated transformations on their input. One should be able to say
program-1 … | sort | program-2 …
and have the output of program-1 sorted before being passed to program-2. This has the major advantage that neither program-1 nor program-2 need know how to sort, but can concentrate on its main task (4).
In effect, the tools chunk computational programs into isolated bits where the programs’ operations are meant to be “invisible to the user” and to the other programs in a sequence: “the point is that this operation is invisible to the user (or should be)…. Instead he sees simply a program with one input and one output. Unsorted data go in one end; somewhat later, sorted data come out the other. It must be convenient to use a tool, not just possible” (5). Kernighan and Plauger saw the “filter concept” as a useful way to get programmers to think in discrete bits and to simplify their code, reducing the potential complexity of programs. They note that “when a job is viewed as a series of filters, the implementation simplifies, for it is broken down into a sequence of relatively independent pieces, each small and easily tested. This is a form of high-level modularization” (5). In their own way, these filters function as a kind of lenticular frame or lens, allowing only certain portions of complex data sets to be visible at a particular time to both the user and the machine.
The technical feature that allowed UNIX to achieve much of its modularity was the development by Ken Thompson (based on a suggestion by Doug McIlroy) of the pipe—that is, a vertical bar that replaced the symbol for greater than (>) in the operating system’s code. As described by Doug Ritchie and Ken Thompson in a paper for the Association of Computing Machinery in 1974 (reprinted by Bell Labs in 1978), “A read using a pipe file descriptor waits until another process writes using the file descriptor for the same pipe. At this point, data are passed between the images of the two processes. Neither process need know that a pipe, rather than an ordinary file, is involved” (480). In this way, the ability to construct a pipeline from a series of small programs evolved, while the “hiding of internals” was also supported. The contents of a module were not central to the functioning of the pipeline; rather, the input or output (a text stream) was key. Brian Kernighan noted “that while input/output direction predates pipes, the development of pipes led to the concept of tools—software programs that would be in a ‘tool box,’ available when you need them” and interchangeable.8 Pipes reduced complexity and were also linear. In “Software Tools,” Kernighan and Plauger extend their discussion of pipes, noting that “a pipe provides a hidden buffering between the output of one program and the input of another program so information may pass between them without ever entering the file system” (2). They also signal the importance of pipes for issues of data security:
And consider the sequence
decrypt key <file | prog | encrypt key > newfile
Here a decryption program decodes an encrypted file, passing the decoded characters to a program having no special security features. The ouput of the program is re-encrypted at the other end. If a true pipe mechanism is used, no clear-text version of the data will ever appear in a file. To simulate this sequence with temporary files risks breaching security. (3)
While the affordances of filters, pipes, and hidden data are often talked about as a matter of simple standardization and efficiency (as when Kernighan and Plauger argue that “our emphasis here has been on getting jobs done with an efficient use of people” ), they also clearly work in the service of new regimes of security, not an insignificant detail in the context of the cold war era. Programming manuals and UNIX guides again and again stress clarity and simplicity (don’t write fancy code; say what you mean as clearly and directly as you can), but the structures of operating systems like UNIX function by hiding internal operations, skewing “clarity” in very particular directions. These manuals privilege a programmer’s equivalent of common sense in the Gramscian sense. For Antonio Gramsci, common sense is a historically situated process, the way in which a particular group responds to “certain problems posed by reality which are quite specific” at a particular time (324). As programmers constituted themselves as a particular class of workers in the 1970s, they were necessarily lodged in their moment, deploying common sense and notions about simplicity to justify their innovations in code. Importantly, and as we will see, this moment is overdetermined by the ways in which the United States is widely coming to process race and other forms of difference in more covert registers, as noted earlier, even if the programmers themselves do not explicitly understand their work to be tied to such racial paradigms.9
Another rule of UNIX is the Rule of Diversity, which insists on a mistrust of the “one true way.” Thus UNIX, in the words of one account, “embraces multiple languages, open extensible systems and customization hooks everywhere,” reading much like a description of the tenets of neoliberal multiculturalism (Raymond, 24). Certain words emerge again and again throughout the ample literature on UNIX: modularity, compactness, simplicity, orthogonality. UNIX is meant to allow multitasking, portability, time sharing, and compartmentalizing. It is not much of a stretch to layer these traits over the core tenets of post-Fordism, a mode of production that begins to remake industrial-era notions of standardization in the 1960s: time-space compression, transformability, customization, a public/private blur, and so on. UNIX’s intense modularity and information-hiding capacity were reinforced by its design—that is, in the ways in which it segregated the kernel from the shell. The kernel loads into the computer’s memory at start-up and is “the heart” of UNIX (managing “hardware memory, job execution, and time sharing”), although it remains hidden from the user (Baldwin and Clark, 332). The shells (or programs that interpret commands) are intermediaries between the user and the computer’s inner workings. They hide the details of the operating system from the user behind “the shell,” extending modularity from a rule for programming in UNIX to the very design of UNIX itself.10
Modularity in the Social Field
This push toward modularity and the covert in digital computation also reflects other changes in the organization of social life in the United States by the 1960s. For instance, if the first half of the twentieth century laid bare its racial logics, from “Whites Only” signage to the brutalities of lynching, the second half increasingly hides its racial “kernel,” burying it below a shell of neoliberal pluralism. These covert racial logics take hold at the tail end of the civil rights movement at least partially to cut off and contain the more radical logics implicit in the urban uprisings that shook Detroit, Watts, Chicago, and Newark. In fact, the urban center of Detroit was more segregated by the 1980s than in previous decades, reflecting a different inflection of the programmer’s vision of the “easy removal” or containment of a troubling part. Whole areas of the city might be rendered orthogonal and disposable (also think post-Katrina New Orleans), and the urban black poor were increasingly isolated in “deteriorating city centers” (Sugrue, 198). Historian Thomas Sugrue traces the increasing unemployment rates for black men in Detroit, rates that rose dramatically from the 1950s to the 1980s, and maps a “deproletarianization” that “shaped a pattern of poverty in the postwar city that was surprisingly new” (262). Across several registers, the emerging neoliberal state begins to adopt the Rule of Modularity. For instance, we might draw an example from across the Atlantic. In her careful analysis of the effects of May 1968 and its afterlives, Kristin Ross argues that the French government contained the radical force of the uprisings by quickly moving to separate the students’ rebellion from the concerns of labor, deploying a strategy of separation and containment in which both sides (students and labor) would ultimately lose (69).
Modularity in software design was meant to decrease “global complexity” and cleanly separate one “neighbor” from another (Raymond, 85). These strategies also played out in ongoing reorganizations of the political field throughout the 1960s and 1970s in both the Right and the Left. The widespread divestiture in the infrastructure of inner cities can be seen as one more insidious effect of the logic of modularity in the postwar era. But we might also understand the emergence of identity politics in the 1960s as a kind of social and political embrace of modularity and encapsulation, a mode of partitioning that turned away from the broader forms of alliance-based and globally inflected political practice that characterized both labor politics and antiracist organizing in the 1930s and 1940s.11 While identity politics produced concrete gains in the world, particularly in terms of civil rights, we are also now coming to understand the degree to which these movements curtailed and short-circuited more radical forms of political praxis, reducing struggle to fairly discrete parameters.
Let me be clear. By drawing analogies between shifting racial and political formations and the emerging structures of digital computing in the late 1960s, I am not arguing that the programmers creating UNIX at Bell Labs and in Berkeley were consciously encoding new modes of racism and racial understanding into digital systems. (Indeed, many of these programmers were themselves left-leaning hippies, and the overlaps between the counterculture and early computing culture run deep, as Fred Turner has illustrated.) I also recognize that their innovations made possible the word processor I am using to write this article, a powerful tool that shapes cognition and scholarship in precise ways. Nor am I arguing for some exact correspondence between the ways in which encapsulation or modularity work in computation and how they function in the emerging regimes of neoliberalism, governmentality, and post-Fordism. Rather, I am highlighting the ways in which the organization of information and capital in the 1960s powerfully responds—across many registers—to the struggles for racial justice and democracy that so categorized the United States at the time. Many of these shifts were enacted in the name of liberalism, aimed at distancing the overt racism of the past even as they contained and cordoned off progressive radicalism. The emergence of covert racism and its rhetoric of color blindness are not so much intentional as systemic. Computation is a primary delivery method of these new systems, and it seems at best naive to imagine that cultural and computational operating systems don’t mutually infect one another.
Thus we see modularity take hold not only in computation but also in the increasingly niched and regimented production of knowledge in the university after World War II. For instance, Christopher Newfield comments on the rise of New Criticism in literature departments in the cold war era, noting its relentless formalism, a “logical corollary” to “depoliticization” (145) that “replaced agency with technique” (155). He attributes this particular tendency in literary criticism at least in part to the triumph of a managerial impulse, a turn that we might also align (even if Newfield doesn’t) with the workings of modular code (itself studied as an exemplary approach to dynamic modeling systems for business management in the work of Baldwin and Clark cited earlier.)12 He observes as well that this managerial obsession within literary criticism exhibits a surprising continuity across the 1960s and beyond. Gerald Graff has also examined the “patterned isolation” that emerges in the university after World War II, at the moment when New Criticism’s methods take hold in a manner that deprivileges context and focuses on “explication for explication’s sake.” Graff then analyzes the routinization of literary criticism in the period, a mechanistic exercise with input and output streams of its own (227). He recognizes that university departments (his example is English) begin to operate by a field-based and modular strategy of “coverage,” in which subfields proliferate and exist in their own separate chunks of knowledge, rarely contaminated by one another’s “internals” (250). (He also comments that this modular strategy includes the token hiring of scholars of color who are then cordoned off within the department.) Graff locates the beginning of this patterned isolation in the run-up to the period that also brought us digital computing; he writes that it continues to play out today in disciplinary structures that have become increasingly narrow and specialized. Patterned isolation begins with the bureaucratic standardization of the university from 1890 through 1930 (61–62), but this “cut out and separate” mentality reaches a new crescendo after World War II as the organizational structure of the university pushes from simply bureaucratic and Taylorist to managerial, a shift noted as well by Christopher Newfield. Many now lament the overspecialization of the university; in effect, this tendency is a result of the additive logic of the lenticular or of the pipeline, where “content areas” or “fields” are tacked together without any sense of intersection, context, or relation. Today, we risk adding the digital humanities to our proliferating disciplinary menus without any meaningful and substantial engagement with fields such as gender studies or critical race theory.
It is interesting to note that much of the early work performed in UNIX environments was focused on document processing and communication tools and that UNIX is a computational system that very much privileges text (it centers on the text-based command line instead of on the graphical user interface, and its inputs and outputs are simple text lines). Many of the methodologies of the humanities from the cold war through the 1980s also privilege text while devaluing context and operate in their own chunked systems, suggesting telling parallels between the operating systems and privileged objects of the humanities and of the computers being developed on several university campuses in the same period.
Lev Manovich has, of course, noted the modularity of the digital era and also backtracked to early twentieth-century examples of modularity from the factory line to the creative productions of avant garde artists. In a posting to the Nettime listserv in 2005, he frames modularity as a uniquely twentieth-century phenomenon, from Henry Ford’s assembly lines to the 1932 furniture designs of Belgian designer Louis Herman De Kornick. In his account, the twentieth century is characterized by an accelerating process of industrial modularization, but I think it is useful to examine the digital computer’s privileged role in the process, particularly given that competing modes of computation were still quite viable until the 1960s, modes that might have pushed more toward the continuous flows of analog computing rather than the discrete tics of the digital computer. Is the modularity of the 1920s really the same as the modularity modeled in UNIX? Do these differences matter, and what might we miss if we assume a smooth and teleological triumph of modularity? How has computation pushed modularity in new directions, directions in dialogue with other cultural shifts and ruptures? Why does modularity emerge in our systems with such a vengeance across the 1960s?
I have here suggested that our technological formations are deeply bound up with our racial formations and that each undergo profound changes at midcentury. I am not so much arguing that one mode is causally related to the other but, rather, that they both represent a move toward modular knowledges, knowledges increasingly prevalent in the second half of the twentieth century. These knowledges support and enable the shift from the overt standardized bureaucracies of the 1920s and 1930s to the more dynamically modular and covert managerial systems that are increasingly prevalent as the century wears on. These latter modes of knowledge production and organization are powerful racial and technological operating systems that coincide with (and reinforce) (post)structuralist approaches to the world within the academy. Both the computer and the lenticular lens mediate images and objects, changing their relationship but frequently suppressing that process of relation, much like the divided departments of the contemporary university. The fragmentary knowledges encouraged by many forms and experiences of the digital neatly parallel the logics that underwrite the covert racism endemic to our times, operating in potential feedback loops, supporting each other. If scholars of race have highlighted how certain tendencies within poststructuralist theory simultaneously respond to and marginalize race, this maneuver is at least partially possible because of a parallel and increasing dispersion of electronic forms across culture, forms that simultaneously enact and shape these new modes of thinking.
While the examples here have focused on UNIX, it is important to recognize that the core principles of modularity that it helped bring into practice continue to impact a wide range of digital computation, especially the C programming language, itself developed for UNIX by Ritchie, based on Thompson’s earlier B language. While UNIX and C devotees will bemoan the nonorthogonality and leakiness of Windows or rant about the complexity of C++, the basic argument offered earlier—that UNIX helped inaugurate modular and lenticular systems broadly across computation and culture—holds true for the black boxes of contemporary coding and numerous other instances of our digital praxis.
Today, we might see contemporary turns in computing—neural nets, clouds, semantics, and so on—as parallel to recent turns in humanities scholarship to privilege networks over nodes (particularly in new media studies and in digital culture theory) and to focus on globalization and its flows (in American studies and other disciplines). While this may simply mean we have learned our midcentury lessons and are smarter now, we might also continue to examine with rigor and detail the degree to which dominant forms of computation—what David Golumbia has aptly called “the cultural logic of computation” in his recent update of Frankfurt School pessimism for the twenty-first century—continue to respond to shifting racial and cultural formations. Might these emerging modes of computation be read as symptoms and drivers of our postracial moment, refracting in some way national anxieties (or hopes) about a decreasingly white America? We should also remain alert to how contemporary technoracial formations infect privileged ways of knowing in the academy. While both the tales of C. P. Snow circa 1959 and the Sokal science wars of the 1990s sustain the myth that science and the humanities operate in distinct realms of knowing, powerful operating systems have surged beneath the surface of what and how we know in the academy for well over half a decade. It would be foolish of us to believe that these operating systems—in this paper best categorized by UNIX and its many close siblings—do not at least partially overdetermine the very critiques we imagine that we are performing today.
Moving Beyond Our Boxes
So if we are always already complicit with the machine, what are we to do?
First, we must better understand the machines and networks that continue to powerfully shape our lives in ways that we are often ill equipped to deal with as media and humanities scholars. This necessarily involves more than simply studying our screens and the images that dance across them, moving beyond the study of representations and the rhetorics of visuality. We might read representations seeking symptoms of information capital’s fault lines and successes, but we cannot read the logics of these systems and networks solely at the level of our screens. Capital is now fully organized under the sign of modularity. It operates via the algorithm and the database, via simulation and processing. Our screens are cover stories, disguising deeply divided forms of both machine and human labor. We focus exclusively on them increasingly to our peril.
Scholars in the digital humanities and in the emerging field of code studies are taking up the challenge of understanding how computational systems (especially but not only software) developed and operate. However, we must demand that these fields not replay the formalist and structuralist tendencies of new media theory circa 1998. This formalist turn displayed a stubborn technological determinism and often privileged the machine over the social. To end run such determinism, the digital humanities and code studies must also take up the questions of culture and meaning that animate so many scholars of race in fields like the new American studies. Likewise, scholars of race must analyze, use, and produce digital forms and not smugly assume that to engage the digital directly is to be complicit with the forces of capitalism. The lack of intellectual generosity across our fields and departments only reinforces the divide-and-conquer mentality that the most dangerous aspects of modularity underwrite. We must develop common languages that link the study of code and culture. We must historicize and politicize code studies. And, because digital media were born as much of the civil rights era as of the cold war era (and of course these eras are one and the same), our investigations must incorporate race from the outset, understanding and theorizing its function as a ghost in the digital machine. This does not mean that we should simply add race to our analysis in a modular way, neatly tacking it on or building digital archives of racial material, but that we must understand and theorize the deep imbrications of race and digital technology even when our objects of analysis (say UNIX or search engines) seem not to be about race at all. This will not be easy. In the writing of this essay, the logic of modularity continually threatened to take hold, leading me into detailed explorations of pipe structures in UNIX or departmental structures in the university, taking me far from the contours of race at midcentury. It is hard work to hold race and computation together in a systemic manner, but it is work that we must continue to undertake.
We also need to take seriously the possibility that questions of representation and of narrative and textual analysis may, in effect, divert us from studying the reorganization of capital—a reorganization dependent on the triumph of the very particular patterns of informationalization evident in code. If the study of representation may in fact be part and parcel of the very logic of modularity that such code inaugurates, a kind of distraction, it is equally plausible to argue that our very intense focus on visuality in the past twenty years of scholarship is just a different manifestation of the same distraction. There is tendency in film and media studies to treat the computer and its screens as (in Jonathan Beller’s terms) a “legacy” technology to cinema. In its drive to stage continuities, such an argument tends to minimize or completely miss the fundamental material differences between cinematic visuality and the production of the visual by digital technologies. For most of the twentieth century, cinema was a profoundly visual (if also aural) form, with images etched into celluloid; the digital does not depend on vision in any analogous way.
To push my polemic to its furthest dimensions, I would argue that to study image, narrative, and visuality will never be enough if we do not engage as well the nonvisual dimensions of code and their organization of the world. Yet to trouble my own polemic, we might also understand the workings of code to have already internalized the visual to the extent that, in the heart of the labs from which UNIX emerged, the cultural processing of the visual via the register of race was already at work in the machine.
In extending our critical methodologies, we must have at least a passing familiarity with code languages, operating systems, algorithmic thinking, and systems design. We need database literacies, algorithmic literacies, computational literacies, interface literacies. We need new hybrid practitioners: artist-theorists, programming humanists, activist-scholars; theoretical archivists, critical race coders. We need new forms of graduate and undergraduate education that hone both critical and digital literacies. We have to shake ourselves out of our small, field-based boxes so that we might take seriously the possibility that our own knowledge practices are normalized, modular, and black boxed in much the same way as the code we study in our work. That is, our very scholarly practices tend to undervalue broad contexts, meaningful relation, and promiscuous border crossing. While many of us identify as interdisciplinary, very few of us extend that border crossing very far (theorists tune out the technical; the technologists are impatient of the abstract; scholars of race mock the computational, seeing it as corrupt). The intense narrowing of our academic specialties over the past fifty years can actually be seen as an effect of or as complicit with the logics of modularity and the relational database. Just as the relational database works by normalizing data—that is, by stripping it of meaningful, idiosyncratic context, creating a system of interchangeable equivalencies—our own scholarly practices tend to exist in relatively hermetically sealed boxes or nodes. Critical theory and poststructuralism have been powerful operating systems that have served us well; they were as hard to learn as the complex structures of C++, and we have dutifully learned them. They are also software systems in desperate need of updating and patching. They are lovely, and they are not enough. They cannot be all we do, but that is not to say that they are not of any value.
In universities that simply shut down “old school” departments—like at my university, German and geography; in the UK, Middlesex’s philosophy program; in Arizona, perhaps all of ethnic studies; in Albany, anything they can—scholars must engage the vernacular digital forms that make us nervous, authoring in them in order to better understand them and to recreate in technological spaces the possibility of doing the work that moves us. We need new practices and new modes of collaboration; we need to be literate in emerging scientific and technological methodologies but also in theories of race, globalization, and gender. We’ll gain that literacy at least partially through an intellectual generosity or curiosity toward colleagues whose practices are not our own. We need to privilege systemic modes of thinking that can understand relation and honor complexity, even while valuing precision and specificity. We need nimbler ways of linking the network and the node and digital form and content, and we need to understand that categories like race profoundly shape both form and content. In short, we need a good deal more exchange between the ASA and the digital humanities so that we might develop some shared languages and goals. We must take seriously the question, why are the digital humanities so white? but also ask why American studies is not more digital.
We must remember that computers are themselves encoders of culture. If, in the 1960s and 1970s, UNIX hardwired an emerging system of covert racism into our mainframes and our minds, then computation responds to culture as much as it controls it. Code and race are deeply intertwined, even as the structures of code labor to disavow these very connections.13 Politically committed academics with humanities skill sets must engage technology and its production not simply as an object of our scorn, critique, or fascination but as a productive and generative space that is always emergent and never fully determined.
1. For the past decade, I have had the privilege to work with a team of collaborators on a variety of digital projects, including the online journal Vectors and a new authoring platform Scalar. In Los Angeles, this team includes Steve Anderson, Craig Dietrich, and Erik Loyer (and, until recently, Raegan Kelly), among others, and it is impossible to overstate how thoroughly I have been reconfigured by the opportunity to interact with such smart and congenial people. Conversations over the years (including at the Baltimore summit) with the broader DH community have deeply shaped our approach to developing computational systems for the humanities.
This essay is a revised version of a piece originally written for Race after the Internet, edited by Peter Chow-White and Lisa Nakamura, forthcoming from Routledge. Feedback from Neil Fraistat, Matt Gold, David Golumbia, and Steve Ramsay helped sharpen the piece for this volume.
2. This panel was organized by Glenn Hendler and Bruce Burgett, both of whom have worked quite tirelessly to engage the ASA community in conversations about the digital humanities. In addition to the three of us, Randy Bass, Sharon Daniel, Deborah Kimmey, and Curtis Marez were also on the panel. Tim Powell had been on the original program but was unable to attend.
3. These tensions between traditional humanities scholars and computational humanists are, of course, not new. For examples of these dynamics within early waves of humanities computing, see Thomas, “Computing and the Historical Imagination,” and Craig, “Stylistic Analysis and Authorship Studies.” As these authors note from within the realms of authorship studies and historical studies, these tensions often played out over the differences between quantitative and qualitative analysis and via debates on the status and validity of various modes of interpretation. Two readers (Golumbia and Ramsay) of this piece during the volume’s semiopen peer review process expressed discomfort with the use of the term “traditional” to describe humanities scholars who don’t consider themselves DHers. I share that discomfort, particularly since the word “traditional” seems to imply conservative, not a term many would associate with the ASA today, at least in a political sense. Instead, I mean the term simply to signal scholars in the humanities whose methodologies are not primarily dependent on digital analysis, platforms, or tools.
4. UNIX develops with some rapidity at least in part because the parent company of Bell Labs, AT&T, was unable to enter the computer business due to a 1958 consent decree. Eric Raymond notes that “Bell Labs was required to license its nontelephone technology to anyone who asked” (33). Thus a kind of counterculture chic developed around UNIX. Raymond provides a narrative version of this history, including the eventual UNIX wars, in his The Art of UNIX Programming. His account, while thorough, tends to romanticize the collaborative culture around UNIX. For a more objective analysis of the imbrications of the counterculture and early computing cultures, see Fred Turner’s From Counterculture to Cyberculture. See also Tom Streeter for a consideration of liberal individualism and computing cultures.
5. Critical code studies (and software studies more generally) take up the study of computational systems in a variety of ways. For an overview of software studies, see Fuller. For emerging work in critical code studies, see the proceedings of the 2010 conference on Critical Code Studies, archived at http://vectorsjournal.org/thoughtmesh/critcode.
6. Some scholars have questioned the neutral status of digital structures such as code and databases. John Unsworth has situated UNIX as a Western cultural formation, arguing that “UNIX is deeply indebted to culturally determined notions such as private property, class membership, and hierarchies of power and effectivity. Most of these ideas are older than the modern Western culture that produced UNIX, but the constellation of cultural elements gathered together in UNIX’s basic operating principles seems particularly Western and capitalist—not surprisingly, given that its creators were human extensions of one of the largest accumulations of capital in the Western world” (142). See also David Golumbia’s observations on the limits of the database and of semantic computing for humanities analysis, as well as work on culturally contextual databases and ontologies undertaken by Kimberly Christen and Ramesh Srinivasan. Golumbia has further argued that object-oriented programming privileges categorization and hierarchies in a manner that has “much more to do with engineering presumptions and ideologies than with computational efficiency” (209). His work is a must read for anyone caught up in utopian readings of digital culture’s empowering and participatory aspects.
7. In comments on a draft of this essay, Steve Ramsay suggested that Mike Gancarz’s The Unix Philosophy categorizes UNIX via a related but different rule set. His rule set (4–5) is as follows:
1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.
Both Raymond and Gancarz privilege many of the same elements, including modularity, portability, and a certain notion of simplicity. See, for example, Gancarz’s discussion of code modules and pipes (116).
8. This quote from Kernighan is from “The Creation of the UNIX Operating System” on the Bell Labs website. See http://www.bell-labs.com/history/unix/philosophy.html.
9. For Gramsci, “common sense” is a multilayered phenomenon that can serve both dominant groups and oppressed ones. For oppressed groups, common sense may allow a method of speaking back to power and of rejiggering what counts as sensible. Kara Keeling profitably explores this possibility in her work on the black femme. Computer programmers in the 1970s are interestingly situated. They are on the one hand a subculture (often overlapping with the counterculture), but they are also part of an increasingly managerial class that will help society transition to regimes of neoliberalism and governmentality. Their dreams of libraries of code may be democratic in impulse, but they also increasingly support postindustrial forms of labor.
10. Other aspects of UNIX also encode “chunking,” including the concept of the file. For a discussion of files in UNIX, see You Are Not a Gadget by Jaron Lanier. This account of UNIX, among other things, also argues that code and culture exist in complex feedback loops.
11. See, for instance, Patricia Sullivan’s Days of Hope for an account of the coalition politics of the South in the 1930s and 1940s that briefly brought together antiracist activists, labor organizers, and members of the Communist Party. Such a broad alliance became increasingly difficult to sustain after the Red Scare. I would argue that a broad cultural turn to modularity and encapsulation was both a response to these earlier political alliances and a way to short circuit their viability in the 1960s. My Reconstructing Dixie examines the ways in which a lenticular logic infects both identity politics and the politics of difference, making productive alliance and relationality hard to achieve in either paradigm.
12. To be fair, Newfield also explores a more radical impulse in literary study in the period, evident in the likes of (surprisingly) both Harold Bloom and Raymond Williams. This impulse valued literature precisely in its ability to offer an “unmanaged exploration of experience” (152).
13. There is no smoking gun that can unequivocally prove a one-to-one equation between shifting parameters of racial representation and racism and the emergence of UNIX as a very particular development in the history of computing, one that was neither necessary nor inevitable. Such proof is not my goal here. Rather, this essay asks why the midcentury turn to modularity was so deeply compelling and so widely dispersed, from urban planning to operating systems; I argue that in the United States this reorganization cannot be understood without taking into account the ways in which the nation responded to the civil rights movement. Of course, race is not the only axis of difference driving cultural change at this moment; how we understand the politics of gender and sexuality are also changing and are important to consider in relation to this essay’s broad argument. In fact, we might understand the emergence of identity politics throughout the 1960s and 1970s as part of this very logic of modularity. But I would maintain that two broad things are true. First, society is reorganizing due to pressures within the political field (i.e., due to social movements), and that race is a particularly important vector in this reorganization. Second, all technological change is deeply situated within cultural forces, and, thus, the development of UNIX needs to be read in relation to these changes even if the relationship is not one of strict linear causality. It has been interesting to note that, when presenting this work in various venues, scholars of race typically get the argument, while others are sometimes more resistant. I would suggest that perhaps this very resistance might itself be an after effect of the triumph of modularity in the contemporary academy.
“The Creation of the UNIX Operating System.” Bell Labs. http://www.bell-labs.com/history/unix/philosophy.html.
Baldwin, Carliss, and Kim Clark. Design Rules, Vol. 1: The Power of Modularity. Cambridge, Mass.: MIT Press, 2000.
Beller, Jonathan. “Re: Periodizing Cinematic Production.” Post on IDC Listserv. September 2, 2009. https://lists.thing.net/pipermail/idc/2009-September/003851.html.
Bolter, Jay, and Richard Grusin. Remediations: Understanding New Media. Cambridge, Mass.: MIT Press, 2000.
Craig, Hugh. “Stylistic Analysis and Authorship Studies.” In A Companion to Digital Humanities, edited by Susan Schreibman, Ray Siemens, and John Unsworth. Oxford: Blackwell, 2004. http://www.digitalhumanities.org/companion/.
Fuller, Matthew. Software Studies: A Lexicon. Cambrigde, Mass.: MIT Press, 2008.
Galloway, Alex. Protocol: How Control Exists after Decentralization. Cambridge, Mass.: MIT Press, 2006.
Gancarz, Mike. The Unix Philosophy. Newton, Mass.: Digital, 1995.
Graff, Gerald. Professing Literature: An Institutional History. Chicago: University of Chicago Press, 1989.
Gramsci, Antonio. Selections from the Prison Notebooks. Translated and edited by Q. Hoare and G. Nowell Smith. London: Lawrence and Wishart, 1971.
Golumbia, David. The Cultural Logic of Computation. Cambridge, Mass.: Harvard University Press, 2009.
Hansen, Mark B. N. Embodying Technesis: Technology Beyond Writing. Ann Arbor: University of Michigan Press, 2000.
Keeling, Kara. The Witch’s Flight: The Cinematic, the Black Femme, and the Image of Common Sense. Durham, N.C.: Duke University Press, 2007.
Kernighan, Brian, and P. J. Plauger. Software Tools. Reading, Mass.: Addison-Wesley, 1976.
———. “Software Tools.” ACM SIGSOFT Software Engineering Notes 1, no. 1 (May 1976): 15–20.
Kernighan, Brian, and Rob Pike. The Unix Programming Environment. Englewood Cliffs, N.J.: Prentice-Hall, 1984.
Kernighan, Brian, and D. M. Ritchie. The C Programming Language. Englewood Cliffs, N.J.: Prentice-Hall, 1978. Reprint, 1988.
Kinder, Marsha. “Narrative Equivocations between Movies and Games.” In The New Media Book, edited by Dan Harries. London: BFI, 2002: 119–32.
Landow, George. Hypertext: The Convergence of Contemporary Critical Theory and Technology. Baltimore, Md.: Johns Hopkins University Press, 1991.
Lanier, Jaron. You Are Not A Gadget: A Manifesto. New York: Knopf, 2010.
Lewis, Martin W., and Kären Wigen. “A Maritime Response to the Crisis in Area Studies.” Geographical Review 89, no. 2 (April 1999): 162.
Manovich, Lev. The Language of New Media. Cambridge, Mass.: MIT Press, 2002.
———. “We Have Never Been Modular.” Post to Nettime Listserv. November, 28, 2005. http://www.nettime.org/Lists-Archives/nettime-l-0511/msg00106.html.
McPherson, Tara. Reconstructing Dixie: Race, Place and Nostalgia in the Imagined South. Durham, N.C.: Duke University Press, 2003.
Newfield, Christopher. Ivy and Industry: Business and the Making of the American University, 1880–1980. Durham, N.C.: Duke University Press, 2004.
Omi, Michael, and Howard Winant. Racial Formation in the United States: From the 1960s to the 1980s. New York: Routledge, 1986/1989.
Raymond, Eric. The Art of UNIX Programming. Reading, Mass.: Addison-Wesley. 2004.
Ritchie, D. M., and K. Thompson. “The UNIX Time-Sharing System.” Bell System Technical Journal 57, no. 6, part 2 (July–August 1978).
Ritchie, Dennis. “The Evolution of the Unix Time-Sharing System.” AT&T Bell Laboratories Technical Journal 63, no. 6, part 2 (October 1984): 1577–93. http://cm.bell-labs.com/cm/cs/who/dmr/hist.html.
Ross, Kristin. May ’68 and Its Afterlives. Chicago: University of Chicago Press, 2004.
Rowe, John Carlos. “Areas of Concern: Area Studies and the New American Studies.” In Transatlantic American Studies, edited by Winfried Fluck, Donald Pease, and John Carlos Rowe. Lebanon, N.H.: University Presses of New England, forthcoming.
Salus, Peter H. A Quarter-Century of Unix. Reading, Mass.: Addison-Wesley. 1994.
Sandoval, Chela. Methodology of the Oppressed. Minneapolis: University of Minnesota Press, 2000.
Spivak, Gayatri. In Other Worlds: Essays in Cultural Politics. New York: Routledge, 1987.
Streeter, Thomas. “The Romantic Self and the Politics of Internet Commercialization.” Cultural Studies 17, no. 5 (September 2003): 648–68.
Sugrue, Thomas J. The Origins of the Urban Crisis: Race and Inequality in Post-War Detroit. Princeton, N.J.: Princeton University Press, 1998.
Sullivan, Patricia. Days of Hope: Race and Democracy in the New Deal Era. Chapel Hill: University of North Carolina Press, 1996.
Thomas, William G. II. “Computing and the Historical Imagination.” In A Companion to Digital Humanities, edited by Susan Schreibman, Ray Siemens, and John Unsworth. Oxford: Blackwell, 2004. http://www.digitalhumanities.org/companion/.
Turkle, Sherry. Life on the Screen: Identity in the Age of the Internet. New York: Simon and Schuster, 1997.
Turner, Fred. From Counterculture to Cyberculture: Stewart Brand, the Whole Earth Network, and the Rise of Digital Utopianism. Chicago: University of Chicago Press, 2006.
Unsworth, John. “Living Inside the (Operating) System: Community in Virtual Reality.” In Computer Networking and Scholarly Communication in the 21st Century, edited by Teresa Harrison, and Timothy Stephen, 137–50. Albany, N.Y.: SUNY Press, 1996.