Seibel Peter. Coders at Work

Подождите немного. Документ загружается.

Dan Ingalls

375

Ingalls: Right, in the radio science department at Stanford, which was part

of double E.

Seibel: So the program you made a business out of—what was it?

Ingalls: Well, it started out with Knuth, as a part of a seminar I took. The

seminar was to measure programs and look at their dynamic behavior.

Seibel: Meaning, profiling?

Ingalls: Yeah. So there was a program that would gobble up a Fortran

program and insert counters at every branch point. I made a fancier version

of it that also had a timer-interrupt process so that it would keep track of

how much real time was spent in various parts of the program.

Seibel: So basically a sampling profiler?

Ingalls: Right. And what was notable about these was that until that time

profiling had typically been in terms of memory locations, and it took a

quantum mechanic to know what the results were telling you, whereas this

came out in terms of your source code and you could see, “Oh, it’s

spending all its time here.” This was immediately usable to the user. I

recognized, “Whoa! people could be using this.”

Seibel: So you ran your business for a while—is that what you were doing

up until you went to Xerox PARC?

Ingalls: Pretty much. In fact, that’s how I ended up at PARC. I wound up

spending a bunch of time in local service bureaus. There was a Control Data

one and an IBM one. And I would take my program around to these various

places and make sure that it ran on their particular computer.

Seibel: And this was profiling Fortran code still?

Ingalls: Yeah. But I found out an interesting thing. Who were the big

Fortran users? They’re big scientific computation users. And who are they

all working for? They’re all working for the government. Do they care how

efficient their program is? Not really. What they really want to do is to

show that the computer is overloaded and that they need a new computer

Download at Boykma.Com

Dan Ingalls

376

and more money. I showed this at a couple of companies and they said,

“Jeez, if you had this for COBOL it would be great.”

Seibel: Because no one’s going to give them more money to buy big iron

for COBOL.

Ingalls: Exactly. So I wrote the same thing for COBOL. This was my

immersion into COBOL. I remember writing the completion routine that

would put together the statistics from the timer interrupts. The completion

routine wanted to be written in the same language as the thing you’re

measuring so that it could all be loaded in together. I may be the only

person who’s ever written a hash table in COBOL.

Anyway, that sold great. I can remember several sales calls where I’d go out

and as a demo I’d run it on one of their programs and, in the course of the

demo, would show them how to save more money than the program cost.

In the process of going around to these service bureaus, I wound up at the

CDC service bureau in Stanford industrial park—typically you’re working

late at night because that’s when it was less expensive—there was another

guy there who had a Fortran program to do speech recognition. He had

various speech samples and his program analyzed the spectra and grouped

the phonemes and stuff like that. I started talking to him and I said, “Well,

jeez, you want to run my program on yours?” So we did that and parted

company.

He called me up a couple of weeks later and said, “I’ve been hired by Xerox

to do a speech-recognition project and I’ve got no one to help me with the

nitty-gritty; would you like to work with me?” So I started consulting with

him. That was George White, who went on for a long time to do speech

recognition. That’s how I got in with Xerox and also with Alan Kay, because

it turned out that my office was across the hall from Alan’s and I kept

hearing conversations that I was more interested in than speech

recognition.

Seibel: Was the domain of speech recognition not that interesting or was it

something about the programming involved?

Download at Boykma.Com

Dan Ingalls

377

Ingalls: Oh, it was interesting—it was fascinating. I ended up building up a

whole personal-computing environment on this Sigma 3 minicomputer. It

used card decks and Fortran was the main thing I had to work with. Out of

that I built an interactive environment. I wrote a text editor in Fortran and

then something so we could start submitting stuff remotely from a terminal.

It wound up being a nice little computing environment, just done in this sort

of strange way.

Seibel: This desire for an interactive environment is a theme that’s come

up a bunch of times in your career. For example, you wrote the first

Smalltalk in BASIC because that was the interactive environment you had at

hand. Where did you get that idea that given a problem to solve, the first

thing you need is an interactive programming environment?

Ingalls: That’s a good question. I think anything where you get immediate

gratification feeds on itself by definition.

Seibel: So what was that first place that you had that immediate

gratification?

Ingalls: There were a couple of experiences. I had a chance to work with a

semi-interactive PL/I. And a friend of mine was working at an IBM where

they had an interactive APL environment. I can’t remember which of those

