Alan Kay Turing Award Lecture (2004)

Good Afternoon, and welcome to the Association for Computing Machinery's Turing Award Lecture.

The Turing Award is ACM's most prestigious technical award.

If you look at past Turing laureates, it'll 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 and major technical importance to 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.

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's a senior fellow at Hewlett Packard. <subtitle id="0:1:1">He's president of Viewpoints Research Institute.

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.

⊕(time: 0:1:47)

Of course, one of the funny things about the larger citation was, it was also said for coming up and helping to come up with many of the ideas that eventually led to C++ and Java.

It reminded me of Tony Hoare's, in his Turing lecture, which was quite a bit about ALGOL. He pointed out that ALGOL is a great improvement, especially on its successors.

About a year ago, I got asked by SIGCSE to come and give a talk here, which 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.

I had spent a fair amount of time trying to think about the high school and college situation.

Since I had no real experience doing a first course.

And, I certainly didn't like what I found when I went out and read 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.

⊕(time: 0:3:53)

Here it is. First I want to start off with a Don quote.

He has lots of them, but this is my favorite one of his.

"Beware of bugys in the above code; I've only proved it correct, not tried it.

This is the perfect antidote to what you might call the academization of the field, which, quite a bit of which, has been an attempt to use classical mathematics to deal with a new mathematics that requires a new math to help describe it.

So what we have is a new field.

I believe a simple statement about our field is that math wins: Basically every time you can do something reasonably mathematical what we're trying to do, we make great 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 proofs are very very long things about finite structures.

So we have a different way of doing about, and hence Don's quote, which i think is absolutely perfect.

⊕(time: 0:5:19)

Because our field is the way it is, everything we do is done within a community, and nobody has benefited more from their community than I have over the years.

For the stuff I'm going to talk about and show tonight, a lot of people contributed, especially over the last few weeks, putting together some of these examples.

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 who actually made it work.

So, we should give him a round of applause.

⊕(time: 0:6:20)

I guess the first thing to think about here is we have these terms: Computer science and software engineering.

I happen 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, even in the first few years afterwards, because what happened was what some people have sometimes called physics envy.

Basically everybody who dabbles in the sciences wants to be a physicist, because they deal with the absolute foundations of the universe.

They do it with serious math and serious experiments.

Physics envy is, science envy is often found when fields wind up having science in their name.

So, library science, social science, computer science.

Interestingly physics, chemistry, and biology don't have science in their name.

I think there can be a science of computing, similar to a science of bridge building, and in fact, Simon pointed out in his book 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 build bridge building build some more bridges and so forth.

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 just exactly what it is that those needle swings actually mean.

Software engineering actually was a term that came about for a conference (I think) in '68 and Garmisch, Germany.

Again, the people who went to that conference, except for a few, did not think there was anything remotely like a software engineering at that time.

In fact, the slide shows kind of..., from the depths to something that we might call engineering today of 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.

I can just imagine some feronik architect at some conference, announcing their new pyramid.

On the other side of the scale, we have one of my favorite artifacts: the Empire State Building, which is well documented and 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.

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 two 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.

The Starrett brothers who did the Empire State Building knew they were making a statement, because the Depression had just happened.

Everything was set up to do this thing. They had already done a couple of skyscrapers and 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.

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 something incredible in less than 11 months and have it work.

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 started appearing, an actual architecture appeared.

Interesting thing that happened some years before the Gothic cathedrals was the Pantheon in Rome, which has this clear span, the dome of clear span of fourteen stories.

Made out of the best reinforced concrete the world ever known, but two thousand years ago. That was amazing.

if you've ever been there, it looks like it was made yesterday.

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 needed.

So, little progress is being made but I think that whenever we say computer science or software engineering, especially whenever we think we're teaching it, the worst thing we could ever do is to pretend to the students that we know what it is.

Because the students are going to be the only 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 sixties: that is it isn't done yet. It's not even close to be done. You have to understand what the actual scope of computing is going to be and you have to help us invent it.

In fact, in those years in the ARPA community, the PhDs were given out for actual advances in the state of the art, as opposed for, as opposed to commentaries and small additions to the state of the art.

So it was a very different time back then but it was a lot simpler.

⊕(time: 0:13:35)

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 motivations, in particular the user interface. I feel 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 ponder 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,

those who are basically interested in ideas. This has been studied in a variety of different ways.

