On the Origin of Eloi

[youzicha]

[posting this on Dreamwidth to try out the editor, and to experience the elegant Middle Cut from a more civilized age.]

A year ago nostalgebraist posted a review of Neal Stephenson's In the Beginning was the Command Line, and pointed out that its arguments about text, GUIs, Eloi, and Morlocks culture, etc, are all enjoyable but complete bullshit.

Last month I read The Second Self (by Sherry Turkle, Professor of the Social Studies of Science and Technology at MIT), and I was surprised to find that in the preface to the 2005 edition of the book, Turkle draws a distinction which feels very similar to Stephenson's Eloi/Morlock split. Let me quote extensively (the entire book is on libgen too, although obviously none of us would dream of reading it illegally):

For me, among so many changes to the landscape of twenty years ago, the shift in expectations about technological transparency stands out as particularly striking. Early personal computers, like their mini and mainframe cousins, used operating systems and programming languages that gave users a feeling of contact with the “bare machine.” I wrote The Second Self on an Apple II computer that had, quite literally, been torn bare. Its cover had been removed and its operating system replaced with another called CP/M. In order to communicate with my computer, for example, to ask it to summon the word processing program called Scribble, I had to give it specific symbolic commands that I understood as my means of addressing the machine “below.” And once I was dealing with Scribble, I was still in a world of commands, this time to format my text. For example, to indicate that I wanted a flush left heading, “Transparency and Opacity,” printed in bold face, I would type “@left[@b(Transparency and Opacity)].” Every command I issued was a line of text, a neat string of symbols—requirements that kept me in touch with the idea that I was directly addressing a machine, speaking to it in its language. I felt that I had to use symbols and a formal language of nested delimiters (parentheses and brackets) because my machine needed to reduce my commands to something that could be translated into electrical impulses. The fact that my Apple II’s printed circuits were physically exposed only reinforced this notion.

Although I did not build my own personal computer from a kit or learn to program in assembly language as did many of the early home computer enthusiasts I interviewed, my experience with CP/M and my naked Apple II provided a reference point for my understanding the aesthetic of technological transparency that I met in the early personal computer culture. Such transparency was described by one enthusiast as “the pleasure of understanding a complex system down to its simplest level.” This was a culture committed to developing a relationship with the computer as a rule-based, understandable machine. It was a culture in many ways reminiscent of that around early automobiles, a world in which most drivers understood the workings of the internal combustion engine, or at least how to fix it in a pinch.

There were, of course, competing aesthetics among the subcultures of computing in the early 1980s. While the personal computer hobbyists were committed to the view that “the machine only does what you tell it to, nothing more, nothing less,” many artificial intelligence researchers were committed to an aesthetic of emergence, where the machine would quite precisely do more than you could ever specify. For them, the beauty of the computer was that programmed agents within a computer system, operating with simple rules, could, through their interaction, create unexpected, “emergent” behavior. Another challenge to the aesthetic of rule-based transparency came from engineers and designers who believed that communication with computers should not rely on commands but on a more fluid and gestural language. To these designers, there was no need for a user to ever address a machine’s underlying mechanism. In their view, computer users should be liberated from having to think about the machine at all. In the late 1970s and early 1980s, during visits to Xerox PARC, a research laboratory in Palo Alto, I was first introduced to computers that offered the new gestural and “conversational” style. Instead of commanding my word processing program through typed commands, I was given a pointing device and shown how to gesture to a screen icon. At Xerox PARC, I met my first computer mouse and saw my first graphical user interface. Both of these technologies became part of the public face of computing during the year this book was first published, 1984, the year of the Macintosh.

The aesthetic of rule-based communication with a bare machine that I had met in the early days of personal computing would not survive the computer becoming a consumer object. However, through the 1980s, one could find its legacy, its style of command, in the DOS operating language for the IBM personal computer and again in the early Windows operating system, built on top of DOS, which enabled a user to “reach back” into DOS and recapture the feeling of directly addressing a machine. In contrast, the Macintosh, like the computers I had met at Xerox PARC, introduced a way of thinking that put a premium on the manipulation of a surface simulation. Macintosh users worked with a new understanding of the word transparency, indeed, one that turned common usage on its head. If one used the DOS operating system, things felt transparent when computer use felt analogous to working on a traditional mechanical device, like a car. Specific instructions to a computer enabled one to “open the hood” and “poke around” its inner workings. But when Macintosh users spoke about transparency, they were referring to an ability to make things work without going below a screen surface filled with attractive icons and interactive dialogue boxes. Indeed, these screen objects suggested that communicating with a computer could be less like commanding a machine and more like having a conversation with a person. In only a few years, the “Macintosh meaning” of the word transparency had become a new lingua franca. By the mid-1990s, when people said that something was transparent, they meant that they could immediately make it work, not that they knew how it worked. [...]

The Eloi use Macs and the Morlocks use DOS!

I have suggested, in talking about Deborah, that on the level of the individual child, something interesting has been lost in the move away from authorship of the programs that underlie one’s own game. On a societal level, there is an analogous loss. The aesthetic of transparency (common to the Logo movement and the early generations of personal computer hobbyists) carried with it a political aesthetic that was tied both to authorship and to knowing how things worked on a level of considerable detail. This is a kind of understanding that is not communicated by playing off-the-shelf simulations. [...]

