Difference between revisions of "Rethinking Design, Risk, and Software (2012)"

Latest revision as of 18:49, 17 July 2018

1 Introduction by Joel Orr
2 Opening
3 What is Engineering?
4 How Empire State Building was designed and architected
5 A book on the Empire State Building
6 Engineering Bridges
7 "Can Software Engineering do anything like this?": Complexity of Software and Software Engineering
8 What is Science: With a hair ball standing in for Complexity
9 Science with Engineering by making an artifact and observing it
10 Computer Science, contrasted with Real Science and Engineering
11 Tactics vs. Strategies
12 Xerox ALTO in 1973
13 8 and half Inventions at Xerox PARC
14 Introduction to the STEPS project background
15 Principles of STEPS
16 The graphics engine of the STEPS project: Dan Amelang's Nile and Gezira
17 OMeta, Language Transformation Language
18 The working model of TCP/IP by Ian Piumarta
19 Particles and Fields Abstraction
20 Paragraph Justification with Rules
21 Coordinating Multiple Solvers
22 From Gears to Ecologies
23 Simulation of Space and Time
24 Scalability of Ecology and Psychology
25 Apple, Orange and Lemon
26 News and New

Introduction by Joel Orr

⊕(time: 0:06)

Joel Orr was Chief Visionary (Emeritus) at Cyon Research.

I'm Joel Orr. I'm welcoming you to COFES. I'm very glad that you're all here, and I have the impossible task of introducing Alan Kay this morning. Alan has been an idol of mine for many many years. And, when I asked him how to introduce him, he said, like a woman's skirt. And I said, huh, and he said short enough to be interesting. And really, I could spend the whole hour talking about Alan's contributions to the worlds of computing, education, and so much more. Please do look them up on the web.

There is no lack of adequate places to learn about the inventor of the laptop, the guy responsible for all kinds of wonderful networking things and language things.

So, with that let me not take any more time away from his keynote, and let me welcome my friend Alan Kay.

Opening

I tried to incorporate in this title the topic, central topic, of this symposium. And, I'm also using the words engineering and science.

I'm taking the larger sense of those terms. Larger sense of engineering, and larger sense of what science is. And, I want to apply it to our thoughts and needs about software.

Viewpoints Research Institute is a 501c3 nonprofit public benefit organization so so we don't have a product, we're not trying to sell you anything.

Brad invited me here to provide some alternative points of view on how we might think about software, and how we might make software because the time is going to be dire

I put my email address up there. I should put it at the end but I'll put it here so that if people have a question that didn't get answered while I'm here. I welcome email I like email.

I love it better than almost any other form of communication because I can decide when not to use it.

What is Engineering?

⊕(time: 0:2:56)

You all know what I mean. Okay, let's tackle engineering first.

One way of thinking about engineering is that in the world we're presented with situations. Here's a really nice beautiful one but it has a couple of drawbacks from practical human need that gives rise to an idea.

We design something we make a thing that caters to that.

And, if we don't extract principles from this thing, then we're not doing engineering yet we're just tinkering.

Tinkering is kind of the thing that is built in to many mammals. If you have a cat, imagine what a cat would be like if it had hands it would be basically a monkey. If you'd come home from vacation your house would be dismantled.

We want to extract principles we want to push them back into the things, so we start doing principles building of things.

Those principles leak back into how we design things, and they even leak back into how we have ideas.

This has been going along on a lot longer than mathematics and science.

In the twentieth century one of the ideas that gave rise to was a really really tall building done very quickly.

Here's what it looked like when they got done with it. And, I'm not going to spend a lot of time with this but when you talk about engineering, this is one of the three or four things that comes up, the Empire State Building.

How Empire State Building was designed and architected

⊕(time: 0:4:38)

Paul Starrett oversaw and managed the construction of the Empire State Building. See Paul Starrett on Wikipedia

here's an article in one of the engineering magazines that says planning control permit erection of 85 stories of steel in six months. It wasn't just 85 stories of steel, it was 85 stories of steel and granite.

Here's what it looked like. Here's the site after they demolished the old Waldorf Astoria Hotel, and then, Bing, Bing, Bing, Bing, Bing.

So they clad the thing as they went up and the entire building of the Empire State Building took less than 12 months and was done by about 3,000 people.

We could not muster 3,000 people to do something major in less than a year in computing. So, whatever we mean when we say software engineering, we don't mean real engineering.

We mean something that we're aspiring to. This is the way the term software engineering was intended back in the 60s at the Garmisch conference in 1968 where it was coined as an aspiration.

Today, if you go to a university or many companies and ask them what is software engineering, they'll say it's what we're doing. That is manifestly not the case.

There's some really interesting things. Anybody who aspires to being an engineer of any kind should be intimately familiar with how this was done.

A book on the Empire State Building

⊕(time: 0:6:8)

What's wonderful that there are many good books about it, including this facsimile of the Foreman's, notebook. One of the foremen, every night, typed on his pica typewriter, and took a picture and pasted it in there.

This has come down to us but we don't know who the foreman was. And, a few years ago it was a facsimile into a book that you can buy and are many interesting things are in there.

One of the questions that was asked the aspiring contractors was what tools do you have for this job.

One of them was Paul Starret who was one of two Starret brothers. They had built some very large buildings in Manhattan previously but they were one of three big companies bidding for this job.

They'd all said to this question, "well, we have all the tools we need in blah blah blah blah."

What Starrett said is not a blankety-blank thing, not even a pick and shovel.

"Gentlemen, this building of yours is going to present unusual problems. Ordinary building equipment won't be built worth a damn on. it will buy and make new stuff fitted for the job that's what we do on every big job. It costs less than renting secondhand stuff, and it's more efficient." Okay.

