Seibel Peter. Coders at Work

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

Guy Steele

345

Seibel: So they were just customizing, essentially, the key-bindings?

Steele: That’s right. And they each had their own ideas about what should

be concise because you do it most often and what you can afford to be

longer. So one guy, for example, was really concerned about typing in Lisp

code and began to experiment with finding balanced parenthesized

expressions. And another guy was more interested in text, so he was

interested in commands that would move over words and convert between

uppercase and lowercase and capitalize them. And that’s where those

commands in Emacs came from.

Different people had different ideas about how the key-bindings ought to be

organized. As a systems-support guy for Lisp, I was often called to people’s

terminals and asked to help them. And I fairly quickly noticed that I couldn’t

sit down at their TECOs and help them modify their programs because I’d

be faced with a set of key-bindings and I had no idea what they were going

to do.

Seibel: Was one of these guys Richard Stallman?

Steele: No, Stallman was the implementer and supporter of TECO. And he

provided the built-in real-time edit mode feature, although I think Carl

Mikkelsen had worked on the early version of it. He provided the key-

bindings feature that made all of this possible.

Anyway, there were something like four different macro packages and they

were incompatible, and I decided to play standards guy, or community

reconciliation guy. I saw something that had been lost in our community,

which was the ability to easily help each other at our terminals. I said, “OK,

we’ve had some experimentation; we’ve seen a bunch of ideas. What if we

could agree on a common set of key-bindings and draw the best ideas from

each of these things?”

I literally had a pad of paper and ran around the building, talking to these

guys, visiting each of them several times, and tried to get some kind of

consensus. I was trying to get consensus on what the content ought to be

and then I drew on their designs and tried to organize the actual choice of

key-bindings so as to make them a little more regular and a little more

mnemonic. And not being a human-factors guy at all, I didn’t think at all

Download at Boykma.Com

Guy Steele

346

about convenience for touch typists. I was principally concerned with

mnemonic value. And so that’s why Meta-C and Meta-L and Meta-U stand

for capitalize and lowercase and uppercase.

Seibel: Which is sort of ironic given the way the commands move out of

your brain and into your fingers. I’m sure you have experienced the

phenomenon of having someone ask you what is the key-binding for

something that you use a thousand times a day, and you can’t say.

Steele: Actually my wife had that experience. Maybe one of the reasons I

was less aware of it is that I’m not a particularly good touch typist. But she’d

been away from Emacs for 20 years and then I made one available on her

Macintosh. And she sat down, typed in some stuff, and then said, “How do I

save this? I forget how to save a file.” And then she realized her fingers had

done it and she didn’t know what she’d typed. So she did it again and

watched her fingers and said, “Oh yes, Control-X Control-S.” But she

literally couldn’t remember what the commands were.

Seibel: So you made this standard set of key-bindings. How did that go

over? Were people happy with it?

Steele: Well, people worked through it. Then I then sat down and

proceeded to begin an implementation of it. And we had another idea that

came into the mix at the same time and it was the idea that you could make

TECO macros run a lot faster if you squeezed out the spaces and deleted all

the comments. The way the TECO interpreter worked, interpreting one

character at a time, when you encountered a comment it had to spend the

time skipping over that comment. So we had this idea of this very primitive

TECO compiler that was mostly just squeezing out the white space and the

comments and doing a few other minor things to put it in a form that would

run a little bit faster.

So I began in an initial way to try to construct a version of this macro

compressor, which I think was actually based on an earlier idea that Moon

had had. I don’t think I originated that idea. I began to think about how to

organize the initial dispatch and organize some of the first few routines

borrowing on the existing implementations of other macro packages—I was

trying to synthesize them. And about that point Stallman came along and

said, “What are you doing? This looks interesting.” He immediately jumped

Download at Boykma.Com

Guy Steele

347

in and he could implement ten times as fast as I could, partly because he

knew TECO inside out.

So I worked seriously on the implementation of Emacs probably for only

about four or six weeks. At which point it became clear that Stallman

understood what the program was. I wanted to get back to doing graduate-

student things. So Stallman did the other 99.999 percent of the work. But I

played a role in catalyzing it and beginning the implementation.

Seibel: On a different subject, academic computer science is very

mathematical these days. How important is it for working programmers to

be able to understand, say, the math in Knuth? Versus saying, “I need to sort

things; I’m going to flip through Knuth and skip to where he says, ‘This is the

best algorithm’ and implement that”?

