Seibel Peter. Coders at Work

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

Dan Ingalls

385

Seibel: Maybe you can explain the basic problem that BitBlt was designed

to solve.

Ingalls: The disconnect between wanting to think about the display as just a

1000✕1000-pixel screen and the fact that the memory is organized word by

word. If you want to pick up these four bits and put them down there, they

may be in a different part of the word where you put them down. In fact

they might straddle two words. If, on the screen, you’re trying to move this

thing to there, it may be that you’re going to have to pick up pieces from

two separate words here and lay them down there. And when you lay them

down you have to store an entire word. So you’re going to have to insert

that into what was there before and mask around it. So it’s a mess.

Then there’s the screen raster—the line-by-line aspect of the screen that

gives you two dimensions. BitBlt handles the possibility that the source and

destination may have differing numbers of words per scan line.

That was a challenge where there was a clear spec for what needed to

happen, and it was also one of these things where you tried to have a very

general kernel, because if you do this right, it will not only give you moving

things from one part to another, but it will allow you to do overlapping

scrolls. And it will also allow you to blend pixels. There’s all this opportunity

for generalization.

I tested it and made sure it ran first in Smalltalk, then in assembly, then put

it into microcode for the Alto. When finally done, we could do these

operations at essentially the full speed of the memory without any delay due

to all the yucky masking and shifting because that could all be hidden under

the memory-cycle time.

Having microprogrammed computers around was a wonderful motivation

because it was clear that if there was a little kernel that would do what was

needed, then that could be put in microcode and the whole thing would run

fast. So I was always motivated to do that.

The thing I came up with for all of this, it actually came to me as an image

rather than anything else, which is, it’s like a wheel. If you think of the

source and the destination and word boundaries, it’s like there’s a wheel

picking up whole words here and then dropping them off here, and there

Download at Boykma.Com

Dan Ingalls

386

would only be one shift required—that was the picture that came to me.

Then it was just a matter of putting that into code.

So at the center of the BitBlt operation there’s essentially one long shifter,

which is picking up words from the source and dropping them in the

destination. That was the thing I had to sit down and think about. But once

you had that you could do storing of constants this way, you could do the

laying down of text, the extraction of glyphs from a font, and putting them

down at any pixel location.

Seibel: Back to the BASIC implementation of Smalltalk: that was sort of the

primordial Smalltalk, before even Smalltalk-72?

Ingalls: Right. The minute that worked I set off and did this whole

assembly-language version—because that’s what I had on the Nova—that

was fairly complete. So we used that to debug a bunch of stuff and then, in

parallel with that, the Alto was being built. As soon as it was available, we

moved over and started running on the Alto. That became Smalltalk-72.

Seibel: So Smalltalk-72 was written in assembler—where along the line did

it become self-hosting? You often hear that one of the great things about

Smalltalk was that so much of it was implemented in itself.

Ingalls: That was a long time later. Smalltalk-72 had a big pile of assembly

code with it. And Smalltalk-76 did, too. The big difference from Smalltalk-72

to Smalltalk-76 was that I came up with the byte-code engine for Smalltalk

that had the keyword syntax and it was compilable. Also that classes and

even stack frames were real objects, to your point about self-description.

Seibel: Where did you get the idea to write a byte-code interpreter?

Ingalls: That was a mechanism. The big thing that I was grappling with was

that Smalltalk-72 parsed on the fly and for two reasons, at least, we needed

to be able to compile something that had those kinds of semantics but that

didn’t require parsing everything on the fly.

So I came up with the Smalltalk-76 syntax, which is pretty much the

Smalltalk-80 syntax. Then the question is, what do you compile that into

that will run effectively this way? The only place where it got complicated

Download at Boykma.Com

Dan Ingalls

387

was in doing what we called remote evaluation—variables you declare up

here but they get evaluated down here. This is what ended up as blocks in

Smalltalk, which are like closures in other systems.

Seibel: Why not just compile to machine code?

Ingalls: We were still very space-conscious and this stuff wound up

incredibly compact compared to anything else around. And it needed to be

that compact because we were still trying to run this on Altos that had 96K.

Then they came out with the big one, which was 128K. The compactness

was important.

Seibel: Meaning the generated code would be smaller because the byte

codes were richer than native machine instructions?

Ingalls: Yeah. I also just plain loved the idea and was inspired by Peter

Deutsch’s work on the byte-code engine for Lisp. I was further inspired by

this synergy—it’s another one of these kernels that could fit in microcode.

From the beginning I envisioned it as going into the microcode of the Alto.

Seibel: And the microcode was RAM so you could put the Smalltalk kernel

