Seibel Peter. Coders at Work

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

L Peter Deutsch

415

about Lisp that caught my imagination. I’ve always had a kind of

mathematical bent, and Lisp just seemed sort of cool. I wanted to have one

to play with and I couldn’t get my hands on the Building 26 mainframe. So I

did my Lisp implementation on the PDP-1.

Seibel: Do you remember at all how you designed your PDP-1 Lisp?

Deutsch: I’m smiling because the program was so small. Have you seen the

listing? It’s only a few hundred lines of assembler.

Seibel: I’ve seen it; I didn’t try to understand it. Was it just a matter of

transliterating the thing in the 1.5 manual into assembly?

Deutsch: No, no, no. All that was in the 1.5 manual was the interpreter. I

had to write a reader and tokenizer and I had to design the data structures

and all that stuff. My recollection was that I did that the way I actually have

done most of my programming, which is to do the data structures first.

When I was young enough that my intuition would point me in the right

direction—I won’t say infallibly, but close enough—that was a really good

approach.

In the last couple of years I’ve noticed that I’ve gotten rusty—my intuition

doesn’t work so well anymore. I’ve been doing a substantial project off and

on for several years now to do a good open-source music score editor. I’ve

been fiddling with that off and on for several years now and I find that letting

my intuition steer me to the right data structures and then just writing

everything out from there just doesn’t work anymore.

Seibel: Do you think your intuition is actually worse or did you used to

have more stamina for making it work even if your intuition was actually a

bit off?

Deutsch: I think it’s some of each but I think it’s more the former. I think

what intuition is, really, is an unconscious process for synthesizing a solution

out of a large amount of data. And as I’ve gotten further and further away

from being immersed in the stuff of software, the data that goes into that

synthesis has become less and less accessible.

Download at Boykma.Com

L Peter Deutsch

416

I’ve heard it said that to be a master at something you have to have, pretty

much at your command, something like 20,000 specific cases. What’s

happened is the 20,000 specific cases of software design that passed in front

of my face in my 45 years in the industry are just gradually becoming less

and less accessible, the way memories do. I think that’s pretty much what’s

going on.

Seibel: Do you remember what it was about programming that drew you

in?

Deutsch: With the benefit of 50 years of hindsight, I can see that I have

always been drawn to systems of denotative symbols—languages. Not only

languages of discourse—human languages—but languages in which

utterances have effects. Programming languages certainly fall right into that

category.

I think that also has something to do with why the career that I’ve switched

into is musical composition. Music is a language, or a family of languages, but

what you say in those languages not only has denotation, maybe, but it also

it has effects on people. Music is kind of interesting because on the

spectrum of formality it falls between natural languages and computer

languages. It’s more formal and structured than a natural language, but it

doesn’t have nearly the structure or formality of a computer language. That,

I think, may have to do with why I went into music and not poetry. I think

poetry is not structured enough for me.

But the short answer really is, I just gravitated to this stuff right away.

Seibel: Do you remember the first interesting program you wrote?

Deutsch: The first program that I wrote because the content interested

me was actually the second program that I wrote. The first program I wrote

was some piece of calculation having to do with the Cambridge Electron

Accelerator. The second program was a floating-point-output-formatting

program.

Seibel: Which is a pretty hairy problem.

Download at Boykma.Com

L Peter Deutsch

417

Deutsch: Well it is on a binary machine. It’s not a hairy problem on a

decimal machine, and I was working on a decimal machine. You just slide the

string around and decide where to put the decimal point. You have to

decide whether to use the E or F format. But in those days, everything was

a lot harder—I was writing in assembly language on a batch-processing

machine—so this was not a trivial problem. It wasn’t a hard problem but it

wasn’t a trivial one. That was the first program that I wrote because I

wanted to.

Seibel: So you were hanging out at MIT during high school and then you

went to Berkeley for college. Did you want to escape the East Coast?

Deutsch: Sort of. I realized that it would be really good for me to go to

someplace that was far away from my parents. The three places that I

considered seriously were, I think it was University of Rochester, University

of Chicago, and Berkeley. That was a no-brainer—only one of the three has

reasonable weather. So that’s how I ended up at Berkeley. And it was one

of the best things that ever happened in my life.

I was at Berkeley and I found Project Genie pretty quickly after I arrived and