was first. I really remember the APL one. That affected me in a number of

ways because of both the immediacy of interaction—seeing your results

come back—and the expression evaluation, which is really different from

Fortran’s statement-oriented programming.

You still see that now, it’s amazing—the whole C/C++/Java tradition,

although it goes in an object-oriented direction, is still statement-oriented.

But if it’s convenient to make expressions, it really makes the experience

different. To me it brings the mathematics to life more. Anyway, it was one

of those two. When I got to Xerox there wasn’t much interactive except

the Lisp guys’ stuff. I happened not to be into Lisp. Things would have been

different if I were, I expect.

Seibel: How so?

Download at Boykma.Com

Dan Ingalls

378

Ingalls: I think I would have gone completely in that direction. And by not

having gone in that direction, it left me wanting to do that kind of thing in a

different way. I think what I worked on with Alan had that same kind of

nice, lively, expression feel, but it included the notion of objects and

messages more naturally.

I think if I had been as comfortable in a system like Lisp, I never would have

bothered. I would have tried working around it to get objects, but starting

with the notions of objects from the get-go and then making that nice and

interactive and convenient was, I think, a contribution.

Seibel: Alan Kay has said that both Lisp and Smalltalk have the problem

that they’re so good they eat their children. If you had known Lisp, then

Smalltalk would have been the first eaten child.

Ingalls: Maybe so.

Seibel: So that’s a nice example of the advantage of some ignorance; it

leaves some room for creativity. But sometimes it feels like ignorance is

endemic in this industry—that people are unaware of things and wheels are

constantly being reinvented with pointy corners.

Ingalls: That’s true.

Seibel: Should we be trying to fix that? Is it just a price that we have to pay

so that people can have room for creativity? Or would we be better off if

people were a little more aware of what else is going on?

Ingalls: I’m an embrace-diversity guy. The example we just went through, I

think, says, “No, let people go whatever way they want.” There will be

waste from ignorance, but natural selection will take care of straightening

things out. And you will get these occasional sports that take you into the

future.

I can think of lots of areas where trying to standardize, trying to all go in

one direction, has suppressed creativity. I work at a company that’s

supported by Java, so I’m not going to go very far with this, but it is the case

that when Java came out—the easiest way I had of measuring it was looking

at what went on at OOPSLA—when Java came out not only did work slow

Download at Boykma.Com

Dan Ingalls

379

down and even maybe come to a halt on other object-oriented

programming languages but even in dynamic programming in general. I think

that was a loss.

But it wasn’t permanent. People finally realized “Oh, wait a minute, Java has

all these great strengths and we’re using it for this and that but we were on

to other good things with dynamic programming languages and it’s time to

get back to that.” But that’s an example that’s easy for me to see because

I’m involved in it.

In a much bigger sense I hate to see computer-science departments that feel

their role is to prepare people to work in an industry and the industry is

going that way and therefore we have to teach our students that way. It’s

exactly the wrong thing to do. What you should be doing with your

students is teaching them to think generally—think outside the box and plot

the other courses we should be pursuing.

It’s not a simple problem because there is great value to having that whole

standard out there. Having thousands of programmers who have worked on

thousands of routines and they’re very solid—you can get your work done

that way.

It’s a little bit the difference between computer science in the service of

production and computer science in the service of moving the intellectual

content forward. I’ve been having fun with the Lively Kernel, which is, in a

way, trivial. There’s nothing new about it—I’m using all stuff that was there

before. It’s built on JavaScript and the graphics you can get in a browser. But

it’s been really fun because it’s another kernel like Squeak. Because

JavaScript is all there in the browser and the graphics is all there in the

browser, the work on the kernel is very tiny. It’s just, how do you bring the

graphics to life and how do you build up a little computing environment.

Whenever you do something like that, small enough, then anybody can

understand it. If you take a few things out of the equation, like the language

and the graphics, then the question is, what is the kernel? And I think that’s

an interesting question.

I’m hoping that this—not particularly my stuff—but this kind of investigation

might reinspire computer science to do some studies about how do you

Download at Boykma.Com

Dan Ingalls

380

make a kernel, what other kernels could we build that are even simpler,

even more uniform.

It’s like what math did. Math found by symbolizing things that you could

simplify a lot of stuff. Then, because of that, you could start to think about

bigger constructs. That’s my hope.

Seibel: When you say a kernel, you’re talking about a programming kernel.