Now in software, a first order theory that's obtained as long as I've been in the field, which is 50 years, is that you should never build your own tools. It's a black hole. Don't build your own operating system. Don't build your own computer for god sakes .

Don't build your own programming languages. Get all this stuff from the vendors.

That way, you're actually going to speed up your ability to produce the thing that you want to do. It turns out this isn't true. Or, it's true, if you can't, if you don't know how to build your own tools.

You can certainly get into a black hole. We all know of them. But in fact the second-order theory is also true, which is, if you know how to build your own tools then you better, because you can bypass not just workarounds that you have to do but you bypass an entire set of perspectives that may have nothing whatsoever to do with what you're trying to do.

And, they might even be antagonistic to it.

So, these guys did a lot of wonderful things. This is a narrow gauge railway that was on every floor of the Empire State Building.

They also built twice as many elevators than there they are now just as temporary elevators, but going up 85 stories in order to move equipment around, and when they got the building up they took down these elevators.

Sounds ridiculous, right? Not really.

Engineering Bridges

⊕(time: 0:9:5)

Now, the other thing about engineering, real engineering that makes it rather different still from what we attempt to do in software is this problem.

This is the Tacoma Narrows Bridge. We have much of our infrastructure is crumbling.

Here's one that wasn't as funny as the Tacoma Narrows Bridge was funny because nobody got hurt.

It was predicted by a University of Washington professor.

The reason they got good movies of it is he said when a wind comes up that's over 55 miles an hour, this bridge is going down. So, when that wind came up, they went down to a now-famous camera store in Seattle, famous for supplying the movie cameras, which they then took out to the bridge, set them up.

⊕(time: 0:9:56)

You can see the movie on the Internet, for example, like this one: Narrows Bridge Collapse..

And, watch the thing shake itself apart.

this one though, in Minneapolis, was not so funny because many people got killed and a whole school bus full of children just missed getting demolished.

So there are many casualties on this.

The trace back on this one was: first they thought the rivets were substandard but they turned out to be right. They finally found out that those gusset plates, those square things that the rivets are joining those beams with.

By a clerical error where about .. 3/16 of an inch too thin. 20 years later that defect in the structural engineering plus the clerical error brought down the entire bridge.

The point here is that one of the reasons you can fly in a jet plane and not feel upset, if you knew what was going on in the jet engine that's right outside there,

and you should if you're aspire to be an engineer, you will know that inside that jet engine, there are temperatures that are higher than the melting point of any of the materials in the jet engine.

It's just one of those great things.

But jet engines run for thousands and thousands and thousands of hours. They're one of the most perfect engineering creations especially given the difficulties that they labor under.

They have to spin at 30,000 rpm. They have these temperature problems. They have enormous shear forces and everything else going on. they're just fantastic.

The thing that has allowed engineering to advance is that people get really pissed off when their friends and relatives wind up dying on some engineering failure.

So the forces of nature plus the social forces have conspired to make engineers rather careful.

Of course if you think about the parallel situation inside of a computer, the forces and the masses are slight.

Many software systems are starting a crash that will take 10 years to happen from this instant they are actually deployed.

They're completely buggy but the gusset plate is going to take a long time to gradually come apart as it gets more and more complicated.

When you move from something where doing something out in the world of forces and masses into a world where you don't have these, you have to have an artificial sense of discipline.

This is omething we are still learning how to do.

Now we don't know what happened to the Roman engineers who failed.

I've suspected, because their engineering was so good for its time, I've suspected that they actually wound up in the Colosseum for failures.

But consider this. This is the longest extant, it's not the longest Roman bridge ever made, but it's the longest one that we still have. With those light poles on it.

Becasue it's been continuous use for over 2,000 years, and has had cars running on it for the last century.

Now, if go look at this bridge it's in Merida, Spain, near the Portuguese border, it looks like it was built yesterday.

This is partly because the Romans created the best cement the world has ever known. It took a long time for us to find out, just really about 10-15 years ago, to find out exactly what the secrets were of the Roman cement.

⊕(time: 0:14:14)

Alcántara Bridge, also in Extremadura, Spain, [1].

How about this one. Same age. Again, if you walk right up to it, looks, holy smokes. This thing looks like it was built yesterday.

If ever been to, how many people have ever been to the Pantheon in Rome. She's been to Rome you've been to the Pantheon.

First time I went, I thought wow! You know, it looked like it was made out of granite, and then I found that it was made out of reinforced concrete. How many people, most people here might have found that out. Do you realize?

How many people realize it was made out of reinforced concrete?

It looks like it was made yesterday. You go around. It's just every, nothing is crumbled. Just Incredible.

If you really care about it, engineering goes from beyond a set of these principles to a true art form.

And, you could even go so far to say the big art form of the 20th century were science and engineering.

That's a lot to live up to for something that wants to call itself a science like computer science, and that wants to call itself an engineering discipline like software engineering.

Yeah, so the answer to this question is, "no". Software Engineering cannot do anything like this today.

"Can Software Engineering do anything like this?": Complexity of Software and Software Engineering

⊕(time: 0:15:32)

To make some comparisons here, I just note that a 400 page book has 20,000 lines of text in it.

Each one of those could be a line of code so 20,000 line program is one 400 page book.

And a foot of books is about 300,000 lines. Million lines of code per meter: there's an easy one to remember.

The Empire State Building is about 441 million lines of code high, as stacked books is 20,000 lines, 50 lines of code at a time stacked up.

That sounds like a lot. But in fact a lot of companies are wrestling with about this much code.

Personal computing, which I had something to do with a long time ago. Microsoft's essays into it provide operating systems over a hundred million lines of code and application suites is well over a hundred million lines of code.

