Recently I was in a conference room with the CIO of a large corporation and representatives from a vendor that provides a somewhat unrelated product. The corporation's software is mainly in Java. For some reason, in the middle of the discussion, one of the vendor's 20-something presales engineers started pitching that the company rewrite all of its software in Ruby.
The reason? It would result in higher developer productivity.
[ Also on InfoWorld: Ruby's creator sets his sights on mobile. | InfoWorld's Test Center reviews Ruby in the cloud, as deployed by Engine Yard and Heroku. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
The proposition that this company would rewrite millions of lines of Java code in Ruby to realize "developer productivity" was absurd. Not surprisingly, the CIO decided he had "another meeting" and excused himself.
This isn't an isolated presales engineer. Productivity benefit has been the pitch for most "new" high-level languages for some time. The Ruby community especially likes to beat this drum.
I think it's time for a new sales pitch for Ruby -- and for most high-level languages. Developer productivity is a weak pitch in a multideveloper project, not to mention a ridiculous approach when rewriting code is required, because the costs will long outweigh the benefits. The Ruby community, in particular, needs to outgrow this argument, mainly because Ruby has other, better points in its favor.
Once upon a time, developer productivty was indeed a rational argument for choosing one language over another. When we moved from Assembly to C, for instance -- we're talking a major reduction in finger ache, let alone not having to manage the stack. When we moved from C++ to Java, not having to manage memory was huge. But the individual productivity difference from Java to Ruby is comparatively small. Don't get me wrong, Ruby has an edge -- which might increase as Java grows more complex and Ruby loses more of its rough edges (as with jRuby) -- but it will never be rewrite-the-project-sized margin.