What’s the core of the Lively Kernel?

Ingalls: What I mean by a kernel, typically, is you put together enough stuff

that it can, in some sense, build itself or build other useful things. Squeak is

one that really can build itself. The Lively Kernel presumes the existence of

JavaScript and some graphics, but it ends up with the ability to edit the

graphics so that you can make new graphical things and to edit the programs

so you can make new programs. So it’s enough to build all the applications

that you might want to build in a browser.

I think in playing this game you get to hide layers that you want to. The

question is, where is your playing field. In Squeak the whole language is part

of the kernel so it’s got its own compiler and byte-code interpreter. And it’s

got its whole graphics system—it’s got BitBlt and all the stuff around that.

It looks like those are an important part of any kernel but you can take

them out. You can say, “Let’s assume that we have a dynamic language; let’s

assume that we have graphics.” In my old thinking, I would have thought,

“Well, there is nothing else.” But it’s not true. What’s left is, how do you

put the graphics together to make an interesting user interface

environment? And how do you bring programs and scripts up to the level

that you can change them?

I was forced, by trying to come up with something that would run without

installation, in a browser, to take what was in the browser. What’s in the

browser? Well, we’ve got JavaScript and we’ve got a graphics environment.

It was a chance to step back from all this and say, “Well, yes there are

language kernels, there are graphics kernels, and then there’s this other kind

of self-supporting user-interface environment kernel.”

Download at Boykma.Com

Dan Ingalls

381

Seibel: In both Lively Kernel and Squeak, from the little that I’ve played

with them, part of that kernel that’s not the language or the graphics is this

notion of a UI that’s always programmable—it’s got these little handles and

so forth that you can do programmatic things with.

Ingalls: Right.

Seibel: I found that pretty confusing. Am I programming? Am I using this

application? Sometimes I wished there were a bit more of a distinction.

Ingalls: Yup. This is another of those double-edged swords. I don’t think

there’s a simple answer. At the very bottom, it’s a wonderful thing that

we’ve built computers that totally allow for change. It’s all random-access

memory; it’s all programmable. To me it’s important to keep that liveliness,

that malleability, that changeability. If you have a system that’s dynamic and

changeable, it’s much easier to then draw boundaries and say, “You can’t

change stuff inside of here” than it is to start out with something that’s not

dynamic and changeable and then try to make it that way.

If you look at web programming right now, it started out with this text-

markup language and then JavaScript came into the picture to try and make

it dynamic. It would have been so much easier to start out with something

that was like the dynamic graphics everyone knew about in those days and

then make stuff fixed and printable when you needed to.

Seibel: Well, easier for everybody except someone who just wanted to put

some text on the Web.

Ingalls: I suppose that’s true. But it’s easier for someone to put a layer, like

HTML, on top of that. I think it’s better to have the underlying systems be

as dynamic as possible. Then you can put on syntax or type restrictions, or

this, that, and the other that make it into a fixed thing. Absolutely there are

situations when people are just using a system—you want things to be fixed

that don’t need to be flexible. And yes it does seem that if people perceive

that it’s flexible, it’s scary to them. If you take the Lively Kernel as it is right

now, it’s not at all something that an end user would want. Nobody wants

to suddenly see their window tilted at 20 degrees.

Seibel: Or to inspect the code of the button they’re trying to press.

Download at Boykma.Com

Dan Ingalls

382

Ingalls: Right, right. Really it’s a demo to try to inspire people who want to

go that direction. It’s also very simple so somebody could put in a layer that

would make it usable and not changeable in those various weird ways. But

yeah, there’s a real trade-off between having things be flexible and general

and having things be codified and able to be used as a cookbook and always

do what you expect.

Seibel: Do you really think the current Lively Kernel, or some near-term

evolution of it, will become a way people are going to build apps, or is this

really a thought experiment out of Sun Labs to show people a way of

thinking?

Ingalls: Well, it’s definitely a thought experiment. It offers a couple of

sweet spots that might actually survive as real products in some sense. It’s

got the ability to very quickly do something like, if you wanted to make a

red heart and put a message in it and make it throb, and then store that as a

web page, you can do all that from within it, never having installed any

software. So you get the Lively Kernel and you build this little dynamic thing

with a little bit of scripting in it and it’s got the WebDAV protocol to go out

and create and store a new web page.

That’s something that’s simple and useful and if the scripting were equally