It seems like the normal us, normal human beings, are basically instrumental reasoners.

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.

so, most of us 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, when a new idea comes along that appeals to them, they will transform themselves and their goals in the presence of the idea.

Needless to say, the 5% are much easier to teach. In particular, if you're trying to teach them things that were inventions, rather than things that are built into human beings.

If you're trying to teach something really weird like science, it is not an easy thing, because you're dealing with a set of very practical and pragmatic kinds of people.

The other dimension here is (between) basically about reward:

Inner-motivated vs. outer-motivated.

About 85 percent of us are motivated by things outside of ourselves. About 15 percent are motivated by things inside ourselves.

That's kind of interesting.

What we have here, 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 for you to figure out who those people are.

An interesting category number two is people who are outer-motivated and interested in ideas.

The people who are inner-motivated and not interested in ideas tend to be dangerous and caused a lot of trouble.

A lot of corporate executives are up in there.

Basically, our field is a field that's the next great 500 year idea after the printing press. And, we should all be properly concerned with something quite different.

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 our outer-motivated and basically practical.

A fair amount is known about this 80 percent.

In the past, I've used the term voting.

⊕(time: 0:17:35)

You know, 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.

But the way they do it is kind of interesting. It's a kind of a consensus that is gradual.

It's a seeping kind of consensus, and it has many of the same characteristics as a model of a forest fire.

I have a little particle system here.

The percentage of trees to the percentage of clearing here is just 50/50.

If I say okay, let's see if we can spread the fire throughout the forest here with a 50%.

I didn't initialize that. Let's try again.

Here's 50%.

So surprising that it doesn't [burn much]. Try again.

Let's try go up to 60%, Let's say. You can think of the 60% as people who are almost ready to agree.

People are essentially there. So 10% more, it spreads better.

Try another one. Each time the placement is random so you got a slightly different behavior.

Yeah, so that's about what you get.

they burned itself out. If we go up to like 66 percent or so 67, 66.

Yeah. In these contagion models, you can think of this as spreading memes, if you will.

Roughly two-thirds of this 80% has to pretty much be there before you can get them to agree and do something: because 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.

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 two-thirds of them thought it was okay. And then, all of a sudden it became okay.

So, you're trying to reform education, or you're trying to get a group of people to understand real 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.

Nobody knows whether this thirty 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.

But still, it's a fairly old architecture. So, I'm desperately trying to hold on to life until at least 2007 or 8.

Because quite a bit of the work at PARC peaked 30 years ago from those days, and I'm curious to see whether those ideas will actually be accepted.

⊕(time: 0:22:05)

However, if you look at an extreme case, Doug Engelbart, who had some of the best ideas ever.

</subtitle>

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.

⊕(time: 0:22:29)

I think an ancillary problem is that our field and people in general take great delight in complexity.

It seems like, you go to schools, it is remarkable how much work they make the poor kids do, when if they taught the math better and differently, the kids would have to do much less work.

But in fact, I think people the light in complexity and think that putting immense amounts of hard work in even if there's an easier way actually.

There's something morally good about it.

I think, for our field, one of the hardest things is the delight of complexity, because of the many levels of structure in computing and the difficulty of going from one level to another.

Pretty much everyone who gets interested in computing and a successfulabout it is a person who has mastered staggering amounts of complexity.

Now, I believe that most of those complexity is absolutely unnecessary, and I believe it can be proved that it's unnecessary.

⊕(time: 0:23:53)

What we really want is to find the joy of simplicity.

A lot of this talk is almost a living cliché, in the sense that very little of what I'm going to say here is stuff that you don't already know.

But, when I started thinking about what should I say at this talk, simplicity just kept on coming back.

All the projects I've been involved in that have been successful have been successful because the people who worked in them put quite a bit of effort into keeping things to be simple.

⊕(time: 0:24:35)

And, this community of ARPA and then Xerox PARC was outstanding at being simple.

This is a very, very confident group of people. <subtitle id="0:24:50">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 we are very, very respectful of these grand ideas they are trying to do.

Butler Lampson here was always pounding for simplicity.

Chuck Thacker, we did the Alto in just three months, was a master of simplicity.

Dan Ingalls was master of simplicity.

So were Metcalfe and Boggs.

Metcalfe tells a great, great stories about how he didn't actually -- how many things he'd actually didn't understand.

