Seibel: And what has changed?

Bloch: Well, it’s hard to make your programs readable when you’rerestricted to single-character variable names. So I worry more aboutvariable naming now. Obviously, as you use languages with new features,many things change. And things that you vaguely understood over the yearsreally get slammed home.

For example, don’t repeat yourself. I was freer with the copy-and-paste backthen than I am now. Now I really try not to do it at all. That’s a little bit ofan overstatement, but only a little bit. Generally speaking, if I find myselfcopying and pasting, I think, ”What’s wrong with this design? How can I fixit?” So that’s something that took a little while to get right. Basically I’vebecome harder on myself over the years—that’s what it takes to write goodprograms. You really can’t accept bad habits from yourself.

Seibel: If you were going to go back in time and do it all over again, is thereanything you wish you had really done differently? The BASIC didn’t braindamageyou or anything?

Bloch: No, actually that’s a funny thing. I think Dijkstra, God rest his soul,was entirely wrong about that. I know so many really good programmerswho got their start programming BASIC because that’s what was availableto them.

I do think it’s good to use lots of languages, though. By the time I was incollege, I was programming a whole bunch of them. Each course you woulddo in a different language. In a numerics course or a science course, you’duse Fortran. If you were taking a programming course back then, it wasPascal or SAIL or Simula or something like that. In an AI course, it was Lisp.

But maybe I should have learned more languages. It’s funny—I didn’t reallyget into the object-oriented thing until late in the game. Java was the firstobject-oriented language I used with any seriousness, in part because Icouldn’t exactly bring myself to use C++.

Seibel: When was that?

Bloch: Starting in ’96 when I joined Sun. I think it would have been good tolearn those concepts a little earlier than I did. That said, I don’t think allthose concepts are good. OO is a funny thing. It means two things. It meansmodularity. And modularity is great. But I don’t think the OO people canclaim the right to that. You can look at older literature—for exampleParnas’s information hiding—and see that the notion of a kind of class as anabstraction predates object-oriented programming. And the other thing isinheritance and I consider inheritance a mixed blessing, as many people doby now.

Also I should have exposed myself to more areas, inside and outside ofcomputer science. The more things you learn and the younger you learnthem, the better off you are. One thing I’ve never really done much of isGUI programming and I should have forced myself to do that at some point.But for whatever reason, libraries have appealed the most to me over theyears, writing the building blocks for other people to use. So I’ve been doingdata structures and algorithms and so forth for decades.

Seibel: Are there any books that every programmer should read?

Bloch: An obvious one, which I have slightly mixed feelings about but I stillthink everyone should read, is Design Patterns. It gives us a commonvocabulary. There are a lot of good ideas in there. On the other hand,there’s sort of a mish-mash of styles and languages, and it’s beginning toshow its age. But I think it’s absolutely worth reading.

Another is Elements of Style, which isn’t even a programming book. Youshould read it for two reasons: The first is that a large part of everysoftware engineer’s job is writing prose. If you can’t write precise, coherent,readable specs, nobody is going to be able to use your stuff. So anything thatimproves your prose style is good. The second reason is that most of theideas in that book are also applicable to programs.

My desert-island list is a little bit odd. For example, a book that’s terriblyimportant to me is Hacker’s Delight, by Hank Warren.

Seibel: That’s the bit-twiddling book?

Bloch: Yes. I love bit twiddling and it’s relevant to what I do. If you writelibraries, compilers, low-level graphics, or crypto, this book is indispensable.Warren has taken what used to be an oral tradition, put it all in one place,and given it the rigorous mathematical treatment that it deserves. I wasthrilled when that book was published.

Of course there’s Knuth’s The Art of Computer Programming. In truth, Ihaven’t read the whole series or anything close to it. When I’m working ona particular algorithm, though, I go there to see what he has to say about it.And often it’s exactly what I need—it’s all in there.

But I simply don’t have the capacity and speed to read through all of it, soI’d be lying if I told you I had. An old book that I think is great is TheElements of Programming Style, by Kernighan and Plauger. All the examplesare in Fortran IV and PL/I, so it’s a bit out-of-date. But it’s amazing, given theage of the book, the ideas are all still current.

Another old one is Frederick Brooks’s The Mythical Man Month. It’s 40 yearsold and still as true today as when it was written. And it’s just a joy to read.Everyone should read that. The main message of the book is “adding peopleto a late software project makes it later,” and it’s still true. But there are alot of other important things in it. Some of the details are beginning to age,but everyone should read it anyway.

These days, everybody has to learn about concurrency. So Java Concurrencyin Practice is another good bet. Although it has Java in the title, a lot of thematerial transcends any particular programming language.

Seibel: That’s the one you worked on with Brian Goetz?

Bloch: My name is on the cover but the reason I felt free to mention it isthat it’s not really my book. The lead author is Brian and then the secondaryauthor was Tim Peierls and the remaining ones are everyone who was onJSR-166, the Java concurrency people. But those are almost there forcourtesy—we contributed material but not prose to the book.

Oh, one more book: Merriam-Webster’s Collegiate Dictionary, 11th Edition.Never go anywhere without it. It’s not something you actually read, but as Isaid, when you’re writing programs you need to be able to name youridentifiers well. And your prose has to be good. I’d feel lost without a gooddictionary.

Seibel: Other than naming your variables better, and cutting and pastingless, is there anything else about how you approach programming that haschanged as you gained experience?

Bloch: The older I get, the more I realize it isn’t just about making it work;it’s about producing an artifact that is readable, maintainable, and efficient.Generally speaking, I find that, contrary to popular belief, the cleaner andnicer the program, the faster it’s going to run. And if it doesn’t, it’ll be easyto make it fast. As they say, it’s easier to optimize correct code than tocorrect optimized code.

Some of the changes in my approach are specific to languages. Everylanguage presents you with a toolkit. You want to use the right tool for thejob, and what would be the right tool in one language may not be the rightone in another. A trivial example: if you’re writing in Java 5, using enumsinstead of int constants or booleans can greatly simplify your program andmake it safer and more robust.

Seibel: Given that, can you say anything about how to speed up theprocess of getting to fluency in a new language?

Bloch: I think it’s a lot like spoken languages. One way is by knowing a lotof languages—if you already know Italian and Spanish and you want to learnPortuguese, you’re not going to have a very hard time doing it. The moreyou know, the more you have to draw on.