(Brace yourself for a long-winded "my language kicks your language's ass" diatribe.)

Yesterday in an interview I had the opportunity to ask a candidate the ever-controversial "What's your favorite language?" question. He had an answer that was reasonable from a certain perspective. He thought PHP and Ruby were his favorites, and cited their ability to do regular expressions, work on the web, etc.

This is what I hear argued all the time. More mature engineers eventually become language-agnostic, citing that using the right tool for the right job is more important than waging any kind of syntactic holy war over whitespace and duck typing. And I agree with that viewpoint.

Mostly.

Yesterday's interview made me realize that these arguments are often missing the forest for the trees. For example, I think you could have a long, boring argument about whether the following snippet is easy or hard to understand, and would be faster/shorter/simpler/more elegant in Python or Perl or PHP or whatever:

This is where the "right tool for the right job" pattern applies best. But you know what? Writing and understanding a page of code is just not a particularly tough problem. You want to see a tough engineering problem? Try this:

I know it's uncool to like anything but Ruby right now, but the fact is that if you look at all your choices today for building a project of any real size (let's say, over 40,000 lines of code) that's going to be maintained by more than just one or two people, is going to integrate a bunch of off-the-shelf libraries, or is going to be maintained for more than a few months, one language has successfully built a culture around itself that stands above all the rest.

The Java designers declared Martial Law when it comes to organizing code. Code must be in Methods. Methods must be in Classes. Classes must be in Packages. There is only ONE way to get code into the system, and that's through the ClassLoader. The ClassLoader has some flexibility, but they made the best way to structure a large system also the easiest one by far--- .JAR files. JAR files have a very simple format and are almost always found in one way, which is through the classpath.

This structure has lots of flaws, but it's unbelievably consistent across 99.9% of all of the Java code that exists today. That means that if you learn Java, you can integrate any 3rd-party Java library, step into any Java project, any Java job, any Java company, and have a good shot at understanding what's going on. You can use all the same tools, all the same techniques, and apply all of the same reasoning. In a pinch, you can even decompile your 3rd-party libraries to discover APIs and bugs. And it's so effective that even very large Java projects do not need much of a build system. You contrast that to any big project in C++, and you will just cry.

No other language has this kind of success with scale, and most don't try. Script kiddies don't like having to bow to a despotic structure like Java's, and admittedly for single-owner and smallish script projects, the structure burden is onerous and usually needless. But I'll bet most engineers with the scars of a large, old system on their backs would kill for a chance to convert their projects to Java.