In 1995, in Life on the Screen, I wrote about my encounter with Tim, a thirteen-year-old whose experience with SimLife stands in stark contrast with my encounter with Deborah of the thirty-degrees rule, only a decade before. Deborah worked in a simple system that she built by herself. Tim, who did not know how to program, worked in a complex system built by others. Tim played his simulation software as though it were a video game, moment to moment, with no understanding of the rules. Deborah was nurtured by transparency; Tim’s skill set was centered on the artful navigation of opacity. His philosophy of play: “Don’t let it bother you if you don’t understand. I just say to myself that I probably won’t be able to understand the whole game any time soon. So I just play it.”

"The artful navigation of opacity". And then, even Disney World makes an appearance!

In the late 1990s I took my daughter, then seven, on a vacation in Italy. We took a boat ride in the postcard-blue Mediterranean. She saw a creature in the water, pointed to it excitedly, and said: “Look Mommy, a jellyfish. It looks so realistic.” When I told this story to a research scientist at the Walt Disney Company, he responded to it by describing the reaction of visitors to Animal Kingdom, Disney’s newest theme park in Orlando, populated by “real”—that is, biological—animals. The first visitors to the park expressed disappointment that the animals were not “realistic” enough. They did not exhibit the lifelike behavior of the more active robotic animals at Disney World, only a few miles away. What is the gold standard here? A life in simulation has left my daughter’s generation suspended in play yet newly alive. Our displacement from the traditions of the physical by the shadow of the virtual has created a new kind of dépaysement, providing the opportunity for a clearer view of both registers.

Turkle does not cite ItBwtCL, but I think the similarities are very striking. If this really is an "independent discovery", it seems to indicate that Stephenson and Turkle are on to something—that these two clusters of Transparency/CLI/Algorithm/Books versus Opacity/GUI/Simulation/Disney correspond to some real thing in the world. Even if ItBwtCL is full of glaring factual errors and logical fallacies, the conclusion may still be true.

Turkle's theoretical explanation for the clusters is quite different from Stephenson's. One of the main claims of her book has to do with two different cultural conceptions of computers. One, which goes back to Lady Lovelace, thinks of computers as the paradigmatic example of a mechanical, deterministic, and predictable system which "only does what you tell it". She interviews microcomputer hobbyists in the early 80s, and this is exactly what attracts them to the hobby. The early micros are much to small to do anything very impressive or useful, so the pleasure of owning them is all about understanding how they work. As people pursue this hobby, it's largely about perfecting their understanding, e.g. taking an existing program in BASIC and rewriting it in assembly language. On the other hand, she also interviews hackers at the MIT AI Lab, who are the exact opposite: they want as high-level languages as possible, and they delight in small commands having elaborate and hard to predict effects. (Think of the introduction to SICP, which compares computer programming to conjuring spirits.) So which way you prefer can depend on your personality and what your appetite for risk/safety is, and the same computer interface can in principle support both styles. Turkle interviews Doris, who uses a word processing program running on something like MS-DOS:

[Doris] was doing her writing on a general-purpose computer, rather than the much more restricted special-purpose word-processing machines that are common in business settings. This meant that she also got to work with other programs. She needed to use a separate program in order to prepare the disks on which her text is kept, to make “back-up” copies of her work, to rename files, and to combine them to make her chapters into a book manuscript. Her involvement with these many programs gave her a sense of accomplishment at being able to find her way around not one constructed world, nor, indeed, a number of them, but within a system of logical worlds whose unity is symbolized by the “operating system,” the program that coordi- nates and gives access to the other programs in the system. At first, using the operating system felt to her like the symbol-pushing of her memories of school mathematics. But as time went on, its rules and hierarchy began to seem elegant, its patterns reassuring. Like Carl, Doris found pleasure in understanding a system in that especially complete way that does not ever happen in the “real” world.

Although Doris does not program, she is clearly on one side of the divide separating the style of the “prototypical hacker” from that of the “prototypical hobbyist.” She is interested not in magic, but in transparent understanding:

I have a friend whose son wants to be a computer wizard [the term used at her university for virtuoso programmers in the style of hackers]. For a while, I called on him whenever I had a problem. But I can’t stand the way he works with the computer. He won’t read the sections of the manual I show him. He sits down and starts typing. He never seems to know exactly what’s going on, but somehow by instinct he finds a way to solve the problem. I can’t stand it. I have stopped asking him for help.

But although both approaches are possible in principle, in practice most everyday things are too complicated to understand completely. Microcomputers in the 1980s (and the similarly-sized PDP-7 in the 1970s) are an exception: they are simple and discrete enough that you really can know exactly what is going one, and unlike modern computers there is negligable abstraction leakage (the LOGO source code, or the 6502 assembly, or the circuit diagram each give a "complete" description of the system). For a brief moment in time, ordinary households contained these interesting objects which really rewarded bottom-up understanding. People who were there remember it fondly:

The world isn’t like that anymore. At some point along the way the systems that were being built and the libraries and components that one had available to build systems were so large, that it was impossible for any one programmer to be aware of all of the individual pieces, never mind understand them.

I guess in this theory, we can still attribute the change to Microsoft Windows—not necessarily for popularizing the GUI over the command line, but for creating famously messy APIs, which do not come with source code, so that we all had to settle for experimental poking around. It can't be a coincidence that the Law of Leaky Abstractions was coined by a Microsoft alumnus.

Maybe, back in the days of the command-line interface, users were all "Morlocks who had to convert their thoughts into alphanumeric symbols and type them in, a grindingly tedious process that stripped away all ambiguity, laid bare all hidden assumptions, and cruelly punished laziness and imprecision." It's just that this is a historical coincidence, rather than an intrinsic property of command line interfaces.