Is Ruby on Rails Maintainable?

kale77in asks: "I've become a big fan of Ruby over the past few months, but I'm not at all sure about Ruby On Rails. Automatic code generation sets of alarm bells in my mind; so that, to RoR's promise of 'Web Development that Doesn't Hurt', I automatically add '...until you have to maintain it'. On the other hand, some writers and coders I respect (like the Pragmatic Programming mob) seem to be fans. I've mainly written generators in Python, to produce PHP/SQL/Java from SQL files, but I've always gone back to well-constructed objects, where extension and overloading offers more precise and maintainable customization than auto-generation allows. So is Rails just a nice RAD tool for disposable, cookie-cutter apps (which have a place, of course)? Is high-level generation just a bad OO substitute? And what has your experience of Rails' maintainability been?"

Comments

Yes, very

[Bruce Perens]

Maintainability is a combination of several factors. Most important is: can you read and understand the code? Ruby on Rails wins in this category because it's brief - smaller and thus easier to comprehend than Java - without being cryptic like APL. Second most important is: is it easily modified? Here Rails wins again, because of the say it only once philosophy and because of Ruby's duck typing *. Say-it-once means that you don't have to track down the other places where you've had to say the same thing (as in Java) and change them. Duck typing means you can change an object substantially without the user of that object seeing the change, because the user only knows what methods the object is expected to respond to, not the object's type.

Bruce

* Duck typing: If it looks like a duck and sounds like a duck, it's a duck! Object types don't matter to the users of Ruby objects. What matters is that the object responds to a particular collection of methods. This is something like virtual functions, but does not require inheritance from any class or virtual class although inheritance from a Ruby module (sort of an abstract base class) is often the best way to implement those methods. So, a Ruby object might export a collection of methods called Enumerable and would respond positively to an is_enumerable? method to identify that those services are available.

Re:It's obvious...

[qslack]

This is exactly right. The scaffolding is seen as the major feature of Ruby on Rails by far too many people. It's not. In fact, if anyone were making a serious, production-level app, they wouldn't even use the scaffolding. It serves only three purposes: to help newcomers to the language become familiar, to jumpstart a simple Web app, and to look amazing on the screencasts.

Ruby on Rails is great. At the very least, everybody should try it. It's no silver bullet, but it is a huge improvement over most everything else out there.

Using Rails is a bit like using a Mac: you always run into these little helpful features that make you think it was created just for you.

Usage of RoR

[achacha]

RoR is pushing this whole codegen thing too much (I personally think codegen is the work of mediocre developers who have ego issues, but that's just me). I used RoR for about a day and wrote a little app then realized that maintenance is a pain and that I would have to manually change all the code anyways to make it behave as I want and that codegen created something I did not want. Then I weighed it against writing sevlets and JSP pages and RoR didn't look so appealing. Ruby is a nice scripting language but I didn't like the architecture of rails. Just not for me. Performance was quite bad too, about 6 times slower than JSP for fetching some data from a database, manipulating it (which is the bulk of the work) and displaying it (given JSP gens compiled into Java and takes advantage of JIT). Ruby is a nice language though, but it's not as useful as python. So I struggle to find a place where I can use it, maybe it can be nice as a simple embedded script language (similar to Lua).

If asked what I would use to develop a server side app, I would have to look at volume and complexity then go in the order: C/C++ > servlets > JSP/PHP > RoR (from highest volumen/complexity to lowest). For high volume/complexity C/C++ is still the best efficient way to go but not for all, requires more work from the developers and not for average/weak developers. Servlets are a good next step if performance is not extremely important. JSP/PHP is a good way to run a site that doesn't have complex computation or one that is static content based (news, blog, forum, and such). RoR I would use for maybe some prototyping or to build a quick and dirty app to provide a simple view of the database (but even then I would probably lean to PHP). YMMV.