Reblog

How Ruby gems boost productivity

The other day I was considering the huge amount of tiny gems and plug-ins that the Ruby and Rails community produces compared to the world of other more “enterprise” languages like Java or C#. One of the main differences seems to be the size: a gem can be anything from a dozen lines up to a fully featured self-contained component. I don’t have numbers to support this right now, but I have the impression that the average Java library is usually much bigger that the average gem.

One of our Rails project at the studio is a kind of receptacle for bleeding edge Rails plugins: if while reading the news I find a new cool “fu” gem you can be pretty sure that it’s already installed and running in production thanks to Nate :) The same often happens with Java projects: it’s easy to find a web application war file of 80+ megs full of “lightweight” Java libs. So while the Java application increases in size of a few megabytes for each new library, the increase in size in the Rails application typical plugin is barely noticeable (and sources/docs are always part of the installation).

I think the reason of this difference is that in Java the price of having dependencies is much higher than Ruby so a Java developer thinks twice before adding another dependency on the classpath. If you think about it it’s just a couple of years that the Java community is creating smarter building tools. But before Maven was just a pain for large projects driven by Ant. 

The conclusion is that in Java the adoption threshold for a new library is much higher. In other words the library must embed a consistent added value to enter the project while libraries with a bunch of helpers methods are worth re-writing instead. This is exactly the opposite of a Rails plugin: there are tons of them consisting of few lines of code, solving everyday Rails problems, which are happily packaged and used as gems. Therefore gems are fine-grained compared to the average Java lib.

There are amazing side-effects of having fine grained gems:

• the Ruby community experiences a short satisfaction cycle effect which, I think, is the most powerful motivation booster.
  
• the Ruby community can benefit right away of quick fixes of everyday programming issues without waiting for the next light-weight framework.
  
• Ruby gems are low-ceremony packages in which installing instructions are almost like following an IM transcription by the developer. This brings a sense of enlarged team that again boost productivity.

In conclusion: why Ruby allows for fine-granularity community support? At the root I think there is the complexity of the class-path mechanism for static typed languages that renders dependency management of libraries so cumbersome. Without an easy way of loading classes you have to pay much more attention during the building process about what dependencies you introduce and in which order. Also the fact that the rubygems support was there from the beginning and is almost part of the language is for sure another strong point.