Ruby on Rails: Not So Productive?

Tuesday, May. 10 2005 | Author: Scrivs

I am sure we all know that on the web hype for any new technology can spread real quick. This was certainly the case with Ruby on Rails. Before Rails, Ruby was always behind Python on the hype meter, but after the introduction of Rails and it’s use by 37signals it seems everyone has jumped on board.

During these explosions of hype it’s always nice to see someone take a step back with a critical eye and run over the actual performance and productivity gains from using the latest hype technology. Magpiebrain does so and comes up with this conclusion:

This is by no means a fatal flaw - but when analysing the productivity gains of Ruby, the initial benefit of code generation should be seen as just that - an initial benefit. Rails will stand (or fall) based on Ruby itself - both its technologies, tools and workforce.

It’s a quick and interesting read and at the very least makes you think a bit more about what productivity gains really come from using Rails. A change in Ruby could impact the whole framework, but a lack of change in Ruby could stunt its growth.

Category: Uncategorized

One Response for "Ruby on Rails: Not So Productive?"

ct

May 11th, 2005 at 1:44 pm
1

They guy makes a sober, and limited argument about the /initial/ productivity gains attainable with Rails: “the obvious conclusion from which is that the (code) generation steps have to be considered to be a one-shot deal”.

That is reasonable, but you cannot dismiss the whole framework just because the impact of code generation is limited to the first stages.

And people keep equating Rails with Ruby. The argument has been made that Rails could not be without Ruby, but the language is a lot more than Rails. The author goes on to say down on the comments: “the only thing that makes Rails libraries better/easier to use/more elegant than the Java alternatives is the language itself,”.