I've been playing around with Ruby, and I like it. Ruby is powerful and simple. I haven't spent much time figuring out how to get the language to do what I want like I would with Java. Instead, I just do what I'm trying to do, without focusing so much on how.

For example, if I want to build lists of a custom objects, and allow sorting and filtering, I only add one simple method to my object definition to get a ton of cool comparison behavior for free. In Java, I have to do a lot more work, and the results aren't as good, or maybe I decide against proper code organization in Java in favor of some gross, hacky solution that's quick and dirty.

So it's interesting to hear people defend Java. "Oh come on, Java's not that bad", "you're just a Ruby zealot!", "I can do all of that in Java", blah blah blah. To an extent, those comments are correct. But what do they really mean?

"Oh come on, Java's not that bad"
Fine. I'll agree that Java is not that bad. But take this argument a little further. We can build a world-class application in C, Lisp, or Haskell almost as easily as Java. There are plenty of rich libraries of functionality that we can leverage in other languages, so we're not going to 'reinvent the wheel' as is often hyped with OO languages like Java. In reality, the language choice doesn't matter that much. It's not like software development didn't exist before Java. I know several viable software shops here in Austin that are using languages other than Java (including C++, Ruby, Php, Python, ...). The attitude of "software can only be done in Java" is just silly. The heart of this comment is really a posture of defensiveness. I don't care if you say your tools are better than mine, I like Java just fine, I'm not gonna change, you leave me alone!

"You're just a Ruby zealot!"
Say that I am in fact a zealot, I can't shut up about how great Ruby is, I'm sooo excited about the language. Say all of that is true (it mostly is). Here's the big question: what the hell is wrong with that? As long as the language will handle the technical requirements of the project, it's great for the developer to be excited about the tools, excited about building the software, excited about how much he loves doing his work. Java is not exciting. It's big, fat, and bloated. Being a zealot is not a bad thing, and is often quite powerful. You should be happy that your team is excited about doing work on the basis of the tools alone. Happy developers = Good work = Successful company.

Of course, there are practical realities that cannot be ignored - the team may not know Ruby (or whatever language / tool is on the table), there might be a large, pre-existing code base, business demands may prevent the ramp-up to use a new language. All of that stuff is valid, and may very well trump the excited zealotry of the team over Ruby. That's a trade-off you have to make. Happy, excited, forward progress vs. business needs, collective team knowledge. No right answer for everyone, but it's definitely not bad to have zealots. In fact, you should probably always have a few, otherwise you'll be driven by your marketing people or stupid articles about business trends. I don't care how many shops are using Java, it still might not be the right choice for our group. The number one language in terms of lines of code on the entire planet is Cobol (thank you, military), but that means nothing for my software group. Without a zealot among you, you're likely to end up being another sheep in the flock, doing what everyone else is doing. That's bad. This is exactly what Dave Thomas was talking about in his keynote address at NFJS earlier this year. Angry monkeys, indeed.

"I can do all of that in Java"
I'm sure you can, but that's not the point. Think of any task you do in a day (at home, at work, where ever), and consider how many different ways you could achieve the same result. I'm sure you can think of several options. But which one do you choose? The fastest, simplest way to get the correct results. It's an almost unavoidable aspect of human nature - we tend toward the shortest path, and that tendency grows stronger with increases in stress or pressure. In a work context, this means people will favor "getting it finished" over "doing it correctly". Happens all the time in software. TODO: fix this! it's gross and inefficient, need more time to do it right! This is exactly why we have "best practices" in software, and simultaneously why almost nobody follows those practices.

So after I've built something in Ruby, and you've built it in Java, I'll have moved on to think about adding new features, and you'll be reading through javadoc about which package to use, or how to work within Java's linguistic constraints to do what I've already done in Ruby. In the end, we'll both have code that achieves the same result, but mine will be shorter and simpler, and therefore easier to understand, maintain, and extend. And I'll have had an easier time building new stuff because my head was less involved with "Ruby" and more involved with my problem domain, so it will take less mental effort to make more forward progress.