It was incredibly important that he, of those things else, he never would have been able to invent the Ethernet.

Starkweather, who did the laser printer -- first laser printer was a page a second, 500 pixels to the inch, faster than most laser printers today, was about three-quarters made with parts from Edmunds hobby catalog,

because they were cheap so he could get many of them and try them out, and so forth.

This is, this particular way of looking at things, which was basically Hayward basically the 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 make it work.

So, we'll just stick to our old full duplex ideas and retransmission, and put a few other things in there.

It may not work as well as what IBM claims it's going to do, but it's probably going to work.

Funny thing is that the network's we use 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.

⊕(time: 0:27:14)

The other thing that this group was really good at was what I call a different kind of simplicity.

It's hard to claim that Maxwell's equations here is simple, because there are all that work you have to do to understand vectors and curl and divergence and gradient.

But the thing about it is once you've done that work it shrinks down to something that's just a simple eyeful.

the Constitution of 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. Pretty Amazing.

You can hold it in your hand. The reason you can hold it in your hand is they were wise not to put any laws in it.

It was not a law-based thing. It's not a case-based thing. It was a principle-based thing. It was a kernel.

These are the kinds of things that appeal to me greatly over the years.

I think trying to give beginners at computing a taste for the power of the particular kind of simplicity that works so well is what we should do

⊕(time: 0:28:35)

Now, the other thing I've noticed in talking with younger people and teaching a course, upper division course UCLA once a year, 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 the stressing about them is that the things that they do know, they know very badly,

as they know them in ways that are almost counterproductive for their thinking.

So I think in a first course at anything, you have a real chance to not just teach the one subject, but in the first, you can actually touch on a lot of subjects.

For instance, I think math and science should always be taught together in the beginning.

They came about that way one is a language and one is a process.

I think systems and computing should be taught together. I think the four of them should be taught together.

there is arts. We should teach you art and engineering, and why not throw in a little 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 curricula is the failure to think what we're doing as a kind of literacy.

Literacy is something that comes up about when you have first ideas that are worthwhile talking about.

You have a way of writing down those ideas and discussing them that gives literature.

Literacy is the ability to deal with both the spoken and the written forms of these ideas.

When we teach an English class our first English class in college, we're not aiming 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 a printing press as something that is larger than becoming a professional reader or writer.

I think the same thing is true of computing.

Fifty years from now, this will not be controversial. Right now, it's thought of as even in mighty Stanford with its great endowment as basically vocational training in Java and 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 Brick Layering.

You have to understand one the other but they're very different.

I think this is absolutely critical, because the picture on this little slide here is Konrad Lorenz out swimming in the pond with his ducks following.

Remember of Lorentz 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 that person.

Lorenz found that they would follow him, even more happily if he jumped into the water. So, there he is.

I think whenever we're introducing somebody to something, we have to realize that we are going to be a Konrad.

If we're successful, we're going to be a kind of Konrad Lorenz, and we should take great care to what we're going to imprint them on.

We don't want to imprint them on, for God's sakes, the data structures and algorithms.

That was a great idea in the 50s and you had to understand it. And, it's still useful today for optimization and other things.

But, it is not the center of the field for a long time.

What's worse about it is it doesn't scale.

Those very little systems aspect in way the data structures and algorithms are taught.

I believe that we have to do is to give the students a real taste of what the whole deal is.

They have to start thinking in systems ways thinking in math and alkaway scientific ways as we go along.

This is a tall order, obviously./subtitle>

⊕(time: 0:33:32)

<subtitle id="0:33:32">Now, we could all remember our Conrad Lorentz, 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.

Dave said: "read it, then come back and talk with me about it."

It was big thick thing but I saw that his thesis advisor was a guy by the name of Claude E. Shannon.

I'd heard of Shannon. I thought: "Well, boy, if Shannon signed this thing maybe I should read it."

I discovered that it was the most amazing thing that I had ever heard of.

Being done with a computer up to that point, and just show you a little bit of the idea of it.

This, which is about the size of this auditorium, had only one guy on it from 3 o'clock the morning.

You know, as he just sketched in something there, then told those edges to become mutually perpendicular, and Sketchpad figured out how to do that for him.

First system to have a clipping window. You are actually drawing on this huge virtual sheet of paper.

Danny draw quickly point to these two guys and say, "okay become parallel". It figures out how to do that now.