in there and then switch to Lisp and put the Lisp byte-code interpreter in

there.

Ingalls: Yup.

Seibel: Then what was the next evolution?

Ingalls: Smalltalk-76 inherited all the same sort of graphics baggage—a lot

of special code for line drawing, text display, and so on. But at that time I

had done BitBlt, so I rewrote the kernel so all the graphics just used BitBlt

and Smalltalk, so that made the kernel much smaller. That was Smalltalk-78,

which was the first one we ran on a microprocessor—on an 8086.

But that still wasn’t Smalltalk in Smalltalk. The Smalltalk in Smalltalk wasn’t

until Squeak. Smalltalk-80 had a virtual machine spec that was published in

the book, but all the implementations were in C or assembly code.

Seibel: What about the compiler?

Download at Boykma.Com

Dan Ingalls

388

Ingalls: The compiler was written in Smalltalk. Actually, when we were

doing the Smalltalk-80 books, Dave Robson and I—it was mainly his work—

wrote a Smalltalk emulation of the byte-code interpreter. As part of the

Smalltalk-80 release we wanted to help people build their own virtual

machines. We had discovered that one of the most useful aids was a trace

of exactly what byte-codes get executed in what order when you first start

up the system.

So he wrote an emulator in Smalltalk, because our Smalltalk was getting fast

enough that that was a reasonable thing to do, and produced all those

traces that would help people debugging.

Seibel: And you wanted to help people write Smalltalk virtual machines

because the point of Smalltalk-80 was to be an escape pod so Smalltalk

could go out into the world even if PARC decided not to do anything with

it?

Ingalls: That’s right. Then I left the industry and when I came back, I

wanted to do a Smalltalk for a new project. At that time things were

running so fast that, “Wait a minute; why don’t we just try running the

Smalltalk version of it and see what that does?” But the “aha!” was, it

shouldn’t be hard to mechanically translate that to C and then it would be

as fast as the other engines. If you wanted to change something about the

virtual machine you could change that in Smalltalk—you could try it out in

Smalltalk and then push a button, and it would suddenly be in the

production interpreter.

Seibel: So you took this Smalltalk interpreter written in whatever subset of

Smalltalk it happened to be written in and wrote a special-purpose compiler

that knows how to compile that subset into C?

Ingalls: And the C translator was simply a subset of the Smalltalk

compiler—we just had to make the parse trees print out in C. This was

actually something we had done before at Xerox—Ted Kaehler had written

a virtual memory in Smalltalk, and then we used the same trick to translate

that to BCPL. Same thing.

Seibel: When Smalltalk-80 got out in the world there were Smalltalk

companies; objects were a big thing; Byte did its issue all about Smalltalk.

Download at Boykma.Com

Dan Ingalls

389

The promise was that objects were going to be these reusable components

and that programmers would just go down to Ye Olde Object Shoppe and

buy some objects and plug them into their program. Has that promise been

kept?

Ingalls: I think yes and no.

Seibel: So in what ways has it happened?

Ingalls: Look at the world of Java—it’s that kind of a world. There are huge

bodies of software that work well together because of those kinds of

interfaces. I think that was all a real step forward. There were several things

going on in Smalltalk that did end up in the world more or less. One of

them is object-oriented design and interfaces. The other is dynamic

languages and user interfaces. It didn’t take over and you can look at various

little places in history where things could have been done differently and it

might have had a better chance. But I don’t think that’s a big thing lost or

gained. The world moves forward slowly. Other things got done that were

better. Natural selection takes care of it all.

Seibel: But natural selection can also select some pretty grotesque

outcomes.

Ingalls: Oh yeah, Beta and VHS, it’s true. But ultimately, nothing that’s

really good ever gets really lost.

Seibel: Another aspect of Smalltalk that Alan Kay has particularly

emphasized in recent years is that it wasn’t supposed to be about objects; it

was about message passing. C++ and Java don’t have message passing in

nearly the same way Smalltalk did. Why is that such a core idea?

Ingalls: Because it gives you real separation. Alan’s latest phrase—which is

appropriate, I think—is it should be like the Internet all the way down. We

worry about where we have security and various sorts of security

mechanisms in programs and there are all sorts of things wrong with them.

But the Internet-style separation is a real layer that there’s no way around.

So why is message passing such a good thing? That’s the reason: it separates

the inside from the outside, 100 percent. At least, done right it does. And

Download at Boykma.Com

Dan Ingalls

390

there are other systems that have gone farther with this and I think we’ll

see more in that space.

Seibel: So nothing good ever gets really lost. Are there ideas, from

Smalltalk or anywhere else, that you wish had been adopted by the

