By mid-1973 Kay's so-called "Learning Research Group" numbered
eight. They were so miscellaneous in their skills and credentials that
Bob Taylor took to calling them, not entirely facetiously, "the lunatic
fringe."
Ingalls brought along his friend Ted Kaehler, who had also come to
help George White with his speech recognition project but found Idea-
space more interesting. Diana Merry's route was even more random. A
transplanted Iowan with little programming training, she got a job as secretary to Gerald Lucovsky and John Urbach, managers in the General
Sciences Lab.
From the first, however, Merry was entranced by Taylor's work and the
other mysterious goings-on "down the hall among the computer folks"
where she spent most of her free hours, as she recalled later. Eventually
Taylor managed to get her transferred to a job as Jerry Elkind’s assistant.
One of the office machines there was an elaborate electric typewriter
that could do minimal text formatting through the application of a complicated sequence of keystrokes. No one ever utilized the beastly device's
capability except Merry, who was caught at it one day by Alan Kay.
"You're a programmer!" he exclaimed.
"No kidding," she said.
Impressed by the natural skills of this secretary smuggled over from the
physics lab, Kay gave her a few hours of rudimentary training. After that
it was a relatively simple matter to get her assigned to his group.
Then there was Adele Goldberg, an educational technology specialist
from the universities of Michigan and Chicago with fiery red hair and a
turbocharged thought process ("Adele we described as speaking at nine-
tenths of a Lampson," Merry recalled). Kay filled out the team with,
among others, people like Tesler, whom he shared on a roughly fifty-fifty
basis with Bill English until after Gypsy was finished, when he joined
LRG full-time; Chris Jeffers, the childhood friend and "chief of staff";
and interns and summer students who strayed into his orbit with that telltale shimmer in their eyes.
Kay reveled in his people's eclectic backgrounds, which did not always
include work toward a doctorate. "A doctoral thesis is anything you can
get three faculty members to sign," he would say in their defense (quoting Ivan Sutherland, who had been a signer of his). Or: "Point of view is
worth eighty IQ points." He did not care if his recruits had doctorates—
although he certainly employed a high percentage of academically gifted
scientists and engineers
—
but he monitored their points of view meticulously.
Like Taylor, he believed strongly that a lab's success depended on a
shared vision. But he was determined to avoid Taylors tendency toward
militaristic discipline. The Learning Research Groups dogma sprung
from Alan Kay’s mind as surely as CSL's did from Taylors or Lampson's,
but the lab's ambiance was less like an Army barracks than a bohemian
party where the guests all happened to concur in their host's choice of
wine.
No corner of PARC generated anything like the Kay group's freewheeling mania. "It was an amazingly seductive environment," recalled
Merry. "I was there late at night all the time. People were so full of ideas
and excitement, and of course everybody knew more than anybody else
about how the world was supposed to be."
Socially the Learning Research Group was also PARC's most cohesive
unit. "There was just a wonderful, personal feel to the group that spoke
really of caring about one another and supporting one another," Merry
said. Kay strived to build collegiality by sponsoring annual team "offsites"
at a favorite retreat, the seaside resort of Pajaro Dunes located south of
Santa Cruz, a couple of hours by car from Palo Alto. Here they could
spend three or four days together on unstructured tours of Ideaspace, the
pressures of work carefully relegated to the background. Later in time
and inspired by Kay and Jeffers, the more musically inclined group members took to engaging in ragged lunchtime jam sessions ("We played
poorly but with great zest," recalled Goldberg, the house clarinetist)—
including Ingalls on flute and Merry trying to keep up on a trumpet she
had rarely touched since high school. "There used to be an old joke that
we really didn't care whether a new recruit could do any computer science, what we really needed was a bass fiddle," she said.
Even back home, Kay recalled, the group spent much of the daytime
"outside of PARC, playing tennis, bike-riding, drinking beer, eating
Chinese food, and constantly talking about the Dynabook and its
potential to amplify human reach and bring new ways of thinking to a
faltering civilization that desperately needed it (that land of goal was
common in California
in
the aftermath of the Sixties)."
Loose as the groups structure was, everyone understood where the
intellectual power lay. It was
in
the combination of Alan Kay and Dan
Ingalls. They were yet another PARC partnership, like Metcalfe/Boggs
and Lampson/Deutsch, that was unlikely, implausible, and uncannily
powerful. Ingalls filled a role in Kay’s professional life no one else had
seemed willing or able to undertake. He was Alan s reality filter. It was no
secret that Kay’s ideas tended to embrace about 200 percent of what was
technically practical. But there were few people around willing to sift
through the whole sandbox to identify the pragmatic parts. As Lampson
recalled, "Alan would come around and say, I want to do x and
y.
You
would ask him four questions about how this is actually going to work and
you'd discover that it isn't actually going to work. So at CSL we'd say, 'No,
we don't want to build that.'"
But Ingalls was an instinctive master at picking out the subset of
Ideaspace that was actually doable, and doing it. Even before the first
Altos were designed and built, Ingalls had started working on one such
subset. By the time the machines were finished, his efforts had yielded
the masterpiece of computer science called Smalltalk.
Smalltalk would make Kay's reputation more than Ingalls s, but Kay
never forgot who transformed it from idea to reality.
"Nobody would ever have heard of me," he said later, "if it wasn't for
Dan Ingalls."
Kay always claimed to get his best ideas in the shower. Conveniently,
Building 34 had a shower in the basement. More expediently, it was
never in use during his most productive time of the day—from four in
the morning, when he typically came to work, until about eight, when
the rest of his team would start drifting in.
Emerging from the basement one morning, he came upon Kaehler
and Ingalls in a hallway bull session about "how large a programming language would have to be to have great power," as he recalled the scene. In
a flash Kay posed a dare almost as audacious as the one Thacker had
accepted from Bill Vitek.
"With as much panache as I could muster, I asserted that you could
define the most powerful language in the world in a page of code. They
said, 'Put up or shut up.'"
Kays challenge was grounded in his convictions about what a programming language should accomplish. Languages are much more than mere
programs: They are blueprints for the thought process itself, software for
the computer
and
its programmer. Almost from the moment he had
encountered his first computer, Kay understood that the hallmark of a
great system must be its simplicity. Only then can one be certain it has
been fully distilled down to its essentials.
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.