Rethinking Design, Risk, and Software (2012)

Introduction by Joel Orr

⊕(time: 0:06)

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

I'm Joel Orr.

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 Hey

okay

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.

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

⊕(time: 2:59)

The first slide.

• Human-bridge.png

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.

So, 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.

And so, this has been going along on a lot longer than mathematics and science.

And, 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.

So, 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.

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.

(Paul Starr) 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.

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

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

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.

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.

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.

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.

Because we have tiny little brains, we invented mathematics, and we come up with something like Maxwell's equations, or heavy sides 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.

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./subtitle> <subtitle id="0:20:53"> 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.

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

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.

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.

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.

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./subtitle> <subtitle id="0:25:35"> 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.

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.

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.

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.

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

Then, there's, of course, AI, which people have lost interest in, just as it was starting to get really well work done.

So, we should be spending more time thinking about about this. Now, one little blast from the past, 1973, we showed this machine and this system. <subtitle id="0:30:56"> 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.

okay, so 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.

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.

But, I just, 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.

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.

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.

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.

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./subtitle> <subtitle id="0:38:41"> 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.

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.

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.

Here's Dan's brother, and here's all the compositing 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...

Now, 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.

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.

Now, of course, 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.

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.

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.

big key here was not so much the language

as the method

the method came first and then we did the language

too to do it and so the whole thing collapses down

okay

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 and in fact there

are animals that do this also like ants

so here's a little ant simulation

this is their nest these guys are

their 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 so 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

they're not communicating directly with each other they're communicating

in directly with each other and we would call this

loose coupling well

if you have crazy brains you

could imagine that a paragraph of text

is one of those things

who's who said you could do the encyclopedia

over here thank you

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 and 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 so

let's just say go do this

so I just gave you like a three

line formatter

right so this is bath

I'm going to set it off again

and I'm going

to point out that I can edit this let's let it

so I can turn general here into

justify

and it's

just redoing this over and over again all

right so the editor is actually working

faster is to say hey don't follow the leader here because this is just for the crowd

when it's time to

wait until the guy in front of you gets to the right place

and then go right behind him so this

is called jump and here's what that looks like now

they're all standing still

okay

and so if I start jump here and I just say now do this in between frame times

bunk

okay so

all of the editing here is done like this and

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 really don't

a different system for the World Wide Web do

you know because it's just a different way of accessing

these multimedia Docs so

this is a this is actually how we write code so

this is an explanation to somebody

like you to

show in a

little essay how the how the code actually how

the code actually works so

we start off here and

thing we want to do is just get these guys

out there randomly

so these two lines of these two little boxes of

code do this and here's

one that just does this without the worrying

about the next line

and here

are some special cases

so

this is a reminiscent of the way Knuth sometimes

likes to program so

you actually learn the thing while you're while

you're looking at it you can do little experiments and

by the time you've done that bingo

you've got the thing

and so here the this

is a yet another problem oriented language but with

rules this time so rule base

so two seven rules for doing the layout

and

the whole editor

like microsoft word paragraphs

is 35 rules

okay so that's all you have

to do for that

's very useful to have is problem-solvers

but the problem with problem solvers and

these these problem oriented languages they're 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 so

so here are we can have a simplex solver

differential equations propagation dynamic programming

relaxing the rules for

the paragraph these all have different problem domains

and what we want to do is to approach

strategically as I've been talking about here through

general relational languages that

talk to 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

okay

here's an important idea too

many ideas in this talk right but

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 and 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 a

brittle code to something

more like ecology something more biological and

we use these ideas very strongly in

the invention of the internet and in the invention

object-oriented techniques that we used for software at

Xerox PARC and the deal here is

you can fix a clock but you can only make clocks of a

certain size maybe a thousand gears B for the

dis class this is what happens in today's programming

you have to negotiate with the system and

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 so

the

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 and

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 so we want to have something like the internet

all the way down and we want loose coupling

now of course this has all been done before again

with networks and

here's here now we're looking at physical computers on the

internet or Ethernet and 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

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

and in some cases not all of the computation

is going to want to be in the machine that is next

to the user interface so 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 so

here's a great thing if you're interested Dave reads

1978 PhD thesis at

MIT the design of

an operating system for the internet was

never never done but we validated it a

viewpoints so this

is what if you want to make a system that is the size of the internet

hat is a software system what is it that you have to

do to absolutely ensure that

your going to be that your 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 and

a working version of a

migratory system was done by Jerry

Popek I put this up here because this

written in the 80s you can still get it from MIT press

the locusts distributed system architecture you'll

find the entire book interesting just a

little volume but the first two chapters are a classic

still of the issues you have to

think about and solve in order to do this but

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 so we didn't have

at Xerox PARC and we did not have operating systems

and 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 so

here's something that viewpoints has

on its list but it's we

expect not to be able to solve this at least in

this path of doing things and 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

and these have their own dynamics

and they need to be thought about in special ways

so the ability for us

to scale to what Moore's law

allowing right now is going to require us to start thinking more and

this and we did this to some extent when we did the internet

like I have a degree in molecular biology in my

misspent youth and so

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 our own that are special then the next step

beyond this the best book I've ever seen about it is

Minsky 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

so the punchline here we've got three main operating systems

I won't say which one is the lemon and

down

on the bottom here our little

Frankenstein monster that we made is that I shall

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

and

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

but I'll just leave this one thought

with you maybe we can have a few questions and then

maybe more will happen I think there's

a smaller group question session

coming up later but

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

so it's this war that killing

this marriage

that hems is that

right and you can get a quite a bit

of this out in a few minutes

so 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 and

so 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

but the problem is new

can take two to five years

to get the new categories

that you need in order to actually see it and one

of the unfortunate things that happens is that

new when you try to talk about it and people make

on it they usually transform it

back into news so 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 so 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

the forms that they know about so 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