He's saying be collinear to lay yourself over these lines.

Of course, this display on this machine only plotted points.

About half the capacity of this machine, I'm about here over to here.

It was just to put these little dots up on the screen and pretend it was a line drawing display.

Now, he's got a  hole in the flange, okay.

And, he wants to make a rivet.

Got some more ink. Notice that the two-handed user interface, as all user interfaces should be.

That other hand is for point.

He center of the cross piece there to get the center of the arc and again, let's do the mutually perpendicular trick,

that drags the center guy, which drags the arc guys we got a nice little symmetric rivet.

And, he could tell it to be in some ratio.

The two sides of the vertical part of the rivet. Here, he's just showing it us that will do another solution.

And, now he's going to go back to the original form and show us one other interesting thing,

which is he can make instances of this guy.

They get an instance of the rivet. here I can move it around. See, the success of sketchpad led to a desire for a better looking displays, actually.

Those twinkling is they discovered right away that you got seasick unless they randomly plotted the dots.

something is being done in there. They are actually sorting half the memory of the machine to keep the dot display random.

it wouldn't swim around much more than it it is here.

He's got four instances now, and he says, whoops, I forgot about the cross piece. So, it goes to the master,

which we would call a class makes the cross pieces transparent.

And, we see the instances all feel that.

Now, he's going to take this thing that he just made, and make it into a master.

So, the new construction is a master. Now, he can get some instances of this flange here.

So the range of Sketchpad was surprising.

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 the Sketchpad stuff directly by drawing them in.

So, the captions on all of his drawings and his thesis were made by the system as well.

And then, he realized, oh yeah, I can actually do a bridge.

Because the bridge actually acts a little bit like a very stiff set of springs.

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 I actually can show those labels on all of these guys, and, Iget a simulation of a bridge without Sketchpad ever having heard about a bridge.

He realized, oh, I can do that with EMF also.

I can make circuits, and the constraints will actually drive all of these simulations.

In my career I think what I've been doing for the last forty years is trying to get the next version of Sketchpad out,

because if you think about what this thing is. This is kind of what we want.

We want something, in which anything that we are interested in, especially dynamic things that were 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 into a dynamic simulation of astounding range.

It's just beautiful. If they're, I don't know whether our field has Newton. Yeah, I knew then. <subtitle id="0:40:5"> I think it would have to be Ivan Sutherland, because the field was before I even came on the scene, and after it was 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 graphics system, the first object-oriented software system, and the first dynamic problem-solving system.

Ivan looked at me and said: "Well, I didn't know it was hard."

so the period, by the way this thesis is available from MIT - you should get it and read it.

My favorite line from it is, he says that his hope that future work will far surpass this effort.

So, that was my first day in graduate school.

⊕(time: 0:41:14)

And second day, I found out about that I was actually in the middle of the ARPA community, which I had no realization about.

Licklider was not the funder in 1966: it was Bob Taylor and they were just starting to talk about doing what Licklider called the Intergalactic Network.

The reason he called it that is he didn't want people to design a small network.

Those original theory was wherever electricity plug on the face of the earth, there should be can plug into this into.

Like intergalactic network that the thing had the scale at least up to 500 million to a billion users.

So, people were starting to think about that. In a couple of days later I got a tape and some documents about a language called Simula from Norway by Dahl here and Nygaard.

It's very hard to understand.

After a lot of work, and looking at the listings, we realize, well, this is a programming language that is dealing with the same kind of structures as Sketchpad.

By the way, I should mention that, you know, 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 they had pointers in them.

There was none paraphernalia of what we think about as object native programming today. Object was just a general term.

You'll find it in lots of old papers.

And, the realization that you could write procedures for dealing with at Sketchpad was doing was very liberating,

because even though it was ugly compared to what Sketchpad gets bad was just unbelievably elegant.

But, nobody knew how to scale that's  Oliver.

In fact, that problem has not been solved today yet.

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 and interaction 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.

The thing I suddenly realized was that if you were sufficiently abstract if you ignored what these systems were trying to do,

if you just thought of them as being cheap versions of all these little computers on the ARPANET,

you could solve the same 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.

A lot of the development of OOP was software engineering after that.

Interesting things to me in the development of who the Elven of practical as it wound up in spark 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 users way, then we would have something really, really nice.

Some of the best actually I just talked Guy Steele, who is one of the people who helped make Lisp into something really special to use as well as to contemplate.

