Seibel: And what has changed?

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

For example, don’t repeat yourself. I was freer with the copy-and-paste back then than I am now. Now I really try not to do it at all. That’s a little bit of an overstatement, but only a little bit. Generally speaking, if I find myself copying and pasting, I think, ”What’s wrong with this design? How can I fix it?” So that’s something that took a little while to get right. Basically I’ve become harder on myself over the years—that’s what it takes to write good programs. 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 there anything you wish you had really done differently? The BASIC didn’t braindamage you 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 programmers who got their start programming BASIC because that’s what was available to them.

I do think it’s good to use lots of languages, though. By the time I was in college, I was programming a whole bunch of them. Each course you would do in a different language. In a numerics course or a science course, you’d use Fortran. If you were taking a programming course back then, it was Pascal 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 really get into the object-oriented thing until late in the game. Java was the first object-oriented language I used with any seriousness, in part because I couldn’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 to learn those concepts a little earlier than I did. That said, I don’t think all those concepts are good. OO is a funny thing. It means two things. It means modularity. And modularity is great. But I don’t think the OO people can claim the right to that. You can look at older literature—for example Parnas’s information hiding—and see that the notion of a kind of class as an abstraction predates object-oriented programming. And the other thing is inheritance and I consider inheritance a mixed blessing, as many people do by now.

Also I should have exposed myself to more areas, inside and outside of computer science. The more things you learn and the younger you learn them, the better off you are. One thing I’ve never really done much of is GUI 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 the years, writing the building blocks for other people to use. So I’ve been doing data 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 still think everyone should read, is Design Patterns. It gives us a common vocabulary. 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 to show its age. But I think it’s absolutely worth reading.

Another is Elements of Style, which isn’t even a programming book. You should read it for two reasons: The first is that a large part of every software 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 that improves your prose style is good. The second reason is that most of the ideas in that book are also applicable to programs.

My desert-island list is a little bit odd. For example, a book that’s terribly important 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 write libraries, 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 was thrilled when that book was published.

Of course there’s Knuth’s The Art of Computer Programming. In truth, I haven’t read the whole series or anything close to it. When I’m working on a 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, so I’d be lying if I told you I had. An old book that I think is great is The Elements of Programming Style, by Kernighan and Plauger. All the examples are in Fortran IV and PL/I, so it’s a bit out-of-date. But it’s amazing, given the age of the book, the ideas are all still current.

Another old one is Frederick Brooks’s The Mythical Man Month. It’s 40 years old 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 people to a late software project makes it later,” and it’s still true. But there are a lot 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 Concurrency in Practice is another good bet. Although it has Java in the title, a lot of the material 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 is that it’s not really my book. The lead author is Brian and then the secondary author was Tim Peierls and the remaining ones are everyone who was on JSR-166, the Java concurrency people. But those are almost there for courtesy—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 I said, when you’re writing programs you need to be able to name your identifiers well. And your prose has to be good. I’d feel lost without a good dictionary.

Seibel: Other than naming your variables better, and cutting and pasting less, is there anything else about how you approach programming that has changed 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 and nicer the program, the faster it’s going to run. And if it doesn’t, it’ll be easy to make it fast. As they say, it’s easier to optimize correct code than to correct optimized code.

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

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

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