For him, writing a program tight enough to fit on a page had two chief virtues. It forced him to pare it to the bone, and it suited his sense of mental geography. By allowing the structure of the language to be absorbed in a single eyeful, he could show how all its individual components were interrelated pieces of the whole.
Over the previous few years this striving for simplicity had led him to re-examine all the ideas about programming and computer architectures he had absorbed during his ad hoc studies in the Air Force and at Utah. The challenge from Kaehler and Ingalls provoked him to sit down and arrange his thoughts on paper.
Traditional programming languages make a distinction between data and the procedures acting on them: The programmer defines a set of data variables as, say, the integers 3 and 4, then operates on them with the procedure "+" to produce the result "7."
Simple enough on its face. What dissatisfied Kay about this sort of structure was that as the data got more complex and the operations proliferated, the program's complexity quickly got out of hand—even if the desired answer was still the single integer 7.
Using a traditional language to send Seymour Papert's display turtle along a random path would require a programmer to summon all his or her knowledge of the convoluted routes by which data wend their way through the computer, get crunched, translated, and rearranged, and lay them out on paper—just to get a simple picture on a screen!
These systems also ran into trouble when the variables defined something other than numbers—the names "John" and "Mary," say. If one sent "+" to operate on them, the computer would almost certainly crash out of pure confusion. (How does one "add" words?) You would actually need to define John and Mary as some form of number that told the system how to "+" one to the other so the desired answer would result— "John, Mary," perhaps.
Kays goal was to create a language that enabled the programmer to arrive at a simple result by a simple path, regardless of the complex operations taking place beneath the surface. He called this "hiding the details." After all, one does not need to know how a television works to be able to switch it on and find one s favorite show—why should it be necessary to know all the details of data and procedure to map a simple image to a computer screen?
His solution was to invent an entirely new syntax of computer programming based not on data and procedures, but discrete modules of programming code called "objects." Objects can be thought of as black boxes, like the television set. They combine data and the procedures that will work on them, and are manipulated by sending them "messages." Just as clicking the "on" button of a remote control sends the TV a "message" to turn itself on, in Kay’s system one sends the object "3" the message "+ 4." The object knows to interpret that as a simple addition, and returns 7.
This may seem complex at first. But in contrast to traditional languages, object-oriented programming becomes relatively simpler as the data and operations become more complex. The reason is that the underlying calculations always remain hidden within the object, never needing to be explicitly invoked by the programmer. The object "John," for example, needs only to be sent the message "+ Mary" to know that"+" in this context can mean only one thing: to append "Mary" to itself after a comma.
Although Kay drew the principles of what became known as "object- oriented programming" from several well-known languages and computer systems, his system left many traditionally trained programmers befuddled from the start. It was as if one tried to invent a new literary language using conventional English words but devising radically new rules of meaning. The individual words would look familiar, but the way in which they related to each other in a sentence would seem impenetrable—until the reader decoded the new rules, that is.
The CSL programmer Warren Teitelman, a world master of the language Lisp—a key source of Kays ideas—was one who found Smalltalk perplexing at first. "People were used to thinking about programs in terms of instructions and imperatives. If you thought in those terms you had a lot of difficulty with Smalltalk. When you looked at it, your first reaction was, OK, I sort of understand it, but where does the work get done?"
Having been challenged by his teammates to define a language on a page, Kay emerged after eight days of 4 a.m. to 8 a.m. struggle with a blueprint in hand for this new language with an unassuming name. Smalltalk was compact enough to define itself in a page of code (although as it grew more comprehensive, the pages got bigger and Kay’s handwriting more minute). It was slow, because it placed an unusual workload on the computer. But it was astonishingly flexible.
Because anything could be an "object," whether numeral, word, fist, or picture, Smalltalk lent itself especially well to representing graphic images on a computer display. That became evident even in the days before the Alto was ready. The Learning Research Group tested their embryonic system on Novas equipped with their big, lumbering character generators and turned out new typefaces and half-tone bitmaps by the score. Once the Alto came along, this process picked up speed as Kay’s group enhanced Smalltalk with graphical capabilities that exceeded anything else being developed at PARC.
In fact, Kay was so impatient to get his hands on the Alto that he did not even wait for the first fully engineered models with printed circuit boards to come off the production line set up in El Segundo, like the rest of the labs. Instead he requisitioned six machines to be built with the same clumsy and unreliable wire-wrapped circuitry used in the original two prototypes, which he proceeded to install in the basement of Building 34.
The idea was that he could get them cheaper and faster, even if they turned out to be flaky in operation and hard to maintain. He also ordered these first Altos with the low-end option of only 96,000 bytes of memory, rather than the maximum 128,000 bytes. The first machines also came with a 2.5-million byte, or 2.5-megabyte, storage disk. (By comparison, todays household and office PCs often come with at least 32 or 64 million bytes of memory and four to eight billion byte storage disks.)
Under this miserly configuration Smalltalk ran painfully slowly, in part because the full-screen display alone consumed 64,000 bytes, leaving almost nothing for the program kernel. By the time Kay recognized that he had engaged in a false economy and tried to scrounge a few high- performance models out of turn, the machines were such a sought-after sensation that no one would let him cut in. "Forget it, Alan," admonished an amused Ed McCreight. "You're the one who screwed up."
But once Kay finally got all his machines retrofitted with adequate memory, Smalltalk fulfilled all its developers' expectations. While the CSL engineers busied themselves with programs to format the same dull text-heavy documents as fast as they could make the Altos run, the lunatic fringe worked the machines' graphical capabilities to the bone. A typical Learning Research Group program was no blob of black-on- white text but a carnival of drawings, half-tone photographs, even animated pictures. "Objects mean multimedia documents," Kay would say. "You almost get them for free."
As a result, the group's programs tended to favor the artist over the scientist. An LRG engineer named Bob Shur had programmed, with Thacker's help, a musical synthesizer capability into the Alto that allowed the machine to output twelve real-time voices at once, an astonishing capability for a machine of the Altos scale. Then, in the fall of 1975, Ted Kaehler, although no musician himself, developed a program called "Twang." This was a visual interface to a number of music synthesizer programs that could capture, compose, edit, and replay music on the Alto. Twang used a non-traditional notation, black bars of differing lengths and locations to indicate differing tonic and rhythmic values, that deliberately resembled the perforations on a player piano roll. Twang was unusual in that it worked virtually in real time. All previous computer music programs, including the pioneering "FM" developed by John Chowning at Stanford, had to be compiled, meaning that several hours of programming and debugging were necessary to produce a five-minute riff. That was unnecessary with Twang, with which one could compose and program a pol
yphonic passage with as many as eight voices almost as fast as one could hit the keys on an attached piano keyboard.
While Merry, Ingalls, Kaehler, Tesler, and others engaged in the grown-up activity of implementing serious Smalltalk tools on the Alto, Kay decided to make good on his original claim that Smalltalk would be a language simple enough for children to use. In the summer of 1973 he and Adele Goldberg assembled a group of eager preadolescents and started teaching them how to program. The effort would shortly lead to another of Kays painful run-ins with PARC management.
These were not average youngsters. Goldberg started with an advanced class of seventh-graders at Palo Altos Jordan Road Middle School, which served an upper-middle-class neighborhood a mile or so from the Stanford campus. Once or twice a week the kids came up the hill by bus or bicycle to Building 34, to be escorted to a roomful of Kay's original wire-wrapped Altos down in the basement.
Goldberg loaded these with an inspired Smalltalk program she called "A Box Named Joe." Joe, an outlined square, was a direct descendant of Seymour Papert's LOGO turtle. With a series of one-fine commands the seventh-graders could make it appear on the screen, turn on its side, grow larger or smaller, or disappear. By arraying the commands in a sequence, they achieved rudimentary animation.
The encounter was mutually enlightening. Although these youngsters had for the most part grown up in privileged and brainy homes, they were surprised to come across grownups so guilelessly interested in their burgeoning intellects.
"When you're a kid, adults either don't want you around, or when you ask a question they give you a lecture," recalled Marian Goldeen, then twelve, the daughter of a Palo Alto piano teacher and a businessman.
"But they weren't like that. Adele was pregnant, but she looked a lot younger than someone I thought would be working with computers."
The scientists, some with young families of their own but few with teenagers around the house, found it eye-opening to deal with twelve- and thirteen-year-olds who grasped the basics of programming instinctively. One weekend Goldeen, who was an honor student in mathematics but had never programmed a computer, went home armed with a few pointers from Goldberg and coolly returned with a full-blown paint program, complete with a menu of varied shapes from which the user could select a custom "brush." Two older students contrived programs that wrote out musical scores or drew circuit diagrams, junior versions of Twang and SIL.
A few semesters later Kay attempted with characteristic audacity to broaden his experiment. The program coordinator at Jordan Road Middle School had arranged to make a room available to the PARC researchers, and Kay decided to furnish it with a working Alto. Unhappily, spiriting an Alto off the PARC premises was an outrageous violation of Xerox rules. Kay dealt with the implications by the simple stratagem of keeping management uninformed. Late one night he and Adele Goldberg drove up to the loading dock of Building 34 in her station wagon, the only vehicle anyone owned large enough to carry the cargo.
"Isn't this illegal?" she asked nervously. Stop worrying, Kay replied. He would take the heat.
Of course, it was impossible to keep the Alto's presence at a Palo Alto public school secret. Inevitably, news of the escapade reached a furious George Pake.
Painfully aware of Kay's value to the research center, Pake had always treated him tolerantly, if condescendingly. "Alan's irrepressible," he would say. "You can't keep him under control." Even Xerox's post- "Spacewar" strictures on unauthorized press statements had not stopped Kay from granting a steady stream of illicit demonstrations and brazen interviews, of which some of the latter provoked outrage back in Stamford. The California magazine New West once quoted him as saying that Xerox "doesn't understand" computers and its executives "really don't have any idea what I'm doing here," forcing Jack Goldman to reassure his fellow Xerox executives in writing that "Dr. Alan Kay is a recognized outstanding scientist in his field, albeit somewhat native and unorthodox in his dealings with the press." ("The article is a piece of undistinguished journalism and the audior apparently enjoys sniping at large establishments," he added.) Kay complained his quotes were fabricated.
Pake had once hoped that appointing Harold Hall as SSL chief might help rein in Kay; after all, Hall had raised five kids, four of them boys. "I thought, he's a father figure and he can help to bring Alan up," Pake said later. But Hall's discipline did not take. It was shortly after he was succeeded as SSL director in 1975 by the somewhat more accommodating Bert Sutherland that the Jordan scandal erupted, with Kay once again involved in a first-class transgression.
Goldman happened to be on the scene to deliver the obligatory dressing-down. As Pake looked on, he berated Kay and Jeffers for violating Xerox security and exposing a proprietary program to the world.
"The shit really hit the fan," Kay remembered. "Goldman tore a strip off me and Chris." But once Goldman had contented himself with playing the bad cop, he let the experiment go on. As Kay recalled later, he turned to Pake and curtly commanded, "Let them do it!""
Through 1973 and 1974 the Alto's remarkable power and potential made LRG's creative environment "a computer hacker's dream come true," as Ingalls recalled. "We'd go out for lunch and beer and say, 'Wouldn't it be great if you could do this or that?' Then we'd come back to PARC and in an hour or two do the thing we'd said would be so neat. And then we'd give a demo and show it off to our compadres in the CSL."
The partnership was a complementary one, largely because Kay's lunatic fringe always approached the Alto's capabilities along completely different lines from the Computer Science Lab. For CSL the issue was
"Neither Goldman nor Pake recalls Goldman's concluding remark as Kay tells the story. But the Altos were permitted to remain at Jordan, on the condition that they were first carted back to PARC to be formally "checked out." how rapidly they could move data through the machine, whether it was Bravo text or Thacker s design schematics. For LRG it was how to display the same data in the most mind-blowing, dynamic way.
"Our mission was to really make this hardware do what it was supposed to do," recalled Kaehler. "Make it suitable for kids, flashy and wonderful, really responsive. And CSL was more concerned with hard-core computer science issues. They wound up not making that many innovations in the interface. We knew we couldn't design hardware like them, but we could make the interface much more interactive."
They worked like orchestra members composing and rehearsing a symphony at the same time. The day might start with Kay bursting in on Merry and Kaehler, interrupting their hard work on some module of code. He would scrawl some new idea across the lab's ubiquitous whiteboards until they were covered with boxes filled with other boxes and arrows pointing to yet more boxes with pointers across to new boxes and so on. Kay was determined above all to squeeze every ounce of functionality out of the Alto bitmap. The display screen, he proclaimed, was small only in terms of its physical dimension. In terms of its graphic flexibility, it was colossal. From that standpoint, why should the user be prevented from, say, drawing a picture on the screen using a mouse and a paint program while simultaneously drafting a memo describing the procedure?
The answer, unfortunately, was that the Alto's 8½-by-ll-inch screen encompassed just so much physical real estate—the space of a single sheet of writing paper. That limitation, as it happened, led directly to one of their most important contributions to the look of the computer screen—the concept of overlapping windows.
The idea began by thinking of the screen in terms of a physical desktop. People in offices got around the same problem of too much paper and not enough room, Kay reasoned, by piling pages on top of one another. The analogous procedure would be to pile up small images on the screen—perhaps in some way that allowed the user to keep track of how many sheets, or projects, or windows, were open at once and to summon the most important one instantly to the top of the pile.
As usual, Kay was formulating a concept in Ideaspace and asking his team to implement it in reality. Although
they knew how to tile the screen with multiple boxes, even overlapping ones, moving these boxes around or shifting one or another to the top placed enormous demand on the processor. The Alto complained in the only way it knew how, by performing the procedure at a glacial crawl.
For several weeks Kaehler worked principally on the overlapping- windows puzzle. The team had a system for showing when one of them had hit the wall on a coding problem and needed to hand it off. This was the "hot potato": One of them would walk into another's office with the figurative object held gingerly in cupped hands, then drop it into the next one's lap. Kaehler, having hit the wall on overlapping windows, dropped the hot potato into Ingalls's lap one day in the fall of 1974, and he solved it.
The solution came in the form of a brilliant feat of coding Ingalls called "BitBlt," an abbreviation of the term "bit boundary block transfer" that was pronounced "bitblit." BitBlt was a way to shift whole rectangles, or blocks, of the bitmap from one location to another in a single operation. It enabled the system to bypass the tedium of delving into memory, locating all the components of the rectangular image, and changing them one by one; and thus cut out most of the computation that had made full-bitmap procedures so slow. Suddenly graphical changes on the display were faster, more direct, and in computing terms vastly cheaper.
Dealers of Lightning Page 27