Steele: I don’t know. There are parts of Knuth that I don’t understand

because I don’t have the mathematical training. Particularly if it involves

higher or continuous math. I’m a little weaker on that. I think my strengths

are in things like combinatorics and permutations, group theory, things like

that. And I find myself using that over and over and over again. Maybe that’s

because that’s the particular hammer I have at hand. I don’t think that every

programmer needs that. But I think that mathematics formalizes concepts

that programmers do need to work with every day.

I’ll give you an example from my recent programming-language work on

parallel languages, this Fortress project that I’ve got going. Suppose you

want to add up a bunch of numbers. Well, one thing you can do is you can

initialize a register to zero and add in the numbers one at a time—a classic

sequential technique.

Notice that this depends on the addition operation having an identity. You

needed to start with zero. Trivial little observation, but it’s there.

Now here’s another strategy—you can lay out all the numbers in a row and

then add them up pairwise, giving you a bunch of sums, and keep adding

pairwise until you’ve only got one number left. And of course if at any point

you’ve got an odd number of them you just leave that one over extra and

let it go to the next stage and so forth. Well, that works fine, too. And if

you’re using floating-point numbers it may actually give you a little bit better

Download at Boykma.Com

Guy Steele

348

accuracy, although with the bookkeeping overhead it’s sometimes not

worth it.

Notice that this will give you the same answer, at least if you’re working

with integers, as starting with zero and adding them one at a time. This

depends on the fact that addition is associative. In other words, it doesn’t

matter in what way you group the numbers.

And then there’s a third strategy. Suppose you’ve got a bunch of

processors. You could parcel out the pairs to the processors and distribute

that work. The “start with zero and add them one at a time” algorithm is

hard to parallelize, but with the bunching in pairs, you’ve in effect made a

tree and you can assign processors different parts of the tree, and they can

do their parts independently, and only at the end do they need to interact

and you get the sum.

OK, so that’s cool. Here’s another parallel strategy that’s more like the first

one: pick some register and initialize it to zero, and then let processors

compete for grabbing numbers and adding them into that common place.

This involves questions of synchronization, but you will still get the same

answer. But this depends on addition being both associative and

commutative. That is, not only does it not matter how you group the

numbers, it also doesn’t matter in what order you process the numbers.

Mathematicians have big, scary words like “identity” and “associativity” and

“commutativity” to talk about this stuff—it’s their shorthand. But

programmers need to know about ideas like, it doesn’t matter in what

order you do it. And they need to know about ideas like, it’s OK if you

regroup things. So to that extent I claim that mathematical ideas are

important at some level to programmers.

Seibel: Obviously that’s a good example to give because anyone who

understands arithmetic can understand it. But do you find that there are

kind of higher-level concepts that come back into programming in the same

way?

Steele: Now suppose I’m generating a report. The typical thing is you make

a bunch of print statements and you depend on doing them in order and

things get printed out in the order you said. Well, in this multicore world

Download at Boykma.Com

Guy Steele

349

maybe I would like to break up the generation of the report and parcel it

out to processors. Well, how about concatenating strings? Can I use the

same techniques I used for adding up numbers? Turns out it is associative

but not commutative—that tells me exactly which tricks will work for the

strings and which ones won’t.As a language designer worrying about

designing parallel programming languages, I find these concepts and a

vocabulary for them very useful.

Seibel: Speaking of being a language designer, how have your ideas about

language design changed over time?

Steele: I think that the biggest change in my thinking is what I set down in

that talk “Growing a Language” at OOPSLA almost ten years ago, in 1998.

Back in the ’70s people would invent languages and make a complete design

and implement it and you’d be done. Or you wouldn’t be done, but you had

this idea that there is this complete thing.

So Pascal was an invention. Things were in it for a reason and things were

left out for a reason but it was a complete design. And if it turned out that it

wasn’t complete—if it turned out that string processing wasn’t that great,

well, too bad: Wirth had designed the language. And PL/I got designed and

Ada got designed. And maybe Ada and C++ were close to the last of that

generation. And C++ not so much, because it did sort of evolve over time.

I realized as languages got more complicated they were really too big to

design all at once and that languages would necessarily from now on

undergo evolution because they were too big to design all at once or to

implement all at once. And that caused a change in how I approached

programming-language design and thinking about it.

Seibel: So you think Java was not designed that way?

Steele: I think maybe Java was not and should have been. Java has evolved

through the Java Community Process. That has addressed more API than

core language issues. And while features have been added to the language