So, the image here was wow it's all about messages.

The reasons about messages are not about objects so much is that the messages are the abstractions.

We spend time in our field worrying about what the objects are.

⊕(time: 0:45:53)

I need to move along a bazillion prejudices.

I love parallelism because I learned how to program plug boards before programming a computer.

The beauty about those things was you could make a kind of a machine that was highly parallel.

I loved hardware like the B5000.

All of our today that we use came out of the hardware of that machine never

saw fit to learn anything about software make our lives much simpler.

I love Lisp.

Everybody should understand it the giass was programming language ever done. it could hardly do anything but it did it beautifully.

It's an interesting challenge to take something of this level of beauty and try to scale it.

You combine these two together, you got the original Logo that's how Logo came about:

an attempt to take Lisp and have something prettier especially for kids.

I love APL. All of these all of these systems I think can be done in a different way.

But basically the love of these things is because these guys got to some special kernel.

I love what Engelbart did. A lot of spreadsheets. I loved HyperCard.

Suppose you could amalgamate all these wonderful things into a simple system that regular people can use.

⊕(time: 0:47:32)

Now, let's talk about the why 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 is not as it seems.

They asked him why, and he said: "well, every child is different. we 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 said 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.

(Am I interrupting your conversation?) <subtitle id="0:48:38">I won't tell you what quadrant they're in.

⊕(time: 0:48:59)

I think the another important idea is scratch programming, because so much of computing education today is learning the library.

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?

I think it should be like a Model T. Model T has about 350 parts, and you could take it apart over a weekend and put it back together.

But, it was a completely real automobile.

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.

⊕(time: 0:49:41)

Now, a good thing is that many people have written about the fun, the beauty, the romance, what's important and about looking ahead in computing.

There's not just one book out there, and there's less than 1% of books about computing are worthwhile reading.

But, it's not one book. There are dozens of them, and there's plenty of ideas for how to do this stuff.

⊕(time: 0:50:17)

The user interface had better not be like Microsoft's caricature of the stuff that was done at PARC, which is I always have the feeling when I'm using Windows that I'm dealing with a somewhat dangerous nuclear reactor control panel,

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 is most important about them is what I can do without knowing much.

I can find out the pencil and paper is fun.

⊕(time: 0:50:56)

I want an environment that deals with a set of ideas in a way that gets me to lose myself in the ideas.

Mihaly Csikszentmihalyi here, was one of our advisors, had this nice model about this 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, we're giving a talk in front of an audience.

But, if our abilities are greater than the challenge, we start getting bored.

So, these are the two main states that humans are in: either anxious or bored.

Hard to get to is this flow state where everything is just working.

We like to widen this flow state for beginners.

For example, one of the things we could do to deal with areas that where the challenge is greater than our abilities is to increase the safety.

So, having undo in an environment is nice.

most programming environments don't have much of an undo.

On the other hand, because we get bored so easily, we want something to help us to pay attention.

A 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.

⊕(time: 0:52:50)

Alan is drawing a car, explain the viewer and some tiles.

I just want to show you, give you, a little bit of a 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 is basically thinking about ideas making pictures of them.

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, because part of the deal is feeling powerless, and wanting to feel empowered

this is something that video game manufacturers really understand.

Why are those games so violent?

So, we have a little graphic object here, and to do things to it, we can open it up and see a viewer of it.

People in the back can't see very well. So I'm looking at a property here called the heading of the thing, and I'm going to count up the number starts at zero.

As I count it up, you can see the little car turning.

I've got a behavioral property here: "forward."

I've got another one called "turn by".

If I just drag out the lines of script here and turn on the clock, then I've got my little car going.

There are 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.

It says "turn by". Now, "turn by zero".

It goes straight. "Turn by negative". I'll call this guy car.

Keep it straight here. That's a little bit like kissing your sister, because real cars use wheels.

So I want to make a wheel here. Just draw one.

It's got the same user interface as the other one.

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 it, about this in the question and answer, if you would like.

And, so here's this wheel it's got a heading also.

If I pick up the name of that heading and just drag it over to the script here.

So it says "car turned by wheel's heading."

Now, I can just turn the car around.

Now, what's important for ten-year olds is that they learn what a variable is for the rest of their life from 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 they don't ever learn much about what a variable actually is, or does ways of thinking about it.