stayed with that project until—well there was Project Genie and then there

was Berkeley Computer Corporation and then there was Xerox.

Seibel: Presumably at Berkeley you started working on bigger projects than

your PDP-1 Lisp implementation.

Deutsch: Oh, yeah. Considerably larger projects at Project Genie. To begin

with I wrote pretty much the whole operating-system kernel. The kernel

was probably pushing 10,000 lines.

Seibel: How did that change—an order-of-magnitude difference in size—

change your design process?

Deutsch: I’m trying to remember what was in the kernel. It was still a small

enough program that I could approach it as a whole. There were obviously

functional divisions. I know I had a clear mental model of which sections of

the program were allowed to interact with which of the key data structures.

But in fact there weren’t very damn many data structures. There was a

process table; there were ready lists. There were I/O buffers and there was

Download at Boykma.Com

L Peter Deutsch

418

some stuff for keeping track of virtual memory. And then there was an open

file table, per process. But the descriptions of all the system data structures

probably could have fit on, in terms of C struct definitions, probably could

have fit on two pages. So we’re not talking about a complicated system.

Seibel: What’s the biggest system that you’ve worked on that you

remember how it was designed?

Deutsch: I’ve been the primary mover on three large systems.

Ghostscript—not counting the device drivers, which I didn’t write most

of—was probably somewhere on the order of between 50,000 and 100,000

lines of C.

On the ParcPlace Smalltalk virtual machine I worked only on the just-in-time

compiler, which was probably 20 percent of it, and that was probably in the

low single-digit thousands of lines of C. Maybe 3,000, 5,000—something like

that.

And the Interlisp implementation, as much of it as I was concerned with,

was probably a couple thousand lines of microcode, and maybe—I’m

guessing now—maybe another 5,000 lines of Lisp. So Ghostscript is

probably the largest single system I’ve ever been involved with.

Seibel: And other than the device drivers written by other people, you

basically wrote that by yourself.

Deutsch: Up to the end of 1999, I basically wrote every line of code. At

the beginning I made a few architectural decisions. The first one was to

completely separate the language interpreter from the graphics.

Seibel: The language being PostScript?

Deutsch: Right. So the language interpreter knew nothing about the data

structures being used to do the graphics. It talked to a graphics library that

had an API.

The second decision I made was to structure the graphics library using a

driver interface. So the graphics library understood about pixels and it

understood about curve rendering and it understood about text rendering

Download at Boykma.Com

L Peter Deutsch

419

but it knew as little as I could manage about how pixels were encoded for a

particular device, how pixels were transmitted to a particular device.

The third decision was that the drivers would actually implement the basic

drawing commands. Which, at the beginning, were basically

draw-pixmap and

fill-rectangle.

So the rendering library passed rectangles and pixel arrays to the driver.

And the driver could either put together a full-page image if it wanted to or,

for display, it could pass them through directly to Xlib or GDI or whatever.

So those were the three big architectural decisions that I made up front and

they were all good ones. And they were pretty much motherhood. I guess

the principle that I was following was if you have a situation where you have

something that’s operating in multiple domains and the domains don’t

inherently have a lot of coupling or interaction with each other, that’s a

good place to put a pretty strong software boundary.

So language interpretation and graphics don’t inherently interact with each

other very much. Graphics rendering and pixmap representation interact

more, but that seemed like a good place to put an abstraction boundary as

well.

In fact I wrote a Level 1 PostScript interpreter with no graphics before I

wrote the first line of graphics code. If you open the manual and basically go

through all the operators that don’t make any reference to graphics, I

implemented all of those before I even started designing the graphics. I had

to design the tokenizer; I had to decide on the representation of all the

PostScript data types and the things that the PostScript manual says the

interpreter has to provide. I had to go back and redo a lot of them when we

got to PostScript Level 2, which has garbage collection. But that’s where I

started.

Then I just let my experience with language interpreters carry me into the

design of the data structures for the interpreter. Between the time that I

started and the time that I was able to type in

3 4 add equals and have it

come back with

7 was about three weeks. That was very easy. And by the

way, the environment in which I was working—MS-DOS. MS-DOS with a

stripped-down Emacs and somebody’s C compiler; I don’t remember

whose.

Download at Boykma.Com

L Peter Deutsch

420

Seibel: This was a task that you had done many times before, namely

