TITLE: Alan Kay's Talks at OOPSLA AUTHOR: Eugene Wallingford DATE: November 06, 2004 9:03 PM DESC: Kay reminds us of the beauty of computing -- and the responsibility we share for bringing this new medium for thought to the world. ----- BODY: Alan Kay gave two talks at OOPSLA last week, the keynote address at the Educators Symposium and, of course, his Turing Award lecture. The former was longer and included most of the material from the Turing lecture, especially when you consider his generous question-and-answer session afterwards, so I'll just comment on the talks as a single presentation. That works because they argued for a common thesis: introductions to computing should use simple yet powerful computational ideas that empower the learner explore the larger world of ideas. Kay opened by decrying the premature academization of computing. He pointed out that Alan Perlis coined the term "computer science" as a goal to pursue, not as a label for existing practice, and that the term "software engineering" came with a similar motivation. But CS quickly ossified into a discipline with practices and standards that limit intellectual and technical discovery. Computing as science is still an infant. Mathematicians work in a well-defined space, creating small proofs about infinite things. Computing doesn't work that way: our proofs are programs, and they are large, sometimes exceedingly so. Kay gave a delightful quote from Donald Knuth, circa 1977:
Beware of bugs in the above code; I have only proved it correct, not tried it.
The proof of our programs lies in what they do. As engineering, computing is similarly young. Kay contrasted the construction of the Great Pyramid by 200,000 workers over 20 years with the construction of the Empire State Building by fewer than 3,000 people in less than 11 months. He asserts that we are somewhere in the early Middle Ages on that metaphorical timeline. What should we be doing to advance? Well, consider that the builders of the Pyramid used hand tools and relatively weak ideas about building, whereas the engineers who made the Empire State Building used power tools and even more powerful ideas. So we should be creating better tools and ideas. (He then made a thinly veiled reference to VisualStudio.NET 2005, announced at OOPSLA, as just another set of hand tools.) So, as a science and professional discipline in its youth, what should computing be to people who learn it? The worst thing we can do is to teach computer science as if it already exists. We can afford to be humble. Teach students that much remains to be done, that they have to help us invent CS, that we expect them to do it! Kay reminded us that what students learn first will have a huge effect on what they think, on how they think about computing. He likened the effect to that of duck imprinting, the process in which ducklings latch onto whatever object interacts with them in the first two days of their lives -- even if the object is a human. Teaching university students as we do today, we imprint in them that computing is about arcane syntax, data types, tricky little algorithms, and endless hours spent in front of a text editor and compiler. It's a wonder that anyone wants to learn computing. So what can we do instead? I ran into some interesting ideas on this topic at OOPSLA even before the Educators' Symposium and had a few of my own during the week. I'll be blogging on this soon. Alan has an idea of the general direction in which we should aim, too. This direction requires new tools and curricula designed specifically to introduce novices to the beauty of computing. He held up as a model for us Frank Oppenheimer's Exploratorium, "a collage of over 650 science, art, and human perception exhibits." These "exhibits" aren't the dead sort we find in most museums, where passive patrons merely view an artifact, though. They are stations with projects and activities where children can come face to face with the first simple idea of science: The world is not always as it seems. Why are there so many different exhibits? Kay quoted Oppenheimer to the effect that, if only we can bring each student into contact with that one project or idea that speaks directly to her heart, then we will have succeeded. Notice that, with that many projects available, a teacher does not have to "assign" particular projects to students at a particular point in time. Students can choose to do something that motivates them. Kay likened this to reading the classics. He acknowledged that he has read most of the classics now, but he didn't read them in school when they were assigned to him. Then he read other stuff, if only because the he had chosen for himself. One advantage of students reading what they want is that a classroom will be filled with people who have read different things, which allows you to have an interesting conversation about ideas, rather than about "the book".
What are the 650 examples or projects that we need to light a fire in every college student's heart? Every high schooler? Every elementary school child?
Kay went on to say that we should not teach dumbed-down versions of what experts know. That material is unnecessarily abstract, refined, and distant from human experience. Our goal shouldn't be to train a future professional computer scientist (whatever that is!) anyway. Those folks will follow naturally from a population that has a deep literacy in the ideas of science and math, computing and communication. Here, he pointed to the typical first course in the English department at most universities. They do not set out to create professional writers or even professional readers. Instead, they focus on "big ideas" and how we can represent and think about them using language. Alan thinks introductory computer science should be like this, too, about big ideas and how to represent and think about them in language. Instead, our courses are "driver's ed", with no big ideas and no excitement. They are simply a bastardization of academic computer science.
What are the big ideas we should introduce to students? What should we teach them about language in order that they might represent ideas, think about them, and even have ideas of their own?
Alan spent quite a few minutes talking about his first big inspiration in the world of computing. Ivan Sutherland's Sketchpad. It was in Sketchpad that Kay first realized that computing was fundamentally a dynamic medium for expressing new ideas. He hailed Sutherland's work "the greatest Ph.D. dissertation in computer science of all time", and delighted in pointing out Sketchpad's two-handed user interface ("the way all UIs should be"). In an oft-told but deservedly repeated anecdote, Kay related how he once asked Sutherland how he could have created so many new things -- the first raster graphics system, the first object-oriented system, the first drawing program, and more -- in a single year, working alone, in machine language. Sutherland replied, "... because I didn't know it was hard". One lesson I take from this example is that we should take care in what we show students while they are learning. If the see examples that are so complex that they can't conceive of building them, then they lose interest -- and we lose a powerful motivator. Sutherland's dissertation includes the line, "It is to be hoped that future work will far surpass this effort". Alan says we haven't. Eventually, Kay's talk got around to showing off some of the work he and his crew have been doing at Squeakland, a science, math, and computing curriculum project built on top of the modern, open source version of Smalltalk, Squeak. One of the key messages running through all of this work can be found in a story he told about how, in his youth, he used to take apart an old Model T Ford on the weekend so that he could figure out how it worked. By the end of the weekend, he could put it back together in running condition. We should strive to give our students the same experience in the computing environments they use: Even if there's a Ferrari down there, the first thing you see when you open the hood is the Model T version -- first-order theories that, even if they throw some advanced ideas away, expose the central ideas that students need to know. Alan demoed a sequence of increasingly sophisticated examples implemented and extended by the 5th- and 6th-grade students in B.J. Conn's charter school classes. The demos in the Educators' Symposium keynote were incredible in their depth. I can't do them justice here. The best you can do is to check out the film Squeakers, and even that has only a small subset of what we saw in Vancouver. We were truly blessed that day! The theme running through the demos was how students can explore the world in their own experience, and learn powerful ideas at the "hot spot" where math and science intersect. Students can get the idea behind tensor calculus long before they can appreciate the abstractions we usually think of as tensor calculus. In the course of writing increasingly complex scripts to drive simulations of things they see in the world, students come to understand the ideas of the variable, feedback, choice, repetition, .... They do so by exposing them in action, not in the abstract. The key is that students learn because they are having fun exploring questions that matter to them. Sometime along in here, Kay uttered what was for me the Quote of the Day, no, the Quote of OOPSLA 2004:
If you don't read for for fun, you won't be fluent enough to read for purpose.
I experience this every day when interacting with university students. Substitute 'compute' or 'program' for 'read', and you will have stated a central truth of undergraduate CS education. As noted above, Kay has a strong preference for simple, powerful ideas over complex ideas. He devoted a part of his talk to the Hubris of Complexity, which he believes long ago seduced most folks in computing. Software people tend to favor the joy of complexity, yet we should strive for the joy of simplicity. Kay gave several examples of small "kernels" that have changed the world, which all people should know and appreciate. Maxwell's equations were one. Perhaps in honor of the upcoming U.S. elections, he spent some time talking about the U.S. Constitution as one such kernel. You can hold it in the palm of your hand, yet it thrives still after 225 years. It is an example of great system design -- it's not law-based or case-based, but principle-based. The Founding Fathers created a kernel of ideas that remains not only relevant but also effective. I learned a lot hearing Alan tell some of the history of objects and OOP. In the 1960s, an "object" was simply a data structure, especially one containing pointers. This usage predates object-oriented programming. Alan said that his key insight was that an object could act as a miniature software computer -- not just a data structure, not just a procedure -- and that software scales to any level of expression. He also reminded us of something he has said repeatedly in recent years: Object-oriented programming is about messages, not the objects. We worry about the objects, but it's the messages that matter. How do we make messages the centerpiece of our introductory courses in computing? Periodically throughout the talk, Alan dropped in small hints about programming languages and features. He said that programming language design has a large UI component that we technical folks sometimes forget. A particular example he mentioned was inheritance. While inheritance is an essential part of most OOP, Alan said that students should not encounter it very soon in their education, because it "doesn't pay for the complexity it creates". As we design languages and environments for beginners, we can apply lessons from Mihaly Csikszentmihalyi's idea of "flow". Our goal should be to widen the path of flow for learners. One way to do that is to add safety to the language so that learners do not become anxious. Another is to create attention centers to push away potential boredom. Kay's talks were full of little nuggets that I jotted down and wanted to share: Alan closed both talks on an inspirational note, to wrap up the inspiration of what he had already said and shown us. He told us that Xerox PARC was so successful not because the people were smart, but because they had big ideas and had the inclination to pursue them. They pursued their ideas simple-mindedly. Each time they built something new, they asked themselves, "What does the complexity in our system buy us?" If it didn't buy enough, they strove to make the thing simpler. People love to quote Alan's most famous line, "The best way to predict the future is to invent it." I leave you today with the lines that follow this adage in Alan's paper "Inventing the Future" (which appears in The AI Business: The Commercial Uses of Artificial Intelligence, edited by Patrick Henry Winston and Karen Prendergast). They tell us what Alan wants us all to remember: that the future is in our hands.
The future is not laid out on a track. It is something that we can decide, and to the extent that we do not violate any known laws of the universe, we can probably make it work the way that we want to.

-- Alan Kay, 1984

Guys like Alan set a high bar for us. But as I noted last time, we have something of a responsibility to set high goals when it comes to computing. We are creating the medium that people of the future -- and today? -- will use to create the next Renaissance. -----