What Java Should Learn From Ruby and Rails

PostsWhat Java Should Learn From Ruby and Rails

I hate to say this, but Java has gotten a bad rap among some programmers. It’s deserved at times, but it’s worth noting that it’s often more about the people behind Java than the technology itself.

Here’s an example. Clearly, this is horribly wrong. Sun refuses to fix a bug because people have worked around it, thus it must be maintained–to the detriment of all programmers to follow. This gradual growth of cruft is one thing that has driven people away from Java.

Why is this important to me? Well, it’s mostly important because I think that it prevents good comparisons of technologies. It sends the wrong message when people move to Rails because Java is riddled with unnecessary complexity and buggy libraries. While it is some compliment that it says that Ruby is easy to use compared to Java, it doesn’t emphasize what makes Ruby such a different way of doing things.

Real improvements like reduction in code through expressiveness, flexible extension of types, the block syntax, et cetera get lost in the shuffle. What’s worse, it doesn’t send the message that Ruby can be used to solve industrial problems. The eternal mantra of the Ruby naysayers–that it doesn’t scale–is at least partially reinforced when people flock to it for simple projects.

For those who have built scalable applications on top of Ruby, this is laughable. Yet the point remains that dynamic languages in general and Ruby in particular have a great deal of value to deliver to real, serious software development. Even though it’s fun to play with, it’s not just a toy.

Similarly, when people legitimately work on projects like JRuby that work gets ignored by people who just don’t want to deal with the cruft. While that’s a great reason to avoid a class-library, it’s a horrible way to allocate our resources as an industry. In a world where languages live or die by their “standard libraries”, this just makes people’s lives harder and guarantees that we spend more energy to move the same distance.

I can only hope that Oracle’s recent acquisition of Sun might change this attitude and position Java as a more useful technology. It’s a shame to see all of the hard work people have put into the JVM be squandered because some people are afraid to break an API. If anything, this could have been turned into an opportunity for Java to offer versioned APIs, but instead it was met with duplication of functionality and degradation of the clarity of their class library.

I feel that this puts work on Rails 3 in an important light. The Merb project was about a lot of things, but one of its most important aspects was that the people behind it continued the march towards a better product. The Rails core team did a great thing by welcoming the best of Merb into Rails. It’s letting us build a better future, and it’s showing that we can maintain compatibility and still move forward.

We just need to always be mindful that the day that we stop improving Rails is the day that someone starts writing its replacement. More than anything, we need to insist that there is no excuse for not fixing a bug.

About Jayson Vantuyl

I live in San Francisco, California; have an awesome son, David; and make machines do (subjectively) interesting things. I'm generally an all around handy fellow.

Leave a Comment

Your email address will not be published. Required fields are marked *