Dealers of Lightning

Home > Other > Dealers of Lightning > Page 25
Dealers of Lightning Page 25

by Michael Hiltzik


  What made Tesler feel like a stranger was a rather fundamental dis­agreement he had with his colleagues: He thought POLOS was ridiculous.

  Larry Tesler had never worked for Doug Engelbart. Not having par­taken of the master's heady wine, he was troubled by POLOS's com­plexity. As imported from Engelbart's lab, the system required users to learn a dizzying array of commands and key sequences involving the mouse, keyboard, and—especially frustrating—a bizarre device known as the "keyset." This was a pad with five unlabeled levers, resembling the steno machines one saw in courtrooms. Pressing the keys in various combinations could give you any letter of the alphabet and a wide range of specialized commands—impressive enough as an engineering achievement. But Tesler could not imagine why anyone would want to use such an esoteric gadget.

  Two other features of POLOS also offended him. The first was its time­sharing heritage. POLOS was based on the ancient principle that com­puters were so expensive they had to be shared. The system was designed as essentially a pool of Nova minicomputers linked by cable to video ter­minals in every office. A user logging in at any screen would automatically be assigned an idle Nova out of the pool, which would serve as his or her "personal" computer until the required task—typing a letter, parsing fields in a database, or performing an engineering study—was done. But no one would "own" an individual machine, nor would there be any guar­antee that in periods of high demand one would not have to wait for a Nova to get free.

  Tesler hated the very idea of sharing computing cycles, an emotion that dated from an incident that happened when he was a fifteen- year-old senior at New York City's elite Bronx High School of Science. In short, he had gotten banished from a university computer center for throwing the wrong switch.

  The year was 1960. Tesler had acquired permission, somewhat illic­itly, to use an IBM 650 at Columbia University during unbooked slots on weekends. The 650 was about the size of three tall armoires stand­ing back to back. Among its more curious features was its memory apparatus, a magnetic drum driven by an endless rotating belt like the fan belt of a car. The computer's operators were indoctrinated with the stringent rule that if power to the system ever failed they were to wait a minimum of fifteen minutes before turning it back on, to make sure the drum could first come to a complete stop.

  Left alone in the center one day, Tesler hit the wrong switch and inadvertently turned off the machine. "Instinctively I flipped it back on again—and the moment I did I went, 'Oh, shit!'"

  The belt instantly snapped with a report like a pistol shot. The har­vest was a maintenance call to IBM, considerable expense to the com­puter center, and for Tesler a summons to the director's office.

  "He told me I could never use their computer again," Tesler recalled. "That day I resolved that someday I was going to have my own computer, because I didn't want anybody to ever do that to me again. And from then on many of my decisions about my life were weighed against the ques­tion: 'Does this help me get my own computer?'"

  Tesler’s second objection to POLOS was the hopeless inscrutability of its user interface. This violated another personal credo, that the pro­grammer’s primary duty was to render the computer intelligible to the layman. By the time he reached PARC he had already written several programs aimed at turning computers into handy tools for average users, including one to print and format simple documents which he called "Pub" and sold commercially by mail-order.

  Tesler had assumed that at PARC, the world capital of the interactive imagination, he would find everyone working toward this same goal. Instead he had been thrown among the POLOS team, which seemed bent on making things even harder for the user. He could not resist mocking the system and its silly theology. Every chance he could, he tried to show his smitten colleagues that Engelbart’s dazzling system was so complicated that it created more work for the user rather than less, like a telescope viewed through the wrong end.

  "They had to justify the fact that it took people weeks to memorize the keyset and months to become proficient," he recalled. "So they came up with this whole mystique about augmenting intellect' and how in order to become literate with a computer people would need six months of training. Basically, I showed that this stuff that took six months really only had to take a week, with the right system."

  Rather than heed his words, they shunned him like a parson at the orgy. "They were fed up with me and decided I was more of a pain than any­thing else," Tesler recalled. "I was the naysayer. I was bringing down the morale."

  Finally Bill English summoned him to his office. "Larry," he said, "we've found you a new assignment."

  While Tesler had been crabbing about POLOS from the inside, the system had been getting the once-over from a perceptive visitor from the outside. Timothy Mott had been dispatched to PARC as an emis­sary by the head of Ginn & Co., a Xerox subsidiary that published text­books out of an office in Boston.

  For a sixty-year-old publisher, this man, the provocatively named Dar­win M. Newton, was an uncommonly enterprising individual. Sometime earlier he had discovered that Xerox was charging Ginn a portion of its annual revenues to cover "corporate research." As far as he could tell, this tax had never purchased Ginn a dime’s worth of knowledge or technol­ogy, a deficit he resolved to correct. His inquiries led him to PARC, where he had received a short demo of the latest work on office sys­tems—that is, POLOS. Newton returned home thinking that something like POLOS might help relieve the tedium of editing manuscripts and laying out pages, and in the process help Ginn turn out better books.

  But the question of how to actually determine if his suspicions were right had him stymied. He knew everything about editing but nothing about computers. Then one day Tim Mott showed up for a job interview.

  Mott was a displaced Briton with a computer science degree from Manchester University. This was a place with a much older claim to com­puting distinction than Palo Altos, for it was at Manchester that the world's first electronic stored-program computer, based on the concepts of Alan Turing, had been built in 1948. After completing his studies Mott had relocated from Manchester to Oberlin College in Ohio, where he had spent a couple of years teaching math and helping the school set up its computer department. He then moved to Boston to enroll in business school. What brought him to Newton's office was a tip that Ginn had a part-time opening that might tide him over until the school year started.

  Once Newton learned that the man seated before him was a certified computer scientist, he jumped at the chance to explore how to apply the intriguing system he had seen in a real world production fine. The part-time job suddenly disappeared. Instead, Mott found himself shipped out to Palo Alto with instructions to bring back POLOS as an editing system.

  As a Briton, a stranger, and an ambassador from the far reaches of Xerox land, Mott spent his first few days on the West Coast with his head spinning.

  "I had heard of PARC, though probably only through the stuff Stewart Brand had written. I didn't think of myself as being in the mainstream of computer science research," he recalled. What he found at PARC "from the standpoint of personal computing as opposed to either batch process­ing or time-sharing was really fascinating. And I got the joke about the price of the technology and where it was going and the fact that what was being worked on there was really going to be commercially viable, in time."

  But he also saw where the research train was going off the rails. On the POLOS team, he found, "there wasn't a lot of time spent looking at what mere mortals would be able to do with the system." Instead they had pro­duced a system bewilderingly technical and counterintuitive. English and his software chief, Bill Duvall, had faithfully reproduced Engelbart's system of "structured text" in which every line and paragraph of a file incorporated reference pointers to other pertinent text, allowing users to follow a sort of subterranean intellectual path through a document. Mott regarded it as a fascinating model for analyzing computer programs or navigating through information space. "But it wasn't a particularl