You look at that, you think, "Are we really getting that much bang for a couple hundred million lines of code?"

I hope you're saying no. I hope you haven't gotten complacent about this.

So personal computing, 250, say 200 million lines of code. But of course it's not really that much. The problem is that when you make a lot of code, there's a point, where their dependencies are so intertwined, the engineering has been done so poorly, that people start becoming afraid to remove things.

So they just let it stay there and they start layering over it.

This big software company has now gone over 400 million lines of code.

I haven't changed the slide. Yeah, I used to use this analogy, because, I mean, a pyramid is kind of a garbage dump plastered over with limestone so it looks nice.

Just a big accretion. But when I look at this picture, I think I can't use that metaphor anymore because, look at how modular these pyramids are.

We would love to have that modularity in the code that we write. so I think the picture that fits our code better is a slum.

Particularly the web. But basically it's all rather slum like.

There is no large sense of architecture of any kind. Things are tacked in there.

Urban renewal bulldozers out some stuff but just leaves the stuff lying around, never carts it off and and so forth.

The real question is not whether we can improve on this.

But what is the actual level of improvement, which is tantamount to asking, how complex is the actual problems we're trying to solve compared to the complexity we're creating by just bumbling around.

What is Science: With a hair ball standing in for Complexity

⊕(time: 0:18:35)

Let's ask a question about what science is. Now that we've talked about engineering.

Real science looks at hairballs. This is my favorite hairball. It's about this big, recovered from the stomach of a woolly mammoth found in a glacier.

But because hair balls are ugly to look at but it got your attention, especially when I say how big it is.

It represents complications. But, you know, the universe is good enough.

The starry night it's pretty air but it's still complicated. People spent thousand of years misunderstanding it in a bunch of ways.

⊕(time: 0:19:17)

Scheffer Stroke is a logical operation of NAND, from which you can build any other operations, and logical structure. Stroke on Wikipedia.

We little creatures with our brains have languages. We can make all of our languages out of the Scheffer's stroke. Here, this is the NAND operator.

⊕(time: 0:19:29)

Oliver Heavyside cleaned up the formula to concisely describe Maxwell original idea. [2]

Because we have tiny little brains, we invented mathematics, and we come up with something like Maxwell's equations, or Heavyside's version of Maxwell's equation, and put a large part of the phenomena that we're looking at out there on a T-shirt.

This represents complexity, so the complexity of the electromagnetic field, in large amounts of it, enough to invent a radio and radar and etc. etc., can be represented by a couple of these equations.

These equations should be symmetrical because the magnetic field and the electric field are trade off against each other but aren't.

So, if you worry about that and you happen to be named Einstein, you will come up with the special theory of relativity which will put symmetry into the whole thing and you get down to two equations, just like you should have. One for the electric field and one for the magnetic field.

⊕(time: 0:20:35)

The notation is not science.

Now science is not this. The problem is when most people take science courses they're taught the T-shirt.

But science is actually that. Science is the realm of the relationship between the phenomena that we can't get to.

Science with Engineering by making an artifact and observing it

Similarly, we can do science with engineering, because it's an artifact that has phenomena so we can actually look at that bridge that we built there. Scientists can look at what engineers do and make a T-shirt of it.

We have T-shirts of what bridges are, their theories of bridges. Then, the cool thing, this is why it's great to be alive today, the cool thing is you can take that T-shirt and make one hell of a bridge.

Engineering was around for a long time but it didn't hit its stride until it had this beginning the yang here, event of making things and looking at them the special way that science does.

How big is this bridge? Well, See those little boats down there? Those are super tankers.

Just for comparison, there is our Empire State Building. So the pylons on this bridge are the height of the Empire Building. And, there's the Great Pyramid of Egypt.

⊕(time: 0:22:0)

Akashi Kaikyō Bridge. The longest suspension bridge in the world. Wikipedia.

This is the Asahi [Akashi] bridge in Japan. Just can't beat it. So lovely.

So, this is what we want to think about. We want to think about real engineering. We want to think about real science.

Computer Science, contrasted with Real Science and Engineering

⊕(time: 0:22:14)

Computer science is not real science. Ask anybody to give you a definition, and they will give you an engineering definition.

Part of it is because computer science persists in only building things. It doesn't spend a lot of time trying to understand them.

So, you can look, you know, computers We have built. There, you have their complicated artifacts. Programming languages is a complicated artifacts you can do the same thing.

⊕(time: 0:22:41)

What is on the T-shirt is Lisp semantics written in the form of an interpreter written in Lisp. The core of a language can fit on a T-Shirt.

John McCarthy looked at them, and being a mathematician, you want a G-shirt ["T-shirt"]. This is the programming language Lisp on the T-shirt.

Once you look at that you realize, whoops, programming is not as complicated as I thought. All the semantics I really care about are not in these in humongous Fortran or Java compilers but they are actually very small.

When I make them small enough for my tiny little brain I can actually think about to manipulate them.

Whereas trying to go over on the other side and mess around with Fortran directly to make it better, it just never happen.

⊕(time: 0:23:20)

Alan is showing the cell biology he studied and the Internet that inspired Smalltalk design.

So, John came up with a mathematical theory of computation. And, those of us who came in the next generation after McCarthy got to do some really fun things with this idea. I should mention that what I'm talking to you about actually happened in the 60s.

And, it bore some real fruits. But, in fact, it never made it into the world of the 60s which was dominated by IBM. Or, the world of the 80s and 90s which is dominated by Microsoft.

It just didn't happen. So most people program in a way that is strikingly similar to the way programming was done around 1965.

Tactics vs. Strategies

⊕(time: 0:24:5)