implementing an interpreter for a language. Did you just start in writing C

code? Or fill up a notebook with data-structure diagrams?

Deutsch: The task seemed simple enough to me that I didn’t bother to

write out diagrams. My recollection was that first I sort of soaked myself in

the PostScript manual. Then I might have made some notes on paper but

probably I just started writing C header files. Because, as I say, I like to

design starting with the data.

Then I had some idea that, well, there’d have to be a file with a main

interpreter loop. There’d have to be some initialization. There’d have to be

a tokenizer. There’d have to be a memory manager. There’d have to be

something to manage the PostScript notion of files. There’d have to be

implementation of the individual PostScript operators. So I divided those up

into a bunch of files sort of by functionally.

When I took the trouble of registering the copyright in the Ghostscript

code I had to send them a complete listing of the earliest Ghostscript

implementation. At that point it was like 10 years later—it was interesting

to me to look at the original code and the original structure and the original

names of various things and to note that probably 70 or 80 percent of the

structure and naming conventions were still there, 10 years and 2 major

PostScript language revisions later.

So basically that’s what I did—data structures first. Rough division into

modules. My belief is still, if you get the data structures and their invariants

right, most of the code will just kind of write itself.

Seibel: So when you say you write a header file, is that to get the function

signatures or the structs, or both?

Deutsch: The structs. This was 1988, before ANSI C—there weren’t

function signatures. Once ANSI C compilers had pretty much become the

standard, I took two months and went through and I made function

signatures for every function in Ghostscript.

Seibel: How has your way of thinking about programming or your practice

of programming, changed from those earliest days to now?

Download at Boykma.Com

L Peter Deutsch

421

Deutsch: It’s changed enormously because the kinds of programs that I find

interesting have changed enormously. I think it’s fair to say that the

programs that I wrote for the first few years were just little pieces of code.

Over time I’ve considered the issues of how do you take a program that

does something larger and interesting and structure it and think about it,

and how do you think about the languages that you use for expressing it in a

way that manages to accomplish your goals of utility, reliability, efficiency,

transparency?

Now I’m aware of a much larger set of criteria for evaluating software. And

I think about those criteria in the context of much larger and more complex

programs, programs where architectural or system-level issues is where all

the hard work is. Not to say that there isn’t still hard work to be done in

individual algorithms, but that’s not what seems most interesting to me any

more—hasn’t for a long time.

Seibel: Should all programmers grow up to work at that level?

Deutsch: No. In fact, I was just reading that an old friend of mine from

Xerox PARC, Leo Guibas, just received some fairly high award in the field.

He has never really been a systems guy in the sense that I’ve been; he’s been

an algorithms guy—a brilliant one. He’s found a way to think about certain

classes of analysis or optimization algorithms in a way that’s made them

applicable to a lot of different problems, and that has yielded new tools for

working with those problems. So, it’s wonderful work. Programmers should

be able to grow up to be Leo Guibas, too.

There’s a parallel between architectural principles and the kinds of

algorithmic design principles that Leo and people like him use to address

these hard optimization and analysis problems. The difference is that the

principles for dealing with algorithmic problems are based a lot more

directly on 5,000 or10,000 years’ worth of history in mathematics. How we

go about programming now, we don’t have anything like that foundation to

build on. Which is one of the reasons why so much software is crap: we

don’t really know what we’re doing yet.

Seibel: So is it OK for people who don’t have a talent for systems-level

thinking to work on smaller parts of software? Can you split the

Download at Boykma.Com

L Peter Deutsch

422

programmers and the architects? Or do you really want everyone who’s

working on systems-style software, since it is sort of fractal, to be able to

think in terms of systems?

Deutsch: I don’t think software is fractal. It might be nice if it were but I

don’t think it is because I don’t think we have very good tools for dealing

with the things that happen as systems get large. I think the things that

happen when systems get large are qualitatively different from the things

that happen as systems go from being small to medium size.

But in terms of who should do software, I don’t have a good flat answer to

that. I do know that the further down in the plumbing the software is, the

more important it is that it be built by really good people. That’s an elitist

point of view, and I’m happy to hold it.

Part of what’s going on today is that the boundary between what is software

and what isn’t software is getting blurred. If you have someone who’s

designing a web site, if that web site has any kind of even moderately

