Seibel: As a Java guy at Google, do you think it could be used more?Leaving aside the force of history and historical choices, if somehow youcould wave a magic wand and replace all of the C++ with Java, could thatwork?

Bloch: Up to a point. Large parts of the system could be written that way,and over time, things are moving in that direction. But for the absolute coreof the system—the inner loops of the index servers, for instance—verysmall gains in performance are worth an awful lot. When you have thatmany machines running the same piece of code, if you can make it even afew percent faster, then you’ve done something that has real benefits,financially and environmentally. So there is some code that you want towrite in assembly language, and what is C but glorified assembly language?

I’m not religious. If it works, great. I wrote C code for 20 years. But it’smuch more efficient, in terms of programmers’ time, to use a more modernlanguage that provides better safety, convenience, and expressiveness. Inmost cases, programmer time is much more valuable than computer time.

But that isn’t necessarily so if you’re running the same program on many,many thousands of machines. So there are some programs that we writewhere probably using less-safe languages to extract every ounce ofperformance is worth it. I think for most programs these days theperformance of all modern languages is a wash and if anyone tells you thattheir language is ten times more efficient, they’re probably lying to you.

But in terms of efficiency, in terms of use of engineers’ time, it’s far from awash. More modern languages, first of all, are exempt from large classes oferrors. Second of all, they have marvelous sets of tools which makeengineers more efficient. To some degree it’s cultural; it’s what languagespeople learned in schools. But to some degree I think it’s actuallyfundamental engineering at work. For example, if a language has a macroprocessor it’s much harder to write good tools for it. Parsing C++ is amuch trickier business than parsing Java.

Google is writing a lot more of its code in Java now than it used to. I don’tknow what the numbers are, but if the lines haven’t already crossed, theywill soon. So there’s a big difference between how many lines of code do wehave in each language versus how many cycles are getting executed in eachlanguage. And I think it would be a fool’s errand and not particularlymeritorious, either, to try and get the inner loops of the indexing serverswritten in Java. If you were starting a company to do this sort of thing today,you might write things largely in Java or in some other modern, safelanguage, and then escape it when you needed to. But we have thisengineering infrastructure. Libraries and monitoring facilities and all of thatstuff that makes it go. And finally Java is, if not an equal partner in this, it’sreasonably usable within these systems, which is good. When I arrived thatwasn’t the case yet.

Companies establish their DNA very early on. It can make themtremendously successful, but it can also make it hard for them to escapewhen what served them well in the early days doesn’t serve them so wellany more. I remember being an intern at IBM Research in YorktownHeights around 1982, seeing the culture still dominated by batch processing.Even when they were doing timesharing, they talked in terms of virtual cardreaders and virtual card punches. Everything was still 80-column records.With DEC, it was the timesharing mentality that they never escaped. And Isuppose with Microsoft it’s an open question whether they’ll be able tomove beyond the desktop-PC mentality.

Seibel: And 20 years from now people will be talking about how Googlecan’t get past how to sell ads on the Internet.

Bloch: Absolutely. Anyway, there was this sort of cultural meme at Googlethat Java is slow and unreliable. And it’s obvious where it came from:Blackdown Java on Linux, around 1999, was slow and unreliable. And oldideas die very hard. Although the truth is, Google uses Java for many sortsof business-critical functions, including, by the way, ads.

So at some level they understand that it’s neither slow nor unreliable. Butthe actual search pipeline, which is the most intense in terms of machinecycles, that stuff is all basically C++ and there’s an obvious reason having todo with the genesis of the company. And I think that will continue to affectus for quite some time.

Seibel: What are the tools you actually use to program?

Bloch: I knew this was coming; I’m an old fart and I’m not proud of it. TheEmacs keystrokes are wired into my brain. And I tend to write smallerprograms, libraries and so forth. So I do too much of my coding withoutmodern tools. But I know that modern tools make you a lot more efficient.

I do use IntelliJ for larger stuff, because the rest of my group uses it, but I’mnot terribly proficient. It is impressive: I love the static analysis that thesetools do for you. I had people from those tools—IntelliJ, Eclipse, NetBeans,and FindBugs—as chapter reviewers on Java Puzzlers, so many of the trapsand pitfalls in that book are detected automatically by these tools. I think it’sjust great.

Seibel: Do you believe you would really be more productive if you took amonth to really learn IntelliJ inside out?

Bloch: I do. Modern IDEs are great for large-scale refactorings. Somethingthat Brian Goetz pointed out is that people write much cleaner code nowbecause they do refactorings that they simply wouldn’t have attemptedbefore. They can pretty much count on these tools to propagate changeswithout changing the behavior of the code.

Seibel: What about other tools?

Bloch: I’m not good with programming tools. I wish I were. The build andsource-control tools change more than I would like, and it’s hard for me tokeep up. So I bother my more tool-savvy colleagues each time I set up anew environment. I say, “How do you do it these days?” They roll theireyes and help me and I use the environment until it doesn’t work anymore.

I’m not proud of this. Engineers have things that they’re good at and thingsthey’re not so good at. There are people who would like to pretend thatthis isn’t so, that engineers are interchangeable, and that everyone can andshould be a total generalist. But this ignores the fact that there are peoplewho are stunningly good at certain things and not necessarily so good atother things. If you force them all to do everything, you’ll probably makemediocre products.

In particular there are some people who, in Kevin Bourrillion’s words, “lackthe empathy gene.” You aren’t going to be a good API designer or languagedesigner if you can’t put yourself in the shoes of an ordinary programmertrying to use your API or language to get something done. Some people aregood API and language designers, though. Then there are people who arestunningly good at the technical aspects of language design where they cansay, “Oh, this will make the thing not LALR(1) and you need to tweak it injust such a way.” That’s an incredibly useful skill. But it’s no substitute forhaving the empathy gene and knowing you have this awful language that’sunusable.

I know other people who are stunningly good at extracting that lastpercentage of performance. You want to put them in a position wherethat’s what they’re doing. They’ll be happy and they’ll do good stuff for yourcompany. I think you’ve got to figure out what your engineers are good atand use them for that. So that’s my apologia for why I suck at tools. Lame, Iknow.

Seibel: Let’s talk about debugging. What’s the worst bug you ever had totrack down?

Bloch: One that comes to mind, which was both horrible and amusing,happened when I worked at a company called Transarc, in Pittsburgh, in theearly ‘90s. I committed to do a transactional shared-memoryimplementation on a very tight schedule. I finished the design andimplementation on schedule, and even produced a few reusable componentsin the process. But I had written a lot of new code in a hurry, which mademe nervous.