Let's take a look at the idea of tactics versus strategies.

The simplest thing when we have materials is to think tactically.

Have a bunch of these materials piles and stacks.

Simplest things we can get out of those hardly any design effort at all as pyramids and walls.

People did this with bricks for thousands of years before somebody had a strategic thought which is,

"hey, let's make something out of the bricks before we make the thing."

Let's make a new kind of building component a different kind of structural integrity than a pyramid does, and all of a sudden, we can kick ass.

⊕(time: 0:24:47)

With an arch, one can build as tall structure as a pyramid with much less material.

Took thousands of years to get beyond what the brick forced into our minds by being in front of us to this very odd thing that requires more building materials to make than when you're done. This is one of the hard things about an arch.

It's hard to imagine it because it doesn't work until it works: so people just ignored it.

The same thing happened in computing, where we build things out of NAND's.

Basically computing is all about comparing things. So you can take materials, like even two rulers, this is something that first graders love is they can do any fractional arithmetic problem their ten-year-old brother can't do.

They can do it in two seconds with two rulers. All right, because the ruler is an addition slide rule. You show this to a kid they'll love you for life

Just compute the whole thing out ahead of time, and say here's what it is, and by the way, you're teaching them vectors at the same time.

It beats regular fractions in many many ways. Of course the Romans and the Greeks. Romans had a socially accepted QWERTY form of numbers called Roman numerals.

But they didn't use them. most people use this in the wrong way. The Romans and the Greeks had abacuses to compute with. This is a Roman abacus and those stones are called calculi.

The calculus came from this notion of what they pull out of your teeth, also. When they you go to the dentist to get the plaque removed they call them calculi.

⊕(time: 0:26:29)

The couple of British are William Eccles and F. W. Jordan. Origin of Flip Flop on [3].

Flip-flops didn't come people wanted to do computers but because a couple of Brits wanted to see if they could make a memory that could do some of the things human memory could do out of materials.

Remember, vitalism was a big deal back then.

And ENIAC.

But the problem is matter is inconvenient for this. It's just, you know, basically the scaling problems overwhelm you very little return.

You need to go strategically.

⊕(time: 0:27:5)

Jacquard Loom was a powered device that was controlled by punch cards and produced textiles with complex patterns. Loom on Wikipedia. Alan refers to the fact that von Neumann style languages are following what the low-level machine instructions dictates, including ALGOL and Java shown on the slide.

Of course this was done a long time before with a Jacquard loom, von Neumann architectures, von Neumann style programming languages.

Even the programming languages of today like Java, which is also a von Neumann style language in spite of a few trappings it has on it.

Basically, the programming that we're doing today has not stirred from this in 50 years.

There have been about 3,000 different programming languages invented and some of them really useful.

But style of programming that is used today is almost entirely this style. It's style where the programming language is rather similar to the underlying storage mechanisms and control structures of the machine.

There are few convenience is there, but not a lot and not enough.

⊕(time: 0:27:59)

Sketchpad is the black and white picture with the light pen interface on the bottom row. [4].

But, of course there are always weird people out on the fringes, who, like Turing himself, who did things are completely different. For instance, Sketchpad, which is having its 50th anniversary this year, computed by, you programmed it by, putting in constraints that Sketchpad had to figure out.

So, instead of writing solutions to problems, you just gave Sketchpad what the problem, what the nature of the problem was, what the nature that would characterize a solution. Sketchpad had three problem solvers.

In 1962, it would solve those problems for you.

By the way, he also invented computer graphics while doing it, and also this is the first object-oriented system I know of.

Those three things were done by Ivan Sutherland as a thesis project in one year, one person. I once asked Ivan: "how could you do these three things in one year?" He says well I didn't know it was hard.

Ivan was a genius, but he had also had the advantage of just aiming for what we really needed.

He didn't worry about whether it was hard, because nobody knew what was easy and hard in 1962. He just went for what we needed, which is an interactive system, that, you could show sort of what you wanted then tell it what the criteria were to the job up and it finished the job up. Great.

Too bad we don't have it today.

The Internet, another thing which is almost completely ignored by computer people. Why?

Because it works too well. Most computer people, certainly most people in the world, but most computer people even don't think of this as technology.

It's completely different from the technology they're used to. The internet has never gone down started running in '69 but continuously, since then to replace all of its atoms and it's bits without ever being shut down.

People are shutting down their software systems all the time. They shut down individual servers, even though a server is just a name. You never have to do that.

What we've got is two cultures here. We got culture that was able to make something get scaled successfully by eveven orders of magnitude. We've got another culture, who, who can't even appreciate the feat of engineering and science that took it to do.

The Internet is really the only extant true object-oriented system in the world right now.

⊕(time: 0:30:32)

The brain image used to denote AI. In other talks the same image is used to explain how brain interprets the incoming signal and how itself synthesizes information.

Then, there's, of course, AI, which people have lost interest in, just as it was starting to get really well work done. We should be spending more time thinking about this.

Xerox ALTO in 1973

Now, one little blast from the past, 1973, we showed this machine and this system.

⊕(time: 0:30:56)

Alan refers to the idea that each graphical object on screen can be considered as a self-contained entity like an application, and the window border around them is optional. A document in DTP can be organized as an assortment of such graphical objects.

Notice, overlapping windows there, it was a view oriented object-oriented system, desktop publishing was essentially the views without the borders on them.

These got split up when they came out into the real world, but it's, in Xerox theory, one thing. There was no operating system, because you don't need one.

When Xerox asked us what we were we're doing, we gave them our own version of Paul Starrett's speech, not even a pick and shovel.

Part of the deal at Xerox PARC was we built every bit of the hardware and software ourselves from scratch.

