Paul Graham has stirred up a hornet's nest when he wrote in his essay "Great Hackers" that:

Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero.

I read through his essay and I agree with many of the observations that he brings forward. The biggest confusion I see though is his definition of the word "Hacker". To better understand what he means, let's look at his other essay "Hackers and Painters", where he writes:

Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they're doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers-- studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters.

So his definition boils down to people who have the capability of building software of beauty and value. However his reasoning about the limitations of people who write in Java is circumferential at best. His argument about Java is that it's not good enough as a medium of expression. I would agree that there are areas that need enhancement. Java has always been designed for the masses. To reason that it limits expressability therefore no hacker voluntarily uses it, is a bit of a stretch. Just take a sample of this list of "Most Valuable Personalities in Java", most of them in my opinion have achieved some kind of "Hacker status". Also, what about Joshua Bloch or Adam Bosworth, most prominent Java practitioners, aren't they not "hackers"? After all they qualified to get into Google, the place where Graham claims the better hackers go.

The important question though is this "Is Java sufficiently limiting that you can't build software of beauty and value?". To answer that question, we don't really have to look very far, you can find it in his own paper. Paul Graham writes:

Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications. This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department. The toolmakers would have users, but they'd only be the company's own developers.

There's a not too well known company called Object Technology International (OTI). This company has possibly the most innovative and experience object oriented practitioners in the world. People think that it's IBM that built Eclipse, that's somewhat true, but the more precise truth is that OTI built Eclipse and OTI just happens to be an IBM subsidiary. A subsidiary that is isolated from the larger organization to build innovative products. Nothing has ever been built in Lisp, Python or any other "Hacker" language that comes even close to the innovation in the Eclipse platform. I challenge anyone to point one out.

The point is, "limits of expression" is not all bad. In fact, the main architecture of Java is to support collaboration. That is, it has an "Architecture of Participation". If one considers hacking as solely an individual activity, then the limits of expression does have a non-negligible impact on productivity. However, when we involve groups of people, then a language that supports communities bests out a "Hacker" language.

However, the power of a language doesn't solely rest on its expressibility. Since software development is always practiced best as an iterative activity (as opposed to write-only in Perl), a language that supports this will beat out one that doesn't. That's why, despite the more powerful language constructs in other languages like Ruby or Python, these languages aren't going to win if they aren't going to get the slice and dice capabilities you find in Eclipse. Till then, these languages should be content to confining themselves to small projects.

It'll be interesting to see how bigger projects based on languages like Python will fare. So far, the Chandler project which was announced with a lot of fan fare is not progressing very briskly. May I suggest writing some sophisticated refactoring tools first (albeit in Java).

Finally, let us point out Paul Graham's fatal flaw. Software has a lifecycle, some time in that cycle, it eventually hits maintenance mode. This is the point where no hacker will be caught dead holding the bag. He writes:

It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

The kind of work that you'll find in many projects is that there's some work with some kind of legacy code. Also, today's software will always become someeone else's legacy. That's exaclty what happened to Paul Graham's ViaWeb. It eventually became legacy, and when the hackers refused to maintain it, then they needed to hire non-hackers who re-hacked it in Perl and C++. The lesson here is that, successful projects are ones that can easily be maintained by average programmers. The flaw in Graham's argument is that he's figured out how to win the war but overlooked how to win the peace.