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 somethinglike Java that got me thinking about these “growing a language” issues. I’mcertainly familiar with the history of Lisp and how its macro facilities inparticular made it somewhat easier for it to evolve over time and for peopleto make contributions.

Seibel: It seems like recently three languages, all of which you wereinvolved with at some level, have gone through or are going through apainful redesign. Scheme just went through R6RS;JavaScript—ECMAScript—is going through the ES4 vs. ES3.1 debate. And Java isstruggling 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-intechnical or social wherewithal to grow easily and so had to go throughthese 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 alwaysevolutionary pressures because needs change and people will want tomodify the tool to suit where they are now as opposed to where they werefive years ago. My conjecture isn’t about whether a language will grow ornot but rather about technical choices you can make in the early design ofthe language that may facilitate the growth in certain ways later on. And Ithink some languages have turned out to be easier to grow than othersbecause of technical differences among them. And also in part because ofdifferences 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 easilybecause of the flexibility of its macro mechanism. And to some extent inpart because of the social attitudes of the group that constructed it.

Scheme, by contrast, has had a much more painful growth path. And that’sin part because the Scheme community developed a culture early on thatthey 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 withthe community that turned into Common Lisp, majority was enough tosatisfy everyone. And people were more willing to accept things theyweren’t crazy about in order to get other things.

Seibel: How much does a choice of language really matter? Are there goodreasons to choose one language over another or does it all just come downto taste?

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

Seibel: Well, I may like vanilla ice cream and you like chocolate, but wedon’t fight about it. But people fight about programming languages.

Steele: Well, that’s the human social phenomenon of wanting to belong tothe winning side. And, no, I don’t think it’s worth fighting over, but I thinkit’s reasonable to have opinions about what is a more effective tool for agiven task.

The one thing I am reasonably convinced of is that it’s a mistake to thinkthat one language solves all problems better than any other language, oreven equally well. I really think that there are application areas for whichparticular languages are better suited.

I feel perfectly free, when doing algorithm design, to use a hodgepodge ofdifferent languages. As long as I’m just communicating with myself I will goto 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 writtenafterwards. For a particular piece of the algorithm the notation is buying mesomething that I think another language wouldn’t be nearly as clear or usefulfor.

The problem is, if you come up with a notation that’s good at one small setof ideas, you still want to put that in the context of a completeprogramming language and you have to build something around it and makeit complete and if you don’t do a good job of everything, then you end upwith a lopsided language that’s great at this one idea and kind of clunky forthe other stuff.

On the other hand, it’s really hard to make a language that’s great ateverything, in part just because there are only so many concise notations togo around. There’s this Huffman encoding problem. If you make somethingconcise, 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 arethe things I want to make very easy to say and very easy to get right?” Butwith the understanding that, having used up characters or symbols for thatpurpose, 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 everythinguniformly semiconcise. Where the uniformity has the advantage of allowingusers of the language to easily add their own equally uniform, semiconcise,first-class syntactic extensions. Yet a lot of folks resist the s-expressionsyntax. The smug Lisp weenie view of the world is, “Some people just don’tget it; if they did they would see the brilliance of the solution.” Are you asmug enough Lisp weenie to think that if people really understood Lisp theywould 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 alot of people the fact that different languages can offer different things. Andthere are good reasons to make choices among them rather than to hold upone language and say, “This is the winner.”

There are certain kinds of projects that I would not want to tackle withanything other than Lisp because I’m interested in the set of tools itprovides me. For instance, ready-made input/output—if I’m willing toconform to Lisp’s syntax, then I’ve already got readers and printers builtthat are adequate for some kinds of jobs. This in turn allows you to dosome kinds of rapid prototyping. On the other hand, if it’s important that Icustomize the I/O to an existing specific format, then Lisp might not be sucha good tool. Or else I might have to build some kind of transducer in somelanguage, Lisp or otherwise, to get it over to the Lisp world.

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

Steele: I earned my first money programming in COBOL. I was still a highschoolstudent and subcontracted to someone who was doing a report-cardgenerator system for another school system, so there wasn’t any conflict ofinterest there. I used Fortran, IBM 1130 assembly language, PDP-10 machinelanguage, APL. I guess I can’t claim to have used SNOBOL seriously.Certainly C, C++, Bliss, the DECsystems implementation language thatcame out of Carnegie Mellon. GNAL, which is based on Red, I’ve used quiteseriously.

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, whichwas one of the four or five that merged to make Common Lisp. I developedConnection Machine Lisp but I’m not sure I could be said to have doneserious coding in it. That was, I think, in turn implemented in ^*Lisp. ^*Lisp isnot to be confused with Connection Machine Lisp; they are two distinctlanguages.

I did some serious coding in C^*, which was another language we developedfor 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’veworked with a language for more than a month and tried to write asubstantial piece of code in it. Oh, FOCAL, an early interactive language onthe DEC computers, similar to… a little bit like BASIC, a little bit likeJOSS. I’ve done substantial coding in BASIC, now that I think about it. AndTECO, the Text Editor and Corrector, of course was used to program thefirst version of Emacs and I regard that as a programming language for thatpurpose. I wrote enormous amounts of TECO code. And TeX, alsoregarded as a programming language. Those would be the main ones, Iguess.