We did not go out and buy commercial computers. We did not go out and buy commercial software.

The reason is this stuff was so different that we would have spent all of our time running into walls that were simply irrelevant to what we were trying to do.

The cool thing was this was a tiny machine: 128 K RAM, and we used half of it for the display. So, it had a display about 800 by 600.

all the software from the end-user down to the non-existent operating system, down to the metal of the machine, was only about 10,000 lines of code. It was done in a language we invented specifically for the purpose.

One way of thinking about this is, in the end, no matter what it is you think you're doing, math wins.

The thing that is math, the mathematization of an idea dominates all other things once you've done the spadework around the edges. At some point, you have to sit down and do something like mathematical thinking in order to collapse all the things that seem to be artificially dissimilar into things that are similar.

This is called making an algebra. This was a technique that we use pretty generally at PARC.

8 and half Inventions at Xerox PARC

⊕(time: 0:33:14)

Half of the Internet means that Xerox PARC had its own packet switching protocol called PUP, which influenced the design of TCP/IP.

In a few years, we did this: the bitmap screen, the GUI, WYSIWYG in desktop publishing, real objects, laser printers, Ethernet, peer-to-peer and client-server, and about a half of the Internet.

Now, what was interesting about that, perhaps, is it was only two dozen people.

Any company here could have afforded to do this. Two dozen people, just ten million dollars a year in today's dollars, you could do it right now.

You won't do it though. Nobody is doing it. you won't do it in spite of the fact that it returned 30 plus trillion bucks, returning about a trillion dollars a year still.

So, this is a huge win, but in fact, it is against what most people think is good practice.

I don't mean in computing only. I mean in management.

We'll leave that because we don't want to talk about the past too much.

Most people do not realize it was only two dozen people. That is only four to five years to do all this stuff, and doing it all from scratch.

Introduction to the STEPS project background

⊕(time: 0:34:38)

The picture, with two children (two of triplets) using the XO laptop, is a recreation of the drawing in the "Personal Computer for Children of All Ages" paper.

Now let's take a look at a science project in the present. Same idea here, so all of these ideas I've been talking about here.

We're going to apply them to this big thing called personal computing. It's got all kinds of stuff in it.

Again, we're interested in this area that goes from the end-user all the way down to the metal. so, there's a lot of stuff.

We want to know how many T-shirts does it take, right?

This is a completely different thing here. We are not interested.. we're doing science here.

We're going to have to do a little bit of engineering because the only way we can validate this science is by making it run.

But this is a science project. We want those T-shirts.

Principles of STEPS

⊕(time: 0:35:32)

Refer to some of the STEPS proposals and reports available at the VPRI site: Writings, including first year report.

So, let's take a look. Let's say half of what Microsoft, or Moore, has in there is just code they can't get rid of. But still, most of these, you know, Linux and OpenOffice and stuff: it's like a hundred million lines of code.

So, it's a lot of a lot of stuff of different kinds.

Now, here here we have, we're kind of behind the eight-ball of having a brief talk. This part, to do this part in a reasonable way, would take a couple of days.

I hate bullets. So please do not regard these as bullets. just look. They're ten blobs, out of twelve or thirteen blobs, that we used.

What they are are things, a couple of those we invented but, most of them were things that have been around for 50 years that didn't make it into the particulars design culture that computing is.

See, the difference here is nature helps physicists be honest, because in the end you're supposed to submit your theories back to nature. But the problem is we're a design field: so our trade is bullshit.

That's what design is. There's good and there's bad and there's different. A lot, a lot of stuff in between.

We can have a fad like, for instance, semaphores. Semaphores were known to be a bad idea when they were first invented by Dykstra and Hoare. But, in fact, in that culture, they took on, and for a variety of different reasons, they are still being taught today and they're still being used today.

Why are they a bad idea? anybody know? What's wrong with a semaphores?

A system lock up. there is no way to do something ahead of time that will tell you you won't get system lock up.

⊕(time: 0:37:44)

Simulation of Time is one of the principles. Alan refers to John McCarthy's Situation Calculus and the concept of fluents Calculus on Wikipedia and David Reed's work on distributed decision making [5].

So, this is like the world's worst idea to let the CPU control the time base of your computations. you're screwed.

May take a while, may happen quickly, but it's just basically a bad idea. There was already a good idea also thought up by John McCarthy in the early 60s that actually works and works much better.

But it's just not generally used, and it won't be used for a while, because these things take decades to get rid of things that are, you know, de facto religions.

The graphics engine of the STEPS project: Dan Amelang's Nile and Gezira

⊕(time: 0:38:20)

I'm just going to pick on a couple of these. I already talked about math wins, and I want to talk about this now in this area, up around in here, because one of the things we have to do in personal computing today is make anti-alias, 2 and 1/2 D computer graphics.

We have to make it look really good. If we didn't have it look really good, then we will be sloughing off part of making something that is like computer graphics that we can recognize today.

Of course whenever you have a hard problem you get a graduate student to do it, because they are just so much smarter than we are.

This is Dan Amelang, who's a graduate student at UC San Diego. A very good mathematician and computer guy. And even better, he has a mom.

Of course we all do, but his mom happens to be a high school geometry teacher of that special kind that actually understands math.

So, they do exist. He went home Thanksgiving three four years ago, and his mom said: "well, son, what are you doing at Viewpoints?" He said: "well, I need to reduce the amount of code to do computer graphics on a personal computer by a factor of a thousand.

She said: "Oh, that sounds interesting. What are you going to do?" In fact her expertise was in projective geometry. so, Dan did not come back from Thanksgiving. He stayed working with his mom.

he and his mom worked together on this thing through January, finally showed up in January with this formula.

