Cake Solutions Team Blog

Ruby eye for the Java guy

Ruby on Rails is a mature and innovative framework designed especially for the web. This allows rapid, stable and iterative web development. At Cake Solutions we use the latest technologies that ensure that websites developed on Rails will be built to specification, on-time and fully tested.

What’s in it for us, Java developers?

What is the fundamental difference between Ruby and Java? The main difference is that Ruby uses duck typing. The fundamental principle of duck typing is that “if it quacks like a duck, looks like a duck, then it is a duck”. In programming, this means that if an object responds to the signals we send it, then we have the correct type. Consider this code:

def foo(f)
   f < < "some text"
end

This signal handler (method) takes an argument f; the object f passed to the method must respond to the << operator. This means that we can call foo with an Array or a File, because both objects respond to the << operator.
"But," you say, "this feels too brittle. I prefer manifestly-typed languages such as Java, where the compiler will check the types."
First of all, manifest typing does not prevent type errors at runtime. If it did, there would be no need for a ClassCastException. The very existence of this exception means that even manifestly-typed languages do not guarantee type safety at runtime. Think about the collections framework in Java 1.4: the collections held just Objects and you had to do dynamic type casting. But how many ClassCastExceptions did you see at runtime and when you did, how difficult was it to fix it?
I put to you that manifestly-typed languages lull you into a false sense of security, where you believe that type errors cannot occur, because the compiler checks them, but I've shown that that is not strictly true.
With this in mind, why resist the typing freedom Ruby gives you? Look back at the foo method. To make the method as flexible as possible in Java, we would have to use some interface (Appendable) as its argument. But that requires a lot of fore-thought. In Ruby, you write code that deals with the typical situation (appending to a file, for example), but the same code can append to an array or a string, even if you never considered this in your design.
Finally, what makes code brittle? It is not the lack of compile-time type checking, it is lack of tests. Whatever language you use, I urge you to think of any code that is not tested as broken. From that follows that you both Ruby and Java can be equally robust, as long as you test your code.

The ecosystem

The libraries and frameworks available for any programming language largely determines its usefulness. Let's ignore the standard library and jump straight into web application development. Consider Spring Framework and Ruby on Rails. Ignoring the "enterprisey" features of the Spring Framework, both frameworks allow you to write web applications. But there is significant difference in the approach to writing applications in RoR and Spring Framework. Ruby on Rails has strong opinions about how you should write web applications. In Ani's famous words, "it's Ruby on Rails way on no way." A more subtle way of putting it is that RoR prefers convention over configuration. RoR's approach is that if it works for 99 % of the cases, it should work for you, too. RoR makes a lot of choices for you. For example, in Spring, to write CRUD code for a domain object, you have to write (in no particular order): the controller, couple of JSPs, web.xml, repository interfaces and their implementation, their Hibernate implementation and Hibernate mappings; ideally you will also have a services tier to isolate your controllers from the database. In other words, a lot of code.
In RoR, you run script/generate DomainObject title:string body:text. This generates the "domain object", database structure, the controllers and views, all automatically, because RoR has strong views about how you should write your code.
In Spring, you can use the Spring MVC annotations or you can use XML configuration; hey, you can even replace the DispatcherServlet with your own creation. But why would you want to? In most cases, you're paid to get the CRUD operation done, not to mess with the framework.

Does that mean you don't like Spring any more?

Absolutely not; we are still Java EE developers at heart. We are keen to use Spring's power for middleware, where we can take advantage of AOP, transaction management, JMS, JMX, Hibernate and all other big guns. For the front end, though, we are keen to use something simpler.
That something must be more flexible, more efficient. And that for us is Ruby on Rails and Grails!