complex behavior in terms of interacting with the user or tracking state,

you have tools for building web sites like that. And working with those

tools—as I understand it, not having used them—accomplishes some of the

same ends as programming, but the means don’t look very much like writing

programs.

So one of the answers to your question might be that over time a larger and

larger fraction of what people used to think of as requiring programming

won’t be “programming” any more and pretty much anybody will be able to

do it and do a reasonable job of it.

You know the old story about the telephone and the telephone operators?

The story is, sometime fairly early in the adoption of the telephone, when it

was clear that use of the telephone was just expanding at an incredible rate,

more and more people were having to be hired to work as operators

because we didn’t have dial telephones. Someone extrapolated the growth

rate and said, “My God. By 20 or 30 years from now, every single person

will have to be a telephone operator.” Well, that’s what happened. I think

something like that may be happening in some big areas of programming, as

well.

Download at Boykma.Com

L Peter Deutsch

423

Seibel: Can programmers be replaced that way?

Deutsch: Depends on what you want to program. One of the things that

I’ve been thinking about off and on over the last five-plus years is, “Why is

programming so hard?”

You have the algorithmic side of programming and that’s close enough to

mathematics that you can use mathematics as the basic model, if you will,

for what goes on in it. You can use mathematical methods and mathematical

ways of thinking. That doesn’t make it easy, but nobody thinks mathematics

is easy. So there’s a pretty good match between the material you’re working

with and our understanding of that material and our understanding of the

skill level that’s required to work with it.

I think part of the problem with the other kind of programming is that the

world of basically all programming languages that we have is so different in

such deep ways from the physical world that our senses and our brains and

our society have coevolved to deal with, that it is loony to expect people to

do well with it. There has to something a little wrong with you for you to

be a really good programmer. Maybe “wrong with you” is a little too strong,

but the qualities that make somebody a well-functioning human being and

the qualities that make somebody a really good programmer—they overlap

but they don’t overlap a whole heck of a lot. And I’m speaking as someone

who was a very good programmer.

The world of von Neumann computation and Algol-family languages has

such different requirements than the physical world, that to me it’s actually

quite surprising that we manage to build large systems at all that work even

as poorly as they do.

Perhaps it shouldn’t be any more surprising than the fact that we can build

jet airliners, but jet airliners are working in the physical world and we have

thousands of years of mechanical engineering to draw on. For software, we

have this weird world with these weird, really bizarre fundamental

properties. The physical world’s properties are rooted in subatomic physics,

but you’ve got these layers: you’ve got subatomic physics, you’ve got atomic

physics, you’ve got chemistry. You’ve got tons of emergent properties that

come out of that and we have all of this apparatus for functioning well in

that world.

Download at Boykma.Com

L Peter Deutsch

424

I don’t look around and see anything that looks like an address or a pointer.

We have objects; we don’t have these weird things that computer scientists

misname “objects.”

Seibel: To say nothing of the scale. Two to the 64th of anything is a lot,

and things happening billions of times a second is fast.

Deutsch: But that doesn’t bother us here in the real world. You know

Avogadro’s number, right? Ten to the 23rd? So, we’re looking here around

at a world that has incredible numbers of little things all clumped together

and happening at the same time. It doesn’t bother us because the world is

such that you don’t have to understand this table at a subatomic level.

The physical properties of matter are such that 99.9 percent of the time you

can understand it in aggregate. And everything you have to know about it,

you can understand from dealing with it in aggregate. To a great extent, that

is not true in the world of software.

People keep trying to do modularization structures for software. And the

state of that art has been improving over time, but it’s still, in my opinion,

very far away from the ease with which we look around and see things that

have, whatever it is, 10 to the 23rd atoms in them, and it doesn’t even faze

us.

Software is a discipline of detail, and that is a deep, horrendous fundamental

problem with software. Until we understand how to conceptualize and

organize software in a way that we don’t have to think about how every

little piece interacts with every other piece, things are not going to get a

whole lot better. And we’re very far from being there.

Seibel: Are the technical reasons things that could be changed, or is it just

the nature of the beast?

Deutsch: You’d have to start over. You’d have to throw out all languages

that have the concept of a pointer to begin with because there is no such

thing as a pointer in the real world. You’d have to come to grips with the

fact that information takes space and exists over time and is located at a

particular place.

Download at Boykma.Com