⊕(time: 0:40:17)

To see more about Dan's work, check out the talk by him talk at UIUC by Dan (starts around 17:00 mark).

This is one of these serendipitous things that you can't completely supply by method. But this stuff has been kicked around by the best people in the world for forty five years. But in fact, they found a new way of thinking about the involvement of an arbitrary polygon with a pixel that computes exactly the right shade of the pixel to give you perfect anti-aliasing.

It's only that big. The next thing Dan did was to make a math a language out of the mathematics that looked like the mathematics, but could run on a computer.

When you tell these 45 lines of code to do it, they can do things like this. They can render anti-alias text and anti-aliased graphic objects. That was a great start.

This language that he devised, he decided to make it a dataflow language with kind of functional engines at the nodes. Because of that, it is highly amenable to automatic use of parallel resources.

⊕(time: 0:41:29)

Refer to some other talks for the live demo, until we manage to put the movie, or a real working system here.

Here's one of our benchmarks. This is 5000 anti-aliased translucent characters being re-rendered every time by these 45 lines of code.

So, there's no caching or anything here. We can take a look at the CPU usage. We can see that it's basically using..

This is a four-core Mac but the cores can handle two highly interleaved threads at once.

So you're seeing that one of those is being devoted to this task, and the fan has come on.

As I say go faster, it says "okay, give me another thread." There it is. What it's doing here is when I say up to four here, it's spacing them out, so they're each in different cores.

As I go faster and faster, it starts interleaving them. I can start zooming in. here so you can sort of see what's going on a little better.

You got enough monkeys.

We're actually quite surprised that... this is a lot of computing, but we're getting a lot of a lot out of it.

What I thought was, "wow, we should be able to make a whole system just out of this math."

This is in fact what I'm using. I'm not using PowerPoint here.

It's probably obvious by now, but. Here is this system that is this replacement for personal computing.

Here's my next slide.

⊕(time: 0:43:38)

The CompositeOver rule, which does the normal blending, is shown in the first oval, and compositing the star with gradient over the Frank character is shown as a result.

Here's Dan's brother, and here's all the compositing rules.

⊕(time: 0:43:41)

Likewise, there are three more examples of using different composition rules.

So for instance, this one is invert. Here's another combination rule here.

It's 95 lines to do all of the compositing rules that you use.

Now that you've seen. Of course there are those 45 lines. There's gradients, so I should actually...

⊕(time: 0:44:08)

The document editor is called Frank. Refer to the STEPS project reports and also a paper: and KSWorld: A Time-Aware and Mostly Declarative Language and Interactivev GUI Framework.

This user interface here is made out of the system also, because it's all one sort of one big desktop publishing document.

I'm going to.. The system is also live. This has not been compiled away into C code down there.

⊕(time: 0:44:26)

Alan pops out from the full screen mode by clicking the top right button, select a button widget for editing in the document editor, and change the gradient by manipulating mutli-stop gradient editor.

I'm actually going to pick an object here like this.

This menu here, and I'm going to say, "okay, let's change the gradient fill on this.

Yeah, something like that maybe. Or maybe we don't want as hard an edge so we'll zoom this out. Okay, get the idea?

So the whole system is live. It's using its own stuff here. We keep on chugging along.

We can see here's pen stroking, filtering.

All of the graphics for personal computing in this little science exercise came out to be four hundred and fifty seven lines of code.

How do we know it is 457? Because you can count 457 things, right?.

It's hard to count 400 thousands or 440 million or so on.

This is about a thousand times smaller than the way it is done, say, in Firefox. right?

So a thousand should get your attention, right? You have to learn a new language. On the other hand, here it is. The whole thing is just a few pages of code, and it's live, and you can run and use it. Okay.

OMeta, Language Transformation Language

⊕(time: 0:45:56)

The language Nothing was an experiment at VPRI to provide an intermediate system language. (This demo was not using Nothing.)

Where did this language come from? I have to build that.

So there's actually quite a distance between one of these compositing rules, a one-liner of code, and getting the result at the other end.

So I might need to remove the hood and show you what's there. This looks a little more daunting, because I have to translate this language into a standard form.

I have to translate this into another language that is sort of like C.

I have to translate to something that eventually will run on the x86 architecture that's on this machine.

That looks like a lot of work. And, of course, I run the system on multiple processors so I have to do that.

One way of thinking about it is, gee, it looks like there's a lot of work in these square boxes here and all.

We need another special language. We've just showed you a domain-specific language.

In the old days, they are called problem-oriented languages. I like old terminology because I'm old.

We need another problem-oriented language here, whose problem domain is transforming languages.

Of course, there are tools around for doing this.

But this is one of the big stoppers for people doing this themselves because making a language the way it is taught in school is a daunting procedures usually taught through some set of tools like Yacc.

This is not the way to do it. But the poor student comes out either not understanding it all, or convinced that it's too hard.

But in fact, you can make a much better language.

⊕(time: 0:47:41)

OMeta by Alex Warth is described in detail in his Ph.D thesis: with Programming Languages.

Here's one we did called OMeta. and here's a simple arithmetic expression, and here's the program. If I say do it, it transforms that expression into a tree.

If I come down here, and pick this more complicated expression up, and paste it in here and say do it.

I get that.

This translation system isn't just for translating things that have strings. It translates any kind of objects into any other kind of objects. So, You want to do it in that generality, because you're going to use this everywhere.

So, this graphical language winds up being 130 lines of code to make the trees, and another 700 lines of code to make the lower-level stuff that is actually run on the machine.

You could say a thousand lines of code, 900 lines of code to make that graphical language.

But, this is like a shaggy dog story, right? Because, well, now I have to make the language transforming language.