over the last 12 or 13 years, I think the team that designed Java in the early

’90s thought they were designing a complete language for a specific self-

contained purpose. You know, they were aiming at set-top boxes.

Download at Boykma.Com

Guy Steele

350

Seibel: Right.

Steele: They hadn’t even envisioned at that point programming the World

Wide Web or having as huge a user base as it has turned out to have. And

so I thought they were designing a fairly small, self-contained kernel language

on top of which you would then build a bunch of APIs and use it for various

things. And that was the model and that’s the way it’s worked out. And part

of my thoughts about “Growing a Language” came out of observing that

process, that Java turned out to be a little bit too small and people wanted

more features to get to other things.

In particular there was pressure for the kind of

for loop that could iterate

through an enumeration. That is a feature that got added to the language.

There was pressure from the high-performance scientific computing

community to put in more features to support floating point and stuff like

that. That pretty much got rejected by the Java Community Process, and I

think that was more for social reasons than technical reasons.

But there is this demand for adding to the language and then there was a

social process that gated that in various ways. And so I got to thinking that

maybe for a really successful programming language, you need to design and

plan for the social process as much as you design the technical features of

the language and think about how those two things are going to interact.

And Fortress is our first experiment with that, or at least my first

experiment with that. And it’s still early in the game—it’s only a half-done

experiment.

Seibel: Don’t you think Common Lisp, which you were involved with,

stakes out a position in how one does that?

Steele: Yes, that was the other early example as over against something

like Java that got me thinking about these “growing a language” issues. I’m

certainly familiar with the history of Lisp and how its macro facilities in

particular made it somewhat easier for it to evolve over time and for people

to make contributions.

Seibel: It seems like recently three languages, all of which you were

involved with at some level, have gone through or are going through a

painful redesign. Scheme just went through R6RS; JavaScript—

Download at Boykma.Com

Guy Steele

351

ECMAScript—is going through the ES4 vs. ES3.1 debate. And Java is

struggling with whether or not and how to add closures.

Steele: For example, yes.

Seibel: Are these examples of languages that didn’t have enough built-in

technical or social wherewithal to grow easily and so had to go through

these painful growth processes? Or is this how it always happens?

Steele: Well, if a language doesn’t die, it is going to grow. There are always

evolutionary pressures because needs change and people will want to

modify the tool to suit where they are now as opposed to where they were

five years ago. My conjecture isn’t about whether a language will grow or

not but rather about technical choices you can make in the early design of

the language that may facilitate the growth in certain ways later on. And I

think some languages have turned out to be easier to grow than others

because of technical differences among them. And also in part because of

differences among the social contexts.

Seibel: So what are the examples that have grown easily?

Steele: Well, I think Lisp is an example of a language that has grown easily

because of the flexibility of its macro mechanism. And to some extent in

part because of the social attitudes of the group that constructed it.

Scheme, by contrast, has had a much more painful growth path. And that’s

in part because the Scheme community developed a culture early on that

they would not put anything in the language unless everyone agreed on it.

Or close to everyone. So it was more of a blackball culture. Whereas with

the community that turned into Common Lisp, majority was enough to

satisfy everyone. And people were more willing to accept things they

weren’t crazy about in order to get other things.

Seibel: How much does a choice of language really matter? Are there good

reasons to choose one language over another or does it all just come down

to taste?

Steele: Why shouldn’t taste be a good reason?

Download at Boykma.Com

Guy Steele

352

Seibel: Well, I may like vanilla ice cream and you like chocolate, but we

don’t fight about it. But people fight about programming languages.

Steele: Well, that’s the human social phenomenon of wanting to belong to

the winning side. And, no, I don’t think it’s worth fighting over, but I think

it’s reasonable to have opinions about what is a more effective tool for a

given task.

The one thing I am reasonably convinced of is that it’s a mistake to think

that one language solves all problems better than any other language, or

even equally well. I really think that there are application areas for which

particular languages are better suited.

I feel perfectly free, when doing algorithm design, to use a hodgepodge of

different languages. As long as I’m just communicating with myself I will go

to a whiteboard and write fragments of Java and Fortran with APL mixed in.

It doesn’t bother me in the least as long as I can sort out what I’ve written

afterwards. For a particular piece of the algorithm the notation is buying me

something that I think another language wouldn’t be nearly as clear or useful

for.

The problem is, if you come up with a notation that’s good at one small set

of ideas, you still want to put that in the context of a complete

programming language and you have to build something around it and make