mainstream?

Ingalls: I don’t really have wishes for the mainstream—I have things I want

to do or that I would like to be easy. My one wish for the mainstream, in

the context of computer science, is that people would go back to first

principles a little bit more about ways to leverage computing in the

intellectual space.

We’ve gotten incredibly good with the programming systems and the

languages we know. What if we were that good with logic programming?

And had it integrated well? I think we would be doing extraordinarily more

stuff in much more of a human-oriented space. It does go in the direction of

artificial intelligence. You have to know that at some point we’re going to

cross a threshold where computers will be doing a better job thinking about

stuff than we do.

I wonder sometimes if we’re unconsciously holding that off. A lot of

progress was made, up until 1980, in that area. And the computers are

orders of magnitude faster and bigger now. On the latest computer I got, if I

run the Smalltalk music synthesis, in Smalltalk, it can compute the radio

signal for a radio station. This is hard for somebody who, at one point,

could watch simple arithmetic being computed.

So you take that and put it against all sorts of possibilities in logic

programming, in rule-based systems, and artificial intelligence, and you have

to know there’s lots of progress to be made there. I would like to see the

kind of thinking that led to the Lively Kernel—what is a kernel apart from

the language and the user interface? What other kernels are there? What if

you build a kernel around logic programming and what kinds of things can

you do with that? I don’t think that people are playing around with, tinkering

with that stuff enough. Because, Lord, the machines we have today—if you

have a minor breakthrough there you could do incredible stuff.

Download at Boykma.Com

Dan Ingalls

391

Seibel: Smalltalk was originally envisioned as a platform for use in

education, right?

Ingalls: It was envisioned as a language for kids—children of all ages—to

use Alan’s original phrase. I think one of the things that helped that whole

project, and it was a long-term project, was that it wasn’t like we were out

to do the world’s best programming environment. We were out to build

educational software, so a lot of the charter was more in the space of

simplicity and modeling the real world.

Something about having this educational goal made it easy to keep inspiring

the lower-level stuff to be as simple as possible. So there were lots of things

we did that didn’t run as fast as you might like. The first Smalltalk-72 system

was really slow—the second revision on it ran about 20, 25 times faster. But

we had it running, by God, and we were able to use it with kids and learned

a huge amount before even trying a second version.

We focused a lot on getting some cool graphics to work, bitmapped

graphics, music, and putting it together in a fairly simple language. What we

learned from that did actually make a seriously good language. So after

Smalltalk-72, we did Smalltalk-76, which was essentially Smalltalk-80. And I

saw that that could be a serious programming environment for the industry.

There was some tension there with Alan because he wanted to not get

scattered in that direction.

It wasn’t too much longer before he left Xerox, and so we pursued those

separate paths. But that was because we had discovered some things. For

instance, our turnaround time for making changes in the system from the

beginning was seconds, and subsecond fairly soon. It was just totally alive.

And that’s something which I, and a bunch of the other people, got a

passion for. Let’s build a system that’s living like that. That’s what Smalltalk

became. So that then became a new goal, which then spun Smalltalk-80 off.

Squeak was a return to that, but with the doing-it-in-itself bit added.

Seibel: So you and Kay followed, as you say, separate paths. Did you

become disenchanted with the original Smalltalk vision?

Ingalls: No, not at all. I’ve talked about my training as a physicist, and I

think it’s in my nature to look at the world—how it works, how forces are,

Download at Boykma.Com

Dan Ingalls

392

how the planets move, how the winds blow, and all that stuff—as asking

questions about it and really being in touch with the phenomenon. In the

physical world, at least, that’s easy. You can zero in and come away with an

understanding of, “Yes, that’s how it works.”

In computers I think there’s the same kind of thing. You should be able, in a

computing environment, to zero in on music and musical synthesis and

sound and just understand how the whole thing works. It should be

accessible. The same thing with graphics. It’s put together very much the

same way. You’ve got atomic things, which are the various graphical effects,

and then you’ve got structural things you put them together with. The same

thing’s the case for numerical calculation.

When I take somebody new with Smalltalk, I’ll say, “What interests you,

taking text apart? Playing with numbers? Looking at graphics? Or playing

with music?” And then we start there and do a deep dive on that. It’s very

much still a part of my passion, and I’m sure Alan’s too, to take people

through some deep dive in a direction that they’re motivated about so they

come away with what Alan calls powerful ideas—the “aha!” that lets you

see this amazing variety is really a couple of small, general things at work.

You can see that in music. You can see it in graphics. You can see it in

numbers and text manipulation. And it’s really exciting to me to make that