But of course, it can make itself.

Alex Warth did it particularly nicely, so it can make itself in 100 lines of code.

As you get closer and closer down to the bottom of the system, you start using these base things over and over again.

The problem-oriented language is staying on the top.

The working model of TCP/IP by Ian Piumarta

⊕(time: 0:49:14)

Refer to the year STEPS annual report.

Okay, but we have to do the internet. So, TCP/IP, 20,000 lines of C for that. So, one book, one of those books. This C code and most computers is a good nice job.

TCP/IP was invented by experts so we didn't expect to get a factor of thousand on this.

Ian Piumarta only got a little more than a factor of a hundred.

TCP/IP is about 160 lines of code using these techniques. If you're interested, I can explain...

This is particularly elegant the way he did it I'll explain it later for people who are interested.

This represents taking something it was done by very good people, but in the wrong language, and done essentially in a way that generated unnecessary code.

The big key here was not so much the language as the method.

The method came first, and then we did the language to do it so the whole thing collapses down.

Okay.

Particles and Fields Abstraction

⊕(time: 0:50:26)

The dynamic content here is to be filled in.

Let's take another one of these metaphors: particles and fields. Everybody understands this as a kind of a metaphor for iron filings in a magnetic field. The iron filings seem to know what to do. They're feeling this field and they're doing individual things that look like they're somewhat coordinated.

In fact, there are animals that do this also like ants.

Here's a little ant simulation. This is their nest. These guys are the food. And, if we start this thing going, then we see that the ants are finding the food, going to the nest and they're leaving this pheromone trail.

This is using about eleven thousand parallel processes, because each little cell is being used to diffuse the perfume the ants lay down. You see, right now, all of the ants have been captured by the field even they're not communicating directly with each other they're communicating indirectly with each other.

We would call this loose coupling.

Paragraph Justification with Rules

Well, if you have crazy brains, you could imagine that a paragraph of text is one of those things.

Who said you could do the encyclopedia over here?

We're not going to do the encyclopedia but we're just going to say: "hey, we should be able to organizae these little ants to do a paragraph.

The simplest thing that you can get fifth graders to figure out is.. Well, when you have to do something, follow the guy who is in front of you, and if there's nobody in front of you go to the upper left-hand corner.

If you find yourself over the the right-hand margin, tell the guy in front of you, and eventually somebody will know what to do, like go to the next line, right?

Let's just say go do this.

I just gave you like a three line formatter, right?

So, this is math. I'm going to set it off again.

And, I'm going to point out that I can edit this. Let's let it.

I can turn general here into justify.

And, it's just redoing this over and over again. All right.

The editor is actually working

Now, another way to do it, a little faster, is to say: "hey, don't follow the leader here because this is just for the crowd".

When it's time to do your thing, wait until the guy in front of you gets to the right place, and then go right behind him.

This is called jump, and here's what that looks like.

Now, they're all standing still. Okay.

If I start jump here, and I just say now do this in between frame times.

Bonk

okay, so all of the editing here is done like this.

In fact, this is another one of the documents in this universal document system.

Remember, we have to do Microsoft Office here.

But, why would anybody in the right mind give you seven applications that all do almost the same thing but not quite.

Well, the answer is simple, because amazingly people will put up with this silliness enough to buy it from them, and thus encourage them further.

This is nonsense.

Really, what you want is a universal document in just different ways. You really don't need to have a different system for the World Wide Web, do you?

No, because it's just a different way of accessing these multimedia Docs.

This is actually how we write code. This is an explanation to somebody like you to show in a little essay how the how the code actually works.

We start off here, and say: "okay, the first thing we want to do is just get these guys out there randomly."

These two lines of these two little boxes of code do this. And, here's one that just does this without worrying about the next line.

Here are some special cases.

This is a reminiscent of the way Knuth sometimes likes to program.

You actually learn the thing while you're looking at it. You can do little experiments.

By the time you've done that, bingo, you've got the thing.

Here, this is a yet another problem-oriented language, but with rules this time. So rule based.

Seven rules for doing the layout.

The whole editor, like Microsoft Word. Paragraphs is 35 rules, okay.

So, that's all you have to do for that.

Coordinating Multiple Solvers

⊕(time: 0:56:13)

Refer to Hesam Samimi and Alan Borning work on Writings page.

Here is another area. A thing that's very useful to have is problem-solvers.

But the problem with problem solvers and these problem-oriented languages, they're [also] problem solvers, they aren't integrated.

So, you wind up with a hodgepodge of different things serving different things, and you want to be able to integrate them.

Here, we can have a simplex solver, differential equations, propagation, dynamic programming, relaxing, the rules for the paragraph. These all have different problem domains.

What we want to do is to approach them strategically, as I've been talking about here, through general relational languages that talk to, or a kind of a little operating system for solvers, and often with the help of an expert system that helps make a strategy for using these things.

The further stuff here is beyond the scope of this short talk, so I'll just move on here.

From Gears to Ecologies

⊕(time: 0:57:14)

Okay, here's an important idea. Too many ideas in this talk, right?

Here's something that happened in the 60s except nobody noticed it except maybe the ARPA researchers, and the outgrowth of that to Xerox PARC.

That is, that the entire paradigm of computing, because of Moore's law, was going to be able to shift from a gear like way of doing things, basically tight coupling, brittle code, to something more like ecology, something more biological.

We use these ideas very strongly in the invention of the Internet, and in the invention of the object-oriented techniques that we used for software at Xerox PARC.

The deal here is you can fix a clock, but you can only make clocks of a certain size. Maybe a thousand gears before they just crash.

This is what happens in today's programming.