it complete and if you don’t do a good job of everything, then you end up

with a lopsided language that’s great at this one idea and kind of clunky for

the other stuff.

On the other hand, it’s really hard to make a language that’s great at

everything, in part just because there are only so many concise notations to

go around. There’s this Huffman encoding problem. If you make something

concise, something is going to have to be more verbose as a consequence.

So in designing a language, one of the things you think about is, “What are

the things I want to make very easy to say and very easy to get right?” But

with the understanding that, having used up characters or symbols for that

purpose, you’re going to have made something else a little bit harder to say.

Seibel: One way to resolve that is the way Lisp does—make everything

uniformly semiconcise. Where the uniformity has the advantage of allowing

Download at Boykma.Com

Guy Steele

353

users of the language to easily add their own equally uniform, semiconcise,

first-class syntactic extensions. Yet a lot of folks resist the s-expression

syntax. The smug Lisp weenie view of the world is, “Some people just don’t

get it; if they did they would see the brilliance of the solution.” Are you a

smug enough Lisp weenie to think that if people really understood Lisp they

would not be put off by the parentheses?

Steele: No. I don’t think I’ve got the standing to be smug. If anything,

because I have learned so many languages I think I understand better than a

lot of people the fact that different languages can offer different things. And

there are good reasons to make choices among them rather than to hold up

one language and say, “This is the winner.”

There are certain kinds of projects that I would not want to tackle with

anything other than Lisp because I’m interested in the set of tools it

provides me. For instance, ready-made input/output—if I’m willing to

conform to Lisp’s syntax, then I’ve already got readers and printers built

that are adequate for some kinds of jobs. This in turn allows you to do

some kinds of rapid prototyping. On the other hand, if it’s important that I

customize the I/O to an existing specific format, then Lisp might not be such

a good tool. Or else I might have to build some kind of transducer in some

language, Lisp or otherwise, to get it over to the Lisp world.

Seibel: What languages have you used seriously? It must be a long list for

you.

Steele: I earned my first money programming in COBOL. I was still a high-

school student and subcontracted to someone who was doing a report-card

generator system for another school system, so there wasn’t any conflict of

interest there. I used Fortran, IBM 1130 assembly language, PDP-10 machine

language, APL. I guess I can’t claim to have used SNOBOL seriously.

Certainly C, C++, Bliss, the DECsystems implementation language that

came out of Carnegie Mellon. GNAL, which is based on Red, I’ve used quite

seriously.

Several different varieties of Lisp, including Common Lisp, Scheme, Maclisp.

The version of Lisp that Dick Gabriel and I built for the S-1, S-1 Lisp, which

was one of the four or five that merged to make Common Lisp. I developed

Connection Machine Lisp but I’m not sure I could be said to have done

Download at Boykma.Com

Guy Steele

354

serious coding in it. That was, I think, in turn implemented in *Lisp. *Lisp is

not to be confused with Connection Machine Lisp; they are two distinct

languages.

I did some serious coding in C*, which was another language we developed

for the Connection Machine. Java, of course. And some scripting languages.

I’ve done some extensive work in JavaScript, in Tcl.

I’ve done serious programming in Haskell, taking “serious” to mean I’ve

worked with a language for more than a month and tried to write a

substantial piece of code in it. Oh, FOCAL, an early interactive language on

the DEC computers, similar to . . . a little bit like BASIC, a little bit like

JOSS. I’ve done substantial coding in BASIC, now that I think about it. And

TECO, the Text Editor and Corrector, of course was used to program the

first version of Emacs and I regard that as a programming language for that

purpose. I wrote enormous amounts of TECO code. And TeX, also

regarded as a programming language. Those would be the main ones, I

guess.

Seibel: I’m guessing from what you said earlier that the answer to the

question of “What’s your favorite programming language?” would have to

be “mu.”

Steele: I’ve got three children; you might as well ask me which is my

favorite. They’re all great—they’ve got different skills and different

personalities.

Seibel: Are there any programming languages which you just don’t enjoy

using?

Steele: I get some kind of pleasure out of each language. But there are

certainly certain languages that I find more frustrating than others. I enjoyed

TECO at the time; I don’t think I’d want to go back. It had quite a number

of difficulties—it was very difficult to come back in a month and read what

you’d written.

I’m not sure that I’ve written enough Perl code to be taken seriously as a

detractor, but I have not been attracted to the language. I have not been

attracted to C++. I have written some C++ code. Anything I think I might

Download at Boykma.Com