y good model for editing manuscripts, let alone doing page layout of text and graphics." Like Tesler, he shuddered at the thought of training a typical Ginn editor or secretary, or any ordinary user, to utilize POLOS's baroque routines.

  POLOS's inadequacies in the real world posed a real dilemma for Mott. Since his charge was to study and adapt POLOS for Ginn, after six weeks in Palo Alto he had essentially studied himself out of a job. "My report back to Ginn was basically a letter of resignation, saying this isn't technology you can use," he recalled.

  Fortunately, before sending it he happened to spend a few moments in Bob Taylor's office, outlining his misgivings.

  Taylor puffed at his pipe. "You're not going to just go away, are you?" he asked.

  "What choice do I have? This isn't a system suitable for a publishing application."

  "So stick around and help us figure out what will work for Ginn. That's why we're here."

  Taylor's proposal to Mott was not an entirely disinterested one. At that moment POLOS and the Alto were moving along parallel paths toward the same goal—delivering computing cycles interactively to users. Taylor fig­ured the two programs were almost certain to end up vying for money and staff in a zero-sum game. He was not alone: Even observers with little stake in the success of either system realized that when the smoke cleared only one would be left standing. No one could be surprised that Taylor would do anything to ensure the Alto was the one that would prevail.

  By 1974, when his conversation with Mott took place, this rivalry was already creating tension between the Computer Science and Systems Science labs. Lampson and his colleagues were convinced the POLOS architecture was obsolete. It was true that scrapping the traditional heavy-duty mainframe in favor of the Nova pool relieved the system of the memory management and job scheduling that made time-sharing so burdensome and complex. But since one or two Novas had to be reserved for specialized tasks such as scheduling print jobs and coordi­nated with the users of the pooled machines, the complexity got added right back in.

  "It was actually worse than trying to do it on a classical time-sharing system," Lampson explained later. "You had to keep all these balls in the air to keep everything working, which we're not that good at today. And we certainly weren't very good at it then."

  The CSL staff campaigned to undermine POLOS. If Taylor's recruits from Berkeley Computer felt at all abashed about torpedoing the prize project of his recruits from Engelbart's lab, they did not show it; this was a question of engineering, in which personal feelings were not a factor. In any case, English and his people now belonged to a different lab. In staff meetings and hallway bull sessions the Computer Science Lab never let slip a chance to make its views known, as though following the habit Bob Taylor had learned in his early itinerant years among the dusty little towns of rural Texas. They were making sure the Alto's superior position in the hierarchy was established and rendered unassailable.

  "We were saying our way is the right way," Lampson recalled. "We openly articulated our feelings. We really thought they were doing the wrong thing and any resources poured into it were going to be wasted, as indeed they were."

  The POLOS defenders were equally spirited, arguing that CSL's plan to distribute $20,000 machines to everyone in the building would be a ludicrous waste of resources, like giving every secretary her own printing press when all she needed was a typewriter. Not to mention that such a system would present a massive maintenance headache, especially compared to one where the most complicated machines were kept conveniently in one spot and the only distributed elements were essentially cheap, low-maintenance TV sets.

  What may not have been clear at the moment was that POLOS was already in trouble—and for exactly the reasons Lampson cited. The system was too complicated and inherently inefficient to survive. The POLOS team's inability to get the elaborate network operating consis­tently eventually became too obvious for even its staunchest advocates to ignore.

  "We didn't know how to deal with a system so complicated," acknowl­edged Smokey Wallace, another ex-Engelbart engineer working on the project. In contrast to a modular system like Alto-Ethernet, where the whole system would keep functioning regardless of any one component's failure, POLOS was so organically integrated that the crash of any one part would knock the entire assemblage out of commission, sometimes inexplicably. "It would run for three months straight and then fall apart for half a day," Wallace recalled, "and we wouldn't know why."

  Still, for more than a year after the Cookie Monster first munched its way across Chuck Thacker's display screen, it was impossible to say which system would eventually prevail. POLOS still had a lot to offer, including the spectacular multimedia capabilities of Doug Engelbart's NLS, re-implemented and in many respects improved upon. Mean­while, the Alto was still looking for a rationale.

  Taylor jumped at the chance to put Tim Mott to work. He knew Mott needed an alternative to POLOS. Clearly the answer would have to be the Alto. When he asked over at the Systems Science Lab if they had any­one with expertise in publication systems to work with Mott, Bill English suddenly recalled that Larry Tesler had done that "Pub" thing. Without hesitating, he called Tesler in to tell him about his new job.

  "What is it?" Tesler asked.

  "You're going to do a publication system for Ginn," English said.

  By the time Mott and Tesler started working together, several proto­type word processing programs had already been written at PARC.

  Almost none of them functioned very well on the Alto, however—they were too slow, or too elementary, or too complicated. The exception was Bravo, which was fast, rich in features, and well-tuned to the Alto's capabilities.

  Mott and Tesler, however, were among those who believed that Bravo, for all its marvelous endowments, harbored some major flaws. As with POLOS, most of these had to do with the user interface—the keystrokes, commands, and visual cues through which user and pro­gram communicated with each other.

  For one thing, Bravo's interface was heavily moded, meaning that the result of typing a key would differ depending on whether the program was in "command" or "text" mode. The operator always had to keep in mind which of these states the system was in, lest disaster ensue. In "text" mode, for instance, the system functioned like a typewriter: Pressing the "D" key gave you the letter D. In "command" mode, however, the keys produced not text characters but commands—pressing a D, for example, instructed the program to delete a selected block of text.

  Modes were such notorious pitfalls in interface design that they had spawned a standard cautionary joke. This involved a user who inatten­tively typed the word "edit" while in command rather than text mode: Typing "e" selected the entire document, "d" deleted the selection, and "i" instructed the machine to insert in its stead the next character to be typed ... at which point the user discovered that his entire document had been inalterably replaced by the letter "t."

  For the sake of the layman, Tesler and Mott believed, modes had to be exterminated. They thought Bravo's interface represented a vast improvement over POLOS's thicket of perverse and counterintuitive commands, but that it had not gone far enough. Its modes were simpli­fied, but they were still modes, making it "still a very dangerous editor to use," as Tesler recalled.

  Moreover, like all CSL programs, Bravo was exceedingly ugly in appearance. For all CSL's delight at its WYSIWYG capabilities, the pro­gram made scant use of the bitmapped screen's graphical power. Even the variable fonts were still displayed as bare text on a blank screen. This reflected a deliberate choice by the CSL designers, who avoided elabo­rate graphics because they slowed down the system. But because tire Systems Science Lab engineers were mostly interested in making the computer intelligible to the average user, they loaded up their programs with graphical gewgaws of all kinds, figuring that within a generation or two the machine s speed would eventually catch up.

  Tesler and Mott therefore set out to create a modeless graphical interface to make Bravo simple to use. Inspired by the co
stume Mott's stepdaughter was wearing for Halloween that year, 1974, they called their new program "Gypsy."

  Their first step was to do something PARC had never tried before: They analyzed how non-engineers would actually use a computer.

  This survey was conducted back at Ginn, to which Mott returned with an Alto display, keyboard, and mouse. He installed them as a sort of dummy setup (the machine was nonfunctional) and invited editors to seat themselves in front of the equipment, imagine they were edit­ing on-line, and describe what they expected it to do.

  "They were a little skeptical," he recalled. "But—surprise, surprise— what you got was them wanting the machine to mimic what they would do on paper." They even described the processes in terms of the tools they had always used. That is why to this day every conventional word processors commands for deleting a block of text and placing it else­where in a file are called "cut" and "paste"—because Ginns editors, the first non-engineers ever to use such a system, were thinking about tire scissors and paste pots they used to rearrange manuscripts on paper.

 

‹ Prev