Rapid Red

Your rapid development experts

Ruby on Rails by proven experts.

From Java to Ruby: Programmer's view

From Java to Ruby is now at the printers! My strong belief is that the Ruby revolution is being driven by developers, but many technology decisions are made by managers. From Java to Ruby is all about articulating real business value to managers. If you’re interested in Ruby but have no idea how to sell it into your business, From Java to Ruby can help.

Over the next couple of weeks, I’m going to be writing a series of articles describing why I think Ruby is significant to Java developers, managers, and even business people. In this short entry, we’ll start with programmers.

By far, the biggest engine behind the emergence of Ruby on Rails is productivity. Java made early inroads offering good productivity to people seeking to do Internet development.

Ramping Up
You can immediately see hints regarding productivity right out of the gate. With Java, long ago, you could crack open a servlet example and get your initial web-based application up in mere hours. Java is no longer approachable for that problem space. If you want to build your application “the right way”, you need to download frameworks to handle persistence, integration (such as Spring or EJB), MVC (Struts, Tapestry, WebWork or the like), templating (JSP or proprietary), and the like. You’d need to ramp up on development tools, including JUnit, Ant, Eclipse, and possibly something like Mavin. This challenge is daunting to experienced developers, and all but impossible for new developers. With Ruby, the situation is a little different. Since the framework is integrated, you can get all you need with a few short downloads. Ruby Gems is tailored to let you pull together all dependencies quickly, with minimal ramp up. Contrast that with Java, where you need to learn a whole new development paradigm with Eclipse, or a new build system with Maven to get a similar capability. These tools are both good for the expert, but will not help new developers much at all.

Doing Work
When it’s time to do real development, if you’re building database-backed web applications, Ruby on Rails is hands-down a much more productive way to build code. With Rails programming conventions (instead of XML configuration), Ruby developers repeat themselves less and can focus on the business aspects of a particular problem more. The Rails component models make Ajax much easier than with most Java frameworks, and the Rails templating system makes web development much easier. With Rails conventions, you need to write only a fraction of the code that you’d need with Java. Testing is easier to set up, and the dynamic nature of Ruby makes testing easier to do.

But the advantages of Ruby don’t begin and end with Rails. The Ruby programming language makes it easy to do things that are much more difficult with Java. Consider the time and energy spent on aspect oriented programming, dependency injection and annotations. These frameworks solve problems that Ruby developers simply don’t have. Ruby’s mix in model and open classes make it easy to quickly add interceptors, introduce capabilities, or add crosscutting concerns. Ruby’s open classes make it easy to change a class in subtle ways so dependency injection isn’t (ed: make that dependency injection frameworks are not) necessary. Just last week, I changed Date to return ground hog day at each request with only five lines of code, making a set of test cases repeatable. And Ruby’s ability to add domain specific languages, like the ones for mapping in Rails, make annotations look like child’s play. In short, instead of wrapping up thousands of man-days in projects to make a language more dynamic, Rails is built on a more dynamic language.

Maintenance (long-term productivity)
Java has held off the dynamic languages for two reasons: either the prospective language wasn’t popular enough, or the prospective language was not perceived as clean enough. Ruby is not some quick-and-dirty scripting language. In fact, in many ways, Ruby is cleaner than Java:

  • Ruby has one overall type strategy: everything is an object. You don’t have to build special cases to deal with integers, arrays, and objects.
  • Ruby has closures. It’s easy to deal with problems that need short, concise code blocks. Database access, XML, collections and many other types of code are much easier to use within Ruby because of code blocks.
  • Ruby has symbols. Once again, Ruby lets you raise the abstraction of how you deal with the real world.

I could go on, but the meaning is clear. Ruby lets you express many ideas much more cleanly than you can in Java.

Lines of Code
One of the biggest surprises to me when writing Java to Ruby was the idea that lines of code matter. Java developers often say they don’t have to deal with lines of code because their IDE or code generators create the code for them.

Code generation, in your IDE or from a script, don’t get you as far as you need to be. Lines of code matter to the eyes that read them, the tools that must process them, and the programmers that maintain them. With more lines of code, your application will take proportionally (maybe even exponentially) longer to write, contain more bugs, and force a larger team to manage the overall effort.

Another surprise in From Java to Ruby was the idea that having five billion frameworks around to solve every problem is a benefit for Java, and also a huge limitation. Too much choice is a symptom of a larger problem. When one framework exists to do a job, if it does the job well, you won’t see choices emerge. JDBC, JMS and JTA are all examples of good abstractions that have cornered their market. This idea leads me to believe that the Java community still does not have web development right yet. In particular, Web MVC frameworks are out of control, but you can also look to choices in other places. EJB or Spring? JPA or Hibernate? Hibernate or iBATIS? What remoting is the most attractive? ReST or full-stack web services? Which XML binding strategy? Annotations or configuration? All of these questions have underlying architectural implications that are not immediately available on the surface.

In several instances, Ruby development teams have implemented some services from scratch that might on the surface have guided the team toward Java. I talked to two teams who implemented a database driver, and another team implemented a custom caching layer and a reporting component.

Ruby + Rails
Every ten years or so, it’s healthy to start with a clean slate and rebuild based on a cleaner, simpler foundation. That’s exactly what’s going on within the Ruby community. Java programmers have noticed because they can do the same work with much less effort. But the developers don’t always make the technical decisions. In the next article, we’ll look from the perspective of a manager, addressing risk and resistance.