So there are many different kinds of things here that can be done.

⊕(time: 0:56:50)

Open a viewer on the scriptor and rotate them.

So, having one kind of object. That's kind of weird.

I mean, here's a photograph which we can see has the same kind of feel here.

The script is one of these guys. What if I open up its viewer.

I got one called scriptor here, and I see y'all look really the same kind of thing.

So what if I make a script on the script here, and get.

I think about the implications of this means that wherever I go out, for instance, what if I go over here.

⊕(time: 0:57:32)

Open a viewer on the pane in viewer and rotate them.

Well, the viewers got one of those things and so does this category.

⊕(time: 0:57:41)

Open a viewer on the world, and show different panes.

And, this whole outside thing that I'm giving the 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.

We looked at the various traits here. This is like what Nathanael Schärli was talking about earlier.

This notion of side-ways composition also goes back to PARC.

Back then in the 70s, it was called aspects but that word means something somewhat different now.

We, various things you can see. Oh, the thing is a collection.

It's got stuff about its colors and borders, and other kinds of things here.

And what, here's one that says 'as object'. Now, an inheritance system the Object would be way up at the end of the inheritance system.

But in a side-ways composition object system, it's going to be one of the traits. We're looking at it's a view of the object as an object.

We tried to think about what would be an interesting way of showing this idea of meta.

Here's one where I'm, what I'm going to do is suppress all the costumes on all the objects.

⊕(time: 0:59:2)

Choose world useBluePrintCanvas: to change the look.

And, I think this will help you see that everything is sort of abstractly the same here

Ok, basically I just turned off the costume mechanism.

Now, I have this interesting problem of getting back.

But, that's why I left my mouse here. so, this is the guy who did it. I'm going to click the little caret here, which I know is there to make it false

Then, we're going to hit the exclamation point to turn everything back on again.

You see, I'm talking about them, basically, meta is safe if you can allow fence after fence after fence after fence.

Now, there are many many examples, if I had longer talk I'd show you, but I wanted to show you the last set of ideas here.

If we could just go to the video 2, please, in the back.

Ok.

So, return to Sketchpad here, and 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

⊕(time: 1:00:17)

Alan switched to a Croquet Image.

Here, I am in a 3D environment that we built called Croquet.

By the way, the if you are interested, the kids stuff that's found on the website:

squeakland.org, and this Croquet environment, this is all free software. 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 an interesting analogy to webpages.

So, each 3D world here is like a web page, and these portals are like a hyperlink to them.

I'm just going to pop Alice to enter this guy here.

I'm just going to do a 360.

this is a Mars environment.

All of these environments are buildable.

I'm just going to show 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 bridge.

So the first thing we want to look at is the little script for Mass's.

basically what we have here is F = ma.

Acceleration is the force divided by the mass.

The velocity is increasing by the acceleration. And,

the location of all the little elements on here is going to increase by the velocity.

I'm going to turn on the the force here to work.

Say, okay, let's do do that.

So this bridge structures is feeling gravity.

And, you can see it coming into equilibrium.

I could have made it stiffer but let's look at the springs.

The springs are fairly stiff:

K gets 1400 here, so what I'm going to, what I'm going to do here is to make it 400.

Tell it to go ahead that's going to let it sag quite a bit more.

Then, we all remember the Tacoma Narrows Bridge film.

So, of course, we have to have some wind.

Basically, what I'm going to do here is turn on a variable gusting wind that's completely described by this script here.

Okay, now it's going to do some Tacoma Narrows stuff.

I need sound. I noticed the sound wasn't working. Thank you.

Let's take a look at our bridge, and you know it's funny when you look at a model of steel, if you remember that Tacoma Narrows Bridge movie.

It was really like the bridge was made out of fabric of some kind.

This has this kind of same aspect and that gave us an interesting idea here.

I think a good way to end this talk is just to say that if we can't get kids interested in the romance, why this is unbelievably beautiful new art form, then,

we're not living up to what our duty is of enjoying the stuff ourselves.

We have to reach deeply inside of ourselves to remember what it was that first got us interested in this 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.

Thank you, Alan for a fantastic talk, and we have a token of our affection here.

As well that concludes our Turing Award lecture and you're welcome now to go get dinner, and then, afterwards at 8 o'clock, we'll be beginning the last thing on  this evenings agenda: the tenth  anniversary reunion.