available and accessible.

The Squeak environment is really a computer scientist’s environment. The

eToys environment is a kids’ environment, but not as comprehensive as it

could be, and I still feel there’s a thing we haven’t done out there, which

would allow you equally intuitively to dive in and get a physical

understanding of those powerful ideas.

I’m still as passionate about that as anything. Why I’m here doing this stuff—

JavaScript and the browser—is that we’re getting pretty close to being able

to put Squeak-like material on a web page that you can browse from any

browser and interact with in some nice, self-revealing way. That’s part of

this whole picture. I’m sure it’s going to change. Browsers are going to

change. We’ll get other languages besides JavaScript, and I’m still totally in

touch with Alan and his group, who are doing another take on this going

Download at Boykma.Com

Dan Ingalls

393

deeper down and trying to solve some of these other things more seriously.

But it’s absolutely still the same vision.

Seibel: You mention four disciplines: music, graphics, mathematics, and

text. Those are about as old as humanity. Clearly there are powerful ideas

there that are independent of computers—the computer just provides a

way to explore them that might be hard without the computer. Is there also

a set of interesting, powerful ideas inherent in the computer? Is

programming or computer science another deep discipline—a fifth area—

that we can only do now that we have computers?

Ingalls: Yes, I think that’s what I am getting at. The curriculum I’ve always

envisioned is one in which you start with one of these and maybe from the

motivation of going deep in one of those areas, you move over to one of

the other ones that’s less familiar and do a similar thing there. And a lesson

to be learned is that the way in which you get to those simpler, deeper

structures that generate that whole field is similar in every case.

There’s an algebra of graphics. It’s primitive objects, superposition

translation, rotation. Or music. It’s notes and temporal sequences and

chordals—same thing. And I think this goes back to seeing how the wind

works and how the planets move. It’s an invitation to go down and find out

how things work and learn the things that make up the algebra—the

processes and the primitive things. So yes, that fifth area, as you call it, is

just what’s common about all of these things.

Seibel: Would you expect someone who has played with three or four of

these areas to end up learning how to program? Or is that just one of the

things that could happen if their interest happened to go down a particular

channel?

Ingalls: I think it’s just one of the things that could happen. Hopefully

you’ve sharpened their thinking skills. Both by introducing them to stuff and

by getting them excited about stuff in some way or another. But there are

people who are going to like programming and there are people who are

not. I’ve got a 12-year-old son and all he wants to do is do 540s on skis, and

there’s a time and a place for everything.

Seibel: Back to some nitty-gritty: how do you test your software?

Download at Boykma.Com

Dan Ingalls

394

Ingalls: It depends what I’m doing. I always set it up for the most immediate

gratification. So when trying to do something new, I just think of what

would be the first piece of success that’s achievable. And it’s different in

every case. If I had a more normal life, in more normal programming teams,

I’d probably be totally into the current way of team programming. But for

me, it’s much more self-induced—even down to a question of my attention

span. If I think I could get this working over the weekend, then that’s the

chunk I pick and that’s the thing that I go flat out for, ignoring all the other

things. It’s hard for me to generalize this except to say, there’s a place you

want to get to, you pick a piece of it that would be gratifying and that would

demonstrate that you’re on the path and that you can fit into the time until

you next get pulled off to do this at home or that at work.

Seibel: Since you’ve picked something that’s going to have some kind of

gratifying result at the end, that’s your first test—an acceptance test: does it

draw a window on the screen or whatever? What about finer-grained tests?

Ingalls: If it’s the first time you’ve made it possible to pick something up

and drag it over and drop it down, there’s a framework that you need to

have working there. Is the framework factored so that someone else

coming along will see that these are the tests? That’s something that I have

not typically done. This may just be the luxury of my generation—nobody

would get away with that these days. But I’m an old fart and they’re not

going to make me do it. But I think the underlying feeling is still the same.

The Squeak code used to be full of comments that are executable and things

to check. For instance, in lots of the BitBlt tests, there are these little things

that will pick something up from one place on the screen, do something to

it, and put it back, and if you see anything change on the screen, it’s not

working right and the comment says so. That’s a straightforward test.

Seibel: So let’s talk about working with others. The Learning Research

Group at PARC sounded like a pretty close-knit group. How did you

collaborate on the code itself?

Ingalls: Just by being close. And occasional mayhem. It was never a big

group and we each had our own areas. There’s a lot of team programming

expertise that’s grown up and I’m not up on it at all. Right now, in the Lively

Kernel, the kernel part has been just me and one other guy, Krzysztof

Palacz. And we sort of have our separate areas that we work on. We

Download at Boykma.Com