simple, the way the tile scripting is in eToys, I think that a lot of people

could have fun playing with that. So that’s sort of a gimmick. But if you take

that about two levels more, you’re into stuff that’s actually educational—

you could build simple dynamic models that you could interact with. It’s a

lot like Flash but it’s simpler and more integrated with programming.

From there, I just think of it as being possibly a nice environment for

embedding lots of little dynamic, educational examples. A decade or two

ago there was HyperCard and lots of teachers were able to understand that

and do useful things in it. It’s really strange that that whole experience didn’t

naturally go right into the Web. I think there’s still a role to be filled there

with tools as simple as HyperCard and as immediate as the Web. It would

be cool if it went that way.

Seibel: You’ve famously been involved in five or seven or however many

generations of Smalltalk implementations. Let’s start with the first Smalltalk

Download at Boykma.Com

Dan Ingalls

383

that you did in BASIC. You had a couple pages of notes from Alan Kay that

you had to make real. What did you do?

Ingalls: I just started typing in code. I think the first thing was to validate

the execution model. There were just a couple of basic structures that were

needed, the equivalent of a stack frame. So I just made, it must have been an

array, in BASIC, to do that and put together enough that would execute a

piece of code.

Typically with something like that—the word that’s coming to mind is you

“breadboard” it—you just do what you need to do to put a structure in

place that’s the structure you think you’re going to want to interpret and

then try to make it work. I remember the first thing we got to run was six

factorial. It’s a really simple example but it involves the process of dynamic

lookup and creating new stack frames. And then once you’ve got that

working, you come to understand how things are going to go and you find

out what’s difficult.

Eventually you figure out where the time’s going and so you improve all

those things. Then, in this particular case, once that worked there was the

problem of putting a layer on it which is essentially a parser so you can type

text into it and get it to go into that structure that you breadboarded. Then

you’ve got a little environment and you start learning things.

Then you say, “OK, I see how this works, I’m going to write it in assembly

code,” or whatever else. Then you suddenly realize, “Oh, yeah, we need

automatic storage management. So how are we going to do that?” It’s one

thing after another.

Seibel: So have there ever been things where that sort of just-in-time

development either failed to work, or you knew it would not work and you

had to do a design in some different way?

Ingalls: Well, you always do what you can and when you’re stuck you

always turn away and reflect.

In the spectrum of implementers, I probably err on the side of just making

things happen. A lot of that is because I get so much of a thrill bringing

Download at Boykma.Com

Dan Ingalls

384

things to life that it doesn’t even matter if it’s wrong at first. The point is,

that as soon as it comes to life it starts telling you what it is.

And you find out that, yes, maybe you could have done the storage

management completely differently, but the really important things you’re

learning have nothing to do with that. The first Smalltalks I did used

reference counting for garbage collection; probably it would have been

better to use something else. For a while there was a certain amount of pain

associated with reference counts. But that didn’t matter—the point was the

system was up and alive and running and we were learning all this other

great stuff about how you put together things with objects, what it’s like to

do numerics in an object-oriented style—all that other real progress.

Seibel: I don’t know that you’re that far out on the spectrum, at least

among the people I’ve talked to for this book. Though Don Knuth did write

TeX in pencil in a notebook for six months before he typed in a line of code

and he said he saved time because he didn’t have to bother writing

scaffolding to test all the code he was developing because he just wrote the

whole thing.

Ingalls: I believe that. There are people who operate completely differently.

But for a given person I think that’s just how they have to operate. I know

I’ve wasted some time one way or another. But there’s also this side of it,

and it’s sort of the archetypal aspect of exploratory programming, which is if

it gets you more quickly to an environment that you can learn from, you

may find out that some of your original goals don’t even matter. What’s

much more important is that other thing over there. And that becomes a

whole new focus.

Coming back to this need to reflect and get things right, there have been a

couple of times when I’ve done that. The example that comes to my mind is

BitBlt. When I decided to do the thing that became BitBlt, it had this

challenge to it that I had to sit and noodle for a night or two. Which is, how

are you going to efficiently move all these bits on bit boundaries across

word boundaries? That was a case where there weren’t any alternatives out

in the world for me to work with. And so I thought about that and thought

about that and came up with a simple model. It wasn’t somebody else’s spec

but I had looked at all the places we were doing line drawing and text

display and scrolling so I had a spec in my mind for what it needed to do.

Download at Boykma.Com