You have to negotiate with the system. A lot of what growing the old world into this new world is learning what it means to do this kind of negotiation, as you add more system elements.

The next little thing is just a couple of minutes of gloss, because I'm getting close to the end here. But I wanted to say something about systems.

Simulation of Space and Time

⊕(time: "0"58:38")

David Reed's work on distributed decision making [6]. and Gerald Popek's Locus: [7].

Three of the ideas here are that we want to control time. I mentioned this a little bit before. We do not want to CPU to control time first.

We control time, and we'll do it by simulating our own time.

We don't want to have any preferred center. We want to have something like the Internet all the way down.

We want loose coupling. Now of course, this has all been done before, again with networks.

Here now, we're looking at physical computers on the Internet or Ethernet.

Ideally, we'd like our computations to be software versions of these hardware networks. Why?

Because in most cases we will need to do load balancing.

Sometimes we'll be able to run all of these guys on a single machine, in which case we just have increased integrity and ability to design quickly. But a lot of the time, especially now with mobile, we want to have the same computations able to drift around the network to different kinds of devices.

In some cases, not all of the computation is going to want to be in the machine that is next to the user interface. If you think of the user interface here, it's basically a set of views of processes that are giving it images to integrate up on the surface.

Here's a great thing if you're interested. Dave Reed's 1978 Ph. D thesis at MIT. The design of an operating system for the Internet was never done, but we validated it a few years ago at Viewpoints.

What if you want to make a system that is the size of the Internet that is a software system. What is it that you have to do to absolutely ensure that you're going to have what people like to call data integrity always.

So that no matter where you ask a question anywhere on the network about anything anywhere on the network, you will get the same answer for the pseudo time referent of that question.

A working version of a migratory system was done by Jerry Popek. I put this up here because this book was written in the 80s, you can still get it from MIT press.

The Locus distributed system architecture. You'll find the entire book interesting. It just a thin little volume. The first two chapters are a classic still of the issues you have to think about and solve in order to do this.

Again, this has all been done. This is almost 30 years old now, but nobody uses it.

but if you were to use it, all applications are now just mashups, right?

We don't want applications as smoke stacks, because we want to integrate. We didn't have appications at Xerox PARC, and we did not have operating systems.

The current web which is getting more and more complicated can immediately get simple except for all the legacy stuff that has been done so far.

Scalability of Ecology and Psychology

⊕(time: 1:01:56)

The books shown are Ecology: From Individuals to Ecosystems [8] and the Society of Mind.

Here's something that Viewpoints has on its list but we expect not to be able to solve this, at least in this path of doing things. it, may be beyond, may require a much larger effort than a small nonprofit can do.

But if you think about analogies to what's happening with the scaling that's going on here. It basically starts looking like a biological ecology.

These have their own dynamics and they need to be thought about in special ways.

The ability for us to scale to what Moore's law is allowing right now is going to require us to start thinking more and more like this

We did this to some extent when we did the Internet.

Like, I have a degree in molecular biology in my misspent youth.

A lot of the ways I think about this stuff is through tissue biology and how the hundred trillion cells in our body work without having a dedicated center and so forth.

But in computing, we have problems of our own that are special. Then, the next step beyond this, the best book I've ever seen about it is Minsky's Society of Mind book, which is actually about a model for human psychology.

But in fact, it is a very good model for what the Internet is going to turn into. Okay.

Apple, Orange and Lemon

⊕(time: 1:03:26)

Apple is Apple, and orange refers to the theme color of Ubuntu as a stand in for the Linux Operating System.

So the punchline here, we've got three main operating systems.

I won't say which one is the lemon.

Down on the bottom here, our little Frankenstein monster that we made is that I've been showing you today is less than 20,000 lines of code.

So it's worth pondering.

We are not using any of the Macintosh software in order to do this demo.

Here's just to kick off, I think I'll just show this slide and then quit.

I organized the talk so I can stop now at any place and I need to in about a minute.

I'll just leave this one thought with you. Maybe we can have a few questions.

Then, maybe more will happen. I think there's a smaller group question session coming up later.

News and New

⊕(time: 1:04:23)

A recurring theme on learning that Alan mentions in various ways over the decades.

Let's think about this idea. Something appears and we've got two things about it. That are very different. There's news and new.

News is the stuff that is incremental to the categories that we already know. Almost every bit of news is a specific parameter into some category that we already understand.

It's this war, that killing, this marriage, that hem size, right?

You can get a quite a bit of this out in a few minutes.

There's almost no context to news that it's not already inside of our own head.

New on the other hand, real new. not news.

Real new is invisible. We don't have a category. McLuhan said until I believe it I can't see it.

That is the way it works in the human nervous system.

News is something that's been going on for the entire existence of the human race about two hundred thousand years.

It's basically campfires, and this is what we're doing right now.

This is a campfire. I'm doing the best I can do in an hour of telling stories in a campfire.

The problem is new can take two to five years to get the new categories that you need in order to actually see it.

One of the unfortunate things that happens is that new when you try to talk about it, and people make an effort on it, they usually transform it back into news.

For instance, we did this as a way of boosting mankind.

It was all about learning by doing.

But in fact, almost everybody in the world uses it only as a consumable device for their own convenience.

I would spend thousand five hundred dollars, which is the price of an average American car, for a laptop. if I could, because I know what computers are good for.

But in fact, people only value them as as much as they value their television sets. And, they use them roughly the way they use their television sets. The big problem whenever something new comes along, like personal computing and the internet, is that people when they see a convenience to themselves, they recast it back to the forms that they know about.

For instance, object-oriented programming never made it outside of Xerox PARC. Only the term did.

We got designer jeans, but designer jeans are just dungarees with a fancy label on them. Thank you.