INTRODUCTION: The Turing Award is ACM's most prestigious technical award. If you look at past Turning laureates, it will read like a who's who of computer science. The Turing Award is given out annually to an individual who has contributed -- has given contributions of lasting major technical importance in the field -- and the Turing laureate is invited to give a talk on whatever topic they'd like at any ACM conference during the year, and we are privileged to have this year's laureate choose OOPSLA as their venue. So without further ado, I'd like to introduce Dr. Alan Kay. He is a senior fellow at Hewlett Packard, he is president of Viewpoints Research Institute, and the Turing Award was given to him for pioneering many of the ideas at the root of contemporary object oriented programming languages, for leading the team that developed Smalltalk, and for fundamental contributions to personal computing. Let's give a warm OOPSLA welcome to Alan Kay. [ applause ]
ALAN KAY: Of course, one of the funny things about the larger citation was it also said for coming up, helping to come up with many of the ideas that eventually led to C++ and Java. [laughter] And it reminded me of Tony Hoare and his Turing lecture, which is quite good, which is about Algol. He pointed out that Algol was a great improvement, especially on its successors. [laughter]
So about a year ago, I got asked by SIGCSE to come and give a talk here that happened yesterday about early experiences in computing, primarily for high school, and to some extent, for first-year college, and I wasn't, of course, expecting to get this award, and I spent a fair amount of time trying to think about the high-school and college situations, as I had no real experience doing a first course, and I certainly didn't like what I found when I went out and read the books and the AP stuff, and so forth, but I figured nobody wants to hear anybody complain -- even if they're telling the truth -- for an hour, so what I decided to do was to see if I were going to teach a first course in high school or college, what would it be like. That was the talk I gave yesterday, and I wound up thinking that perhaps a slightly different version of this would make a reasonable Turing lecture, so here it is.
First I was to start off with a Don quote. He has lots of them, but this is my favorite one of his. "Beware of bugs in your bug code. I've only proved it correct, not tried it." [laughter]
This is the prefect antidote to what you might call the academization of the field, quite a bit of which has been an attempt to use classical mathematics to deal with the new mathematics that requires a new math to help describe it, so what we have is a new field. I believe math... a simple statement about our field is that math wins, basically every time you can do something reasonably mathematical with what you're trying to do, we've made advances advances. But it's rare that old math wins, because we have a new way of dealing with things. Our theorems are not short, and they're not about infinite things, which is what classical math is generally about. The equivalent of our theorems and groups are very, very long things about finite structures, and so we have a very different way of dealing with that, and hence Don's quote, which I think is absolutely perfect...
Community slide
And because our field is the way it is, everything we do is done within a community, and nobody has benefitted more from their community than I have over the years, and for the stuff I've got to talk about and show tonight, a lot of people contributed, especially over the last few weeks, putting together some of these examples, and these are some of the people. Some of them, you notice, have gray hair. This guy I know is here, Dan Ingalls -- who is the actual creator of Smalltalk. I just wrote the math part, and Dan was the guy that actually made it work. Let's give him a round of applause. [ applause ]
So I guess the first thing to think about here is we have these terms, "computer science" and "software engineering." Um, I happened to be around when both of these terms were made up. Al Perlis made up the term "computer science," absolutely not implying that we had one, but as something to actually aspire to, and I think he immediately regretted it, even in the first few years afterwards, because what happened was what some people sometimes call "physics envy." Basically, everybody who dabbles in the sciences wants to be a physicist, because they deal with the absolute foundations of the universe, and they do it with serious math and serious experiments, so physics envy is -- science envy is -- often found when fields wind up having "science" in their name, so "library science" and "social science"... "computer science..." It's interesting: physics, chemistry, and biology don't have "science" in their name.
So, but I think there can be a science of computing, similar to a science of bridge building, and in fact Simon pointed out they're both called the sciences of the artificial; that you can have a science about artifacts, like a science of bridge building: build a bridge by any means whatsoever, stress it in various ways, analyze it, come up with a theory of bridge-building, build some more bridges, and so forth. And in many ways, physics has found itself becoming a science of the artificial, because a lot of physics is actually all about the science of building accelerators and detectors and trying to figure out exactly what it is that those needle swings actually mean. "Software engineering" actually is a term that came about for a conference in '68 in Garmisch, Germany, and again, the people that went to that conference, except for a few, did not think there was anything remotely like a software engineering at that time, and in fact, the slide shows kind of... from ! the depths to something that you might call engineering today, the difference between a pyramid made out of bricks with no architecture, just a garbage dump with a nice limestone cover, made by slaves... sounds like something that happens a few miles south of here, actually. [laughter] You just imagine some baronic architect at some conference announcing their new pyramid. [laughter and applause]
On the other side of the scale, we have one of my favorite artifacts, the Empire State building, which is well documented. I urge every single one of you who has aspirations to be an engineer to read the three or four excellent recent books about the Empire State building. One of them is the actual log by the foreman, and basically, the Empire State building was constructed from start to finish, that is, from tearing down the buildings that were there to occupancy in less than 11 months, by less than 3,000 people. The flooring itself went up at the rate of almost 2 stories a day, and the steel was still warm -- about a hundred degrees warm -- from the steel mills in Pittsburgh, where it came from. This is one of the greatest organized projects, and the Starrett brothers, who did the Empire State building, but knew they were making a statement, 'cause the Depression had just happened, everything was set up to do this thing, they'd already got a couple of skyscrapers, a! nd they had a feeling this might be the last skyscraper for a while, so they decided to make it an expression of what it meant to be able to make a skyscraper. So it's just the greatest thing, but I think if we look at our own field, we cannot find any instance of 3,000 people being put together to do something incredible in less than 11 months and having it work, so whatever it is that we've got in engineering, it might be closer to Egyptian or Babylonian engineering.
Now, somewhere in the middle, things with arches start appearing, actual architecture appears. Interesting thing that happened some years before we got cathedrals was the Pantheon in Rome, which has this clear span -- it's a dome -- a clear span of 14 stories made up of the best reinforced concrete the world has ever known about 2,000 years ago, so that was amazing. If you've ever been in there, it looks like it was made yesterday, so I think the best practice that we have right now in our field, as far as engineering, is a little bit like a Gothic cathedral. Sometimes our projects take a hundred years, but we can aspire to build rather large structures by the standards of the Middle Ages out of much, much less material than the Egyptians. So, little progress was being made, but I think that whenever we say "computer science" or "software engineering," and especially whenever we think we're teaching it, the worst thing we could ever do is to pretend to the students th! at we know what it is, because the students are going to be the ones that are going to save us. So we should teach the students what I was taught when I was in graduate school in the '60s, and that is: it isn't done yet. It's not even close to done. We have to understand what the actual scope of the computing is going to be, and you have to help us invent it. And in fact, in those years, in the ARPA community, PhDs were given out for actual advances in the state of the art, as opposed to commentaries and small additions to the state of the art, so it's a very different time background, quite simply.
So, I could give a whole talk, maybe not terribly successfully, about motivations. In the end, everything we do, is being subject to other people's motivation, people in the user interface field, particularly in education. But I thought I'd show a much simpler model than we use, but it's only a two-dimensional model, and just have us all conjure it for a bit. So one dimension is in the reasoning and change area is the incredible disparity between the percentage of human beings who are basically instrumental reasoners and those who are basically interested in ideas. Now, this has been studied in a variety of different ways, and it seems like the normal -- us normal human beings are basically instrumental reasoners, and an instrumental reasoner is a person who judges any new tool or idea by how well that tool or idea contributes to his or her current goal. Most of you are very goal oriented, we're working on things, somebody comes up with something new, and our ability ! to accept it or reject it, if we're instrumental reasoners, depends on whether we can see it contributing to our current goal.
The other 5 are primarily motivated by ideas, so a new idea comes along that appeals to them, they will transform themselves and their goals in the presence of that idea. Needless to say, the 5 are much easier to teach, particularly if you're trying to teach them things that were inventions rather than the things that are built into human beings. If you're trying to teach something new and weird like science, it is not an easy thing, because you're dealing with a set of very practical and pragmatic kinds of people.
So and the other dimension here is between -- basically about reward, inner motivated versus outer motivated, so about 85 of us are motivated by things outside of ourselves, and about 15 are motivated by things inside ourselves. And so that's kind of interesting, and what we have there -- if we look at this -- is we have a kind of an interesting category of people who are inner-motivated and interested in ideas, I'll leave it to you to figure out who those people are, and interesting category number two is people who are outer-motivated and interested in ideas. The people who are inner-motivated and note interested in ideas tend to be dangerous and cause a lot of trouble. A lot of corporate executives... [laughter]
But basically, our field is a field that's the next great 500-year idea after the printing press, and so we should all be properly concerned that something quite different; and that is, we have to be concerned with how the entire bulk of humanity is going to respond and deal with the things that we do, so it's extremely interesting to consider the 80 here that are outer-motivated and basically practical, and a fair amount is known about this 80. In the past, I've used the term "voting," but this group does not go to the polls to vote on the things they believe in. It takes them a long time to change what they believe in. The way they do it is kind of interesting, and it's a kind of a consensus that's gradual. It's a seething kind of consensus, and it has many of the same characteristics as a model of a forest fire.
So I have a little particle system here, and the percentage of trees to the percentage of clearing here is just 50-50, so if I say, "okay, let's see if we can spread the fire throughout the forest here," with 50 -- sorry, I didn't initialize that. Let's try it again; here's 50. Surprisingly, it doesn't... let's try it again. Let's try... 50, 60, let's say. The thing about the 60 is people who are almost ready to agree, people who are essentially there, so 10 more spreads better. I'll try another one. Each time, the placement is random, so you get a slightly different behavior... So that's about what you get... It burns itself out. So if you go up to, like 66 or so, 67, 66...
So in these contagion models, you can think of it as in spreading memes, if you will, roughly 23 of this 80 has to pretty much be there before you can get them to agree and do something, 'cause they just won't do it unless everybody else is doing it. This model works really great for even weird things like wearing baseball caps backwards and girls showing their belly buttons. If you trace the girls showing their belly buttons over the years, you'll see how gradual this change was until suddenly it was okay, and the thing is if it's okay now, it was always okay, so what's the problem? Well, the problem was that this group generally didn't think it was okay. It wasn't okay until about 2/3 of them thought it was okay, then all of a sudden, it's okay.
So if you're trying to reform education or you're trying to get a group of people to understand new object-oriented programming, or any other new kind of thing that comes along, you get this incredible disparity, which, in computing, there are many, many instances of roughly 30-year lags from when an idea was really proved out to when it gets generally accepted, and nobody knows whether this 30 years actually means anything or not, but it's interesting to look at the case of UNIX and all of its different adventures over the years, and finally being accepted, even though it has a basically late-60s architecture, which is better than the architecture of some of the operating systems that are around [laughter] but still, it's a fairly old architecture. So I'm desperately trying to hold on to the line?? until at least 2007 or 2008, because quite a bit of the work at PARC peaked 30 years ago, in those days, and I'm curious to see whether those ideas will actually be accept! ed. However, if you look at an extreme case, Doug Englebart, who had some of the best ideas ever, I think he was on a different plane, his ideas are now getting closer and closer to being 40 years old in their articulate expression, and most people still don't understand what it was that he was trying to do.
Now I think that an ancillary problem is that our field, and I think people in general take great delight in complexity. It seems like... if you go to schools, it's remarkable how much work they make the poor kids do, when if they taught the math better and differently, the kids would be doing much less work. But in fact, people delight in complexity and think that putting immense amounts of hard work in, even if there's an easier way, is actually -- there's something morally good about it. And so I think for our field, one of the hardest things is the delight in complexity, because of many levels of structure in computing, and difficulty of going from one level to another, pretty much everyone who gets interested in computing and successful at it is a person who has mastered staggering amounts of complexity. I believe that most of this complexity is absolutely unnecessary, and I believe it can be proved that it's unnecessary.
So what we really want is to find the joy of simplicity, and a lot of this talk is almost a living clich "what shall I say at this talk," simplicity just kept on coming back. All the projects I've been involved in have been successful, successful because the people who worked in them put quite a bit of effort into keeping things simple, and this community of ARPA and then Xerox PARC was outstanding at being simple. And this is a very, very confident group of people, but surprisingly -- I won't use the word "modest," because I don't think anybody would recognize that word applied to these people -- but I would say very, very respectful of these grand ideas they were trying to do.
Butler Lampson here was always pounding for simplicity. Chuck Thacker, who did the Alto in just three months, was master of simplicity. Dan Ingalls, master of simplicity, so... Metcalfe and Boggs; Metcalfe tells great stories about how many things he didn't actually understand, and that it was incredibly important that he didn't understand all of those things, else he never would have been able to invent the ethernet. Gary Starkweather, who did a laser printer; first laser printer was a page a second, 500 pixels to the inch, faster than most laser printers today, was about 3/4 made with parts that Gary got from Edmunds Scientific hobby catalogue, because they were cheap, so he'd get many of them and try them out and so forth.
So, this particular way of looking at things which was basically -- basically, this group said, we're just nowhere near as smart as IBM claims to be. They're always announcing some new complicated network architecture that we can't see how to mak it work, and so we'll just stick to our old full duplex ideas, and do transmission and put a few other things in there, and it may not work as well as what IBM claims it's going to do, but it's probably going to work. And the funny thing is the network speeds today are those terribly designed, unbelievably inefficient, stochastic networks that are far from perfect, but what's great is that they eventually get that packet through perfectly. You just have to be willing to wait.
So, the other thing that this group was really good at was what I call a different kind of simplicity. So it's hard to claim that Maxwell's equations here are simple, because they're... all that work you have to do to understand vectors and curl and divergence and gradient. But the nice thing about it once you've done that work, it shrinks down to something that's just a simple eyeful. The Constitution on the United States is one of my favorite systems design. Think of it: millions and millions of mutually incompatible parts, running without completely breaking for more than 200 years. It's pretty amazing, you can hold it in your hand. The reason you can hold it in your hand is they were wise enough to not put any laws in it. It's not a law-based thing, it's not a case-based thing, it's a principle-based thing. It's a kernel. So, these are the kinds of things that appeal to me greatly over the years, and I think trying to give beginners at computing a taste for the p! ower of the particular kind of simplicity that works so well is what we do.
Now, the other thing I've noticed in talking with younger people and teaching a course, an upper-division course at UCLA once a year, and that is that it's not so much that the juniors and seniors don't know that much. They actually don't know that much, for being close to graduating from college, but the thing that is distressing about them is that the things that they do know, they know very badly, because they know them in ways that are almost counterproductive for their thinking. So I think in a first course, you have a real chance to not just teach the one subject, but in the first course, you can actually touch on a lot of subjects. So for instance, I think math and science should always be taught together in the beginning. They came about that way. One is a language, one is a process. I think systems and computing should be taught together. I think the four of them should be taught together. There are arts: we teach art and engineering and why not throw in a li! ttle bit about how these unusual ways of looking at the world have affected civilization?
I think the other thing that is so critical and so absent in most of our undergraduate computer science curriculum is a failure to think of what we're doing as a kind of literacy. Literacy is something that comes about when you have first, ideas that are worthwhile talking about; writing down those ideas and discussing them, that gives you literature, and literacy is the ability to deal with both the spoken and written forms of these ideas. So when we teach an English class -- our first English class in college -- we're not aiming that class at people who are going to become professional writers when they graduate four years later. We actually think of the impact of the printing press and the new rhetorics and new ways of arguing that came with the printing press as something that is larger than becoming a professional reader or writer. I think the same thing is true of computing. 50 years from now, this will not be controversial. But right now, it's thought of as, e! ven by Stanford -- with its mighty endowment -- as basically vocational training for a job. It's primarily thought of as teaching kids programming. It's absolutely important to learn how to program, but computer science and software engineering are not the same as programming, any more than building Chartres cathedral is the same as bricklaying. You have to understand one to do the other, but they're very different.
I think this is absolutely critical, 'cause the picture on this little slide here is Konrad Lorenz out swimming in the pond with his ducks following him. Remember, Lorenz found that whatever moved near a duckling during one little critical period of a few hours was taken thereafter by that duckling to be its mother, and it would follow even into adulthood that person. And Lorenz found that they would follow him even more happily if he jumped into the water, so there he is. So I think whenever we're introducing somebody to something, we have to realize that we're going to be -- if we're successful -- we're going to be a kind of Konrad Lorenz, and we should take great care in what we're going to imprint them on. What we don't want to imprint them on, for God's sakes, is data structures and algorithms. That was a great idea in the '50s, and we have to understand it and it's still useful today for optimization and other sorts kinds of things, but it's not the center of th! e field. It hasn't been the center of the field for a long time, and what's worse about it, it doesn't scale. There's very little systems aspect in the way the the data structures and algorithms are taught. So I believe what we have to do is give the students a real taste of what the whole deal is, so they have to start thinking in systems ways, and thinking in mathematical ways, scientific ways, as we go along. This is a tall order, obviously.
Now, we all remember our Konrad Lorenz, and mine happened after I'd been a programmer for five years -- a journeyman programmer -- putting myself through school. Went to graduate school, and was given Ivan Sutherland's thesis by Dave Evans. And Dave said, "read it and come back and talk with me about it," and it was a big thick thing, and I saw that his thesis advisor was a guy by the name of Claude E. Shannon. I'd heard of Shannon, and I thought, "well, boy, if Shannon signed this thing, maybe I should read it." And I discovered it was the most amazing thing that I had ever heard of being done with a computer, up to that point, and... I'll just show you a little bit of the idea of it...
So this is the huge machine, which is about the size of this auditorium, had only one guy on it from 3:00 in the morning to 6:00 in the morning, -- notice he just sketched in something there then told those edges to become mutually perpendicular, and sketchpad figured outhow to do that for him -- the first system to have a clipping window, where you're actually drawing on this huge virtual sheet of paper -- then draw quickly, point to these two guys, and say "okay, become parallel," it figures out how to do that. Now he's saying "be co-linear," so "lay yourself over these lines." And of course, this display on this machine only plotted points, so about half the capacity of this machine (from about here over to there) was just to put these little dots up on the screen and pretend there was a line on the display. Now he's got a hole in the flange, and wants to make a rivet... gets some more ink -- notice it's a two-handed user interface, as all user interfaces should be! . That's what that other hand is for. [laughter] Pointing to the center of the crosspiece there, you've got the center of the arc, and again, let's do the mutually-perpendicular trick -- that drags the center guides, which drags the arc guides, into a nice little symmetric rivet. And you could tell it to be in some ratio, with two sides of the vertical part of the rivet, here he's just showing us that it'll do another solution, and now he's going to go back to the original form and show us one other interesting thing, which is you could make instances of this guy.
He gets an instance of the rivet here, you can move it around. See, the success of sketchpad led to a desire for better-looking displays. [laughter] Actually, this twinkling is... they discovered right away that you got seasick unless they randomly plotted the dots, so every time something is being done in there, they're actually sorting half the memory of the machine to keep the dot display random so it wouldn't swim around much more than it is here. He's got four instances now, and he says "whoops, I forgot about the crosspiece," so he goes to the master, which we would call a class, makes the crosspieces transparent, and you can see the instances all feel that. Now he... now he's going to take this thing he just made and make it into a master, so the new construction is a master, and now he can get some instances of this flange here.
So, the range of Sketchpad was surprising, so by the end of 1962, he could not only do stuff like this, but he decided, "okay, I need letters and numbers," so... letters and numbers were actually made out of this sketchpad stuff directly by drawing them in, so all the captions on all his drawings in his thesis were made by the system as well, and then he realized, "oh yeah, I can actually do a bridge, 'cause a bridge acts a little bit like a very stiff set of springs, and I can tell Sketchpad to try and keep these guys constant when something is trying to force them to move, and I can measure the disparity -- the strain on each one of these guys -- and actually I can show them as labels on all of these guys, and I get a simulation of a bridge without Sketchpad ever having heard about a bridge," and he realized, "oh, I can do that with EMF also. I can make circuits and the constraints will actually drive all of the simulations."
So in my career, I think what I've been doing for the last 40 years is trying to get the next version of Sketchpad up. If you think about what this thing is, this is kind of what we are. We want something in which anything that we are interested in -- especially dynamic things that we're interested in -- we can simply draw them in there, put in the relationships that we understand, piece by piece, and have the system synthesize all this interdynamic simulation of astounding range. It was just beautiful. There... I don't know whether our field has a Newton in it yet, but if it has a Newton, then I think it would have to be Ivan Sutherland, 'cause where the field was before Ivan came on the scene and after is this fantastic. I went to ask Ivan "how could you possibly in one year, in machine code, on this big but rather slow machine with no graphics display on it, have done the first graphic system, the first object-oriented software system, and the first dynamic problem! -solving system?" and Ivan looked at me and said, "well, I didn't know it was hard." By the way, this thesis is available from MIT, you should get it and read it. My favorite line from it is... it says, "it is hoped that future work will far surpass this effort."
So, that was my first day in graduate school... and the second day, I found out about, that I was actually in the middle of the ARPA community, which I had no realization about. And Licklider was not the funder in 1966, it was Bob Taylor, and they were just starting to talk about what doing what Licklider called "the intergalactic network," and the reason he called it that is he didn't want people to design a small network. His original theory was wherever there's an electricity plug on the face of the earth, there should be a place where you can plug into this intergalactic network, and that meant the thing had to scale at least up to 500 million to a billion users, so people were starting to think about that.
And a couple of days later, I got a tape and some shockingly bad language called Simula from Norway, by Dahl and Nygaard, and it was very hard to understand, and after a lot of work and looking at the listing, you realize it wasn't a programming language that is dealing with the same kind of structures as Sketchpad. By the way, I should mention the name, the term "object," predates object-oriented programming. "Object" in the early '60s was a general term that was used to describe compound data structures, especially if it had pointers in it. So it's not in the paraphernalia of what we think about as "object-oriented programing" today. "Object" was just a general term, you find it in lots of old papers. And the realization that you could write procedures for dealing with kinds of structures in Sketchpad was very liberating, 'cause even though it was ugly, compared to what Sketchpad was -- Sketchpad was just unbelievably elegant, but nobody knew how to scale the solver! problem. In fact, that problem has not been solved today.
But by going to the less elegant way of being able to write code against these structures, we all got excited about the possibilities of being able to do, in a system like Simula, the kinds of graphic interaction and manipulation. My background coming into this was in molecular biology and mathematics, and particularly Sketchpad just hit me right here as one of these kernels. And the thing I suddenly realized was that if you were sufficiently abstract, you ignored what these systems were trying to do, and you just thought of them as being cheap versions of all these little computers on the ARPAnet, you could solve the scaling problem in software, then you could actually subsume everything in computing with just one kind of idea, which is essentially a little software computer -- not a procedure, not a data structure, but a whole computer. And a lot of the development of OOP was software engineering after that, 'cause the interesting things to me in development of OOP ! and the development of practical OOP as it happened at XEROX Parc was very similar to what happened in LISP earlier, which is, "boy, we've got this incredibly elegant, wonderful thing. Too bad it runs so slow, but what if we could make it run faster in a way that doesn't get in the user's way? Then we would have something really good." Some of the best... actually, I just talked to Guy Steele, who was one of the people who helped make LISP into something really special to use, as well as contemplate. So the image here was "wow, it's all about messages." The reason it's about messages and not about objects so much is that the messages are the abstractions. We spend far too much time in our field worrying about what the objects are. So...
(I need to move along.)
I have a zillion prejudices: I love of parallelism, 'cause I think I we should learn to program plugboards before programming computers, and the beauty about those things, when you make a kind of machine that is highly parallel. I love hardware like the B5000. All of our virtual machines today that we use came out of the hardware of that machine. Too bad Motorola never saw fit to learn anything about software... would've made our lives a lot simpler. I love LISP; everybody should understand it. JOSS was the most beautiful programming language ever done; it could hardly do anything but it did it beautifully. [laughter] It is an interesting challenge to make something of this level of beauty and try to scale it. You combine these two together and you've got the original Logo. That's how Logo came about, and to take Lisp and have something prettier, especially for kids. I love APL. All of these systems, I think, can be done in a different way, but basically the love in t! hese things is because these guys got to some special kernel. I love what Englebart did; I love spreadsheets; I love Hypercard. Suppose you could amalgamate all these wonderful things into a simple system that regular people could use.
Okay, now, let's talk about the whys of what we're doing. Why do people do things? Well, Frank Oppenheimer in the Exploratorium made 500 exhibits to teach just one idea, the world's not as it seems. You ask him why, and he said "well, every child is different. If you have 2,000 children in here bumping against 500 different exhibits, there's a good chance that a child will find the exhibit that speaks to them clearly about this first important idea about science." So he set up 500 of them. I think if you're going to teach a course in this, you need 20 to 30 projects or so, for each area, to give the children the choice.
[shuts down rude audience members... applause... "I won't tell you what quadrant they're in."]
So I think the... another important idea is scratch programming, just so much of computing education today is learning the library, and I don't think beginners should ever be shown the library. If the programming language can't do interesting things without the library, then what is it? So I think it should be like a Model T; a Model T has about 350 parts, and you can take it apart over a weekend and put it back together, but it was a completely real automobile. So a lot of what we're going to look at here in the next few minutes are sort of first-order ideas that might say some important things.
Now, the good thing is that many people have written about "find the beauty, the romance, what's important," and about looking ahead in computing. There's not just one book out there, and it's less than 1 of the books about computing that are worthwhile reading. It's not one book. There are dozens of them, so there's plenty of ideas for how to do this stuff. The user interface had better not be like Microsoft's caricature of the stuff that was done at PARC. I always have the feeling when I'm using Windows that I'm dealing with a somewhat dangerous nuclear reactor controller, and that I haven't had enough training on it, whereas what I want is something like pencil and paper, where although there are things I can learn about pencil and paper, what's most important about them is what I can do without knowing much. So I can find out that pencil and paper is fun.
I want an environment that deals with a set of ideas in a way that gets me to lose myself in the ideas, so like Csikszentmihalyi here -- who is one of our advisors -- had this nice model about the balance between our abilities and the challenges. He said well, if the challenges are higher than our abilities, then we start getting anxious, especially if we're climbing up a rock face or we're going to give a talk in front of an audience, but if our abilities are greater than the challenge, we start getting bored.
These are the two main states that humans are in; we're either anxious or bored. Hard to get to is this flow state where everything is just working, and we like to widen this flow state for beginners, so for example one of the things we have to do to deal with areas where the challenge is greater than our abilities is to increase the safety, so having "undo "in an environment is kind of nice. Most programming environments don't have much of an undo. But on the other hand, 'cause we get bored so easily, we want something to help us pay attention better, and a good user interface basically deals with these things. It provides more safety than most computer people think an ordinary person needs, it provides more ways of attracting their attention than most of us think people need.
So I just want to show you, give you a little bit of the flavor about how children start, and then show you where I think things are actually going to go.
So the work we do with children... we want them to have an experience that's basically thinking about ideas, making pictures of them -- so, for example, take something that most kids would like to do for one reason or another, which is to learn how to drive their parents' car. We get them to design a car, and most kids, boys and girls, put on big off-road tires like this. 'Cause part of the deal is feeling powerless and wanting to feel empowered. This is something video game manufacturers really understand: why are those games so violent?
And we have a little graphic object here, and we can do things to it, we open it up and see a viewer of it -- I realize people in the back can't see very well -- so I'm looking at a property here called the heading of the thing, I'm going to count up the number, starts at zero, and as I count it up, you can see the little car turning. I've got a behavioral property here, forward; I've got another called "turn by," and so if I just drag out to lines of the script here, and turn on the clock, then I've got my little car going. Many different kinds of things I can do with it. For the kids, they want to learn a little bit about driving the car, so the first experiment is what happens if I click this number that says "turn by," now "turn by zero," it goes straight; "turn by negative"... I'll call this guy "car," to keep it straight here... it's a little bit like kissing your sister, so... 'cause real cars use wheels, so I want to make a wheel here -- just draw one -- and i! t's got the same user interface as the other one, because this is a system which is only one kind of object.
It's exactly the opposite of the systems that you're used to that have zillions and zillions of classes and subclasses and so forth. We can talk a little bit about this in the question and answer session if you like. So here's this wheel, it's got a heading also, and if I pick up the name of that heading and just drag it over to the script here, so it says "car turn by wheel's heading value," and just turn the car around.
Now, what's important for 10 year olds is that they learn what a variable is for the rest of their life in this one shot. That's good. And actually I believe this would be good for high school and college kids too, because there's quite a bit of evidence that they don't ever learn much about what a variable actually is or does, and ways of thinking about it. So there are many different kids of things here that can be done.
So having one kind of object, that's kind of weird. I mean, here's a photograph which you can see has the same kind of deal: the script is one of these guys; what if I open up its viewer... I've got one called "scriptor" here, and I say, you know, it's really the same kind of thing, so what if I make a script on the script here, and... [laughter]
So, think about the implications of this, the thing is that wherever I... well, for instance, what if I go over here? Well, viewer's got one of those things, and so does this category... and this whole outside thing that I'm giving a talk in terms of is also one of these things, so I look at its viewer, the viewer of the world, and well, it's got the same kinds of things here. If you look at the various traits here, this is like what Nathanael Schaerli was talking about earlier.
This notion of sideways composition also goes back to PARC. Back then in the '70s, it was called "aspects," but that word means something somewhat different now. So when you look at these various things, you can see "oh, the thing is a collection," it's got stuff about about its colors and borders and other kinds of things here. And here's one that says "as object." Now, in an inheritance system, the object would be way up at the end of the inheritance system, but in the sideways composition object system, it's going to be one of the traits we're looking at. It's a view of the object as object, and we tried to think about what would be an interesting way of showing this idea of "meta," so here's one where what I'm going to do is suppress all the costumes on all of the objects, and I think this will help you see that everything is sort of abstractly the same here.
Okay, so basically, I just turned off the costume mechanism. I have this interesting problem with getting back... [laughter] but that's why I left my mouse here, so this is the guy who did it, so I'm going to click the little caret here, which I know is there, to make it false, and then hit the exclamation point to turn everything back on again. So... see, I'm talking about ... basically, "meta" is safe if you can allow fence after fence after fence after fence.
Now, there are many, many examples, which, if I had a longer talk, I'd show you, but I wanted to show you the last set of ideas here, so if we could just go to video 2 please, in the back? Okay, so returning to Sketchpad here, now, if we look at a more future-oriented environment, we see that we now have the ability of doing much more complicated ways of thinking of environments, so here I am in a 3-D environment that we built called "Croquet," and by the way, if you're interested in the kids' stuff, it is found on the website, squeakland.org, and this Croquet environment -- this is all free software -- the Croquet environment is found on opencroquet.org.
So again, this is a completely constructible environment here, but what we did was to do a kind of interesting analogy to web pages, so each 3-D world here is like a web page, and these portals are like a hyperlink to them, so I'm just going to pop Alice into this guy here. I'm just going to do a 360... this is the Mars environment. All of these environments are buildable.
I'm just going to show you one last thing so I can end on time. I kind of like bridges as an analogy here, so we have a bridge structure, and I want to show you what the kids' scripting environment looks like for doing a bridge, so the first thing you want to look at is the little script for masses. Basically what we have here is f=ma, acceleration is force divided by the mass, velocity is increasing by the acceleration, and the location of all the little elements on here is going to increase by the velocity, and I'm going to turn on the force here, if I can get this mouse to work, and say "okay, let's do that..." So this bridge structure is feeling gravity, you can see it coming into equilibrium. I could have made it stiffer, so let's look at the springs. The springs are fairly stiff; K gets -1,400 here, and so what I'm going to do here is to make it -400, tell it to go ahead, so that's going to let it sag quite a bit more.
Do we all remember the Tacoma Narrows bridge film? So of course we have to have some wind, and basically what I'm going to do here is turn on a variable gusting wind that's completely described by this script here, and... so now it's going to do some Tacoma Narrows stuff here... Now, it needs sound. I noticed the sound wasn't working. Thank you. So let's take a look at our bridge here. Now, you know, it's funny, when you look at the model of steel, you remember that Tacoma Narrows bridge movie, it was really like the bridge was made out of fabric of some kind, and this has this kind of same aspect, and that gave us an interesting idea here. [O Canada plays] [applause]
So I think a good way to end this talk is just to say that if we can't get kids interested in the romance of why this is an unbelievably beautiful new art form, then we're not living up to what our duty is of enjoying this stuff ourselves. We have to reach deeply inside of ourselves to remember what it was that first got us interested in the wonderful new thing. Remember that it hasn't even started yet, and it's our duty to help the children as young as possible try and do a better job of it than we have. Thank you very much. [applause]