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.

Coincidental naming

[kabloom]

The problem that he's referring to in ruby is coincidental naming.

I implement a function with a name "join" without knowing what the rest of the world uses it for. (e.g. my "join" joins a chatroom, but the standard use of "join" is to concatenate all of the objects in an array together into a string.) Suddenly my object looks like a duck, and quacks like a duck, but doesn't act like a duck. Ruby thinks it can be used in the same context that everything else uses it in, but semantically it can't be used there.

Inheritance prevents conicidental naming problems by making the default assumption that two similarly named functions *don't* do the same thing, and can't be used in the same place. You override this assumption by indicating that the class inherits from a certain class (C++) or implements a certain interface (Java).

Re:Bad OO Substitute?

[IamTheRealMike]

Of course it isn't as simple as that. If it was, everybody would use Ruby or Python for everything and Java/C#/C++ would be dead.

In practice, strong typing and the lack of Ruby-style dynamism allows compilers and runtimes to make optimizations they otherwise couldn't. Those matter, a lot, try looking at the memory usage or execution speed of your average Ruby program sometime! Worse, it's an unfixable problem, at least without modifying the language itself quite heavily.

I think the way we're going to go with language design, as an industry, is more like Boo - a language which on the surface looks like Python and has many of the clarity and programmer efficiency features that make Python so much fun to use, but under the hood is actually a traditional strong/static typed language. In Boo, type inference is used to let you drop many of the redundant type declarations that normally clutter up Java/C#/C++ style code, and a smart compiler plugin system is used to let you add new features to the language easily. This is traded off against the ability to do things like add/remove methods at runtime which are hard to implement in a time/space efficient manner.

Automatic Code Generation sets off alarm bells?

[meowsqueak]

I have no experience with Ruby or RoR but I am a software engineer like many people here and I would like to stick up for automatic code generation. Modern software is extremely complex and even when excellently designed and implemented by a skilled person or team it is still subject to faults. Automatic code generation, when done properly, is an excellent way to reduce the effort and risk associated with creating certain types of complex systems. A classic example is a parser - hand writing parsers can be done, of course, but they can be notoriously difficult to test and small grammar changes can upset the entire structure of the parser. In this situation, automatic code generation is not only useful, it's also safer and more reliable. If you have to change the grammar, you just reconstruct the parser code.

A compiler is a form of automatic code generation - you don't compile your source by hand, usually, you let the compiler do it. The compiler becomes a cornerstone of your industry and is trusted perhaps far beyond what it really deserves. But the important thing is that it is hopefully consistent and can compile to a lower form much more accurately and faster than you or I or anyone can. You can make large scale higher-level changes without worrying too much about the effects of these at the lower level.

Unfortunately all generalisations fail when you talk about specifics and the implications of this don't need stating, but I think it's unwise to say 'automatic code generation sets off alarm bells' when it is more accurate to think 'writing it manually should set off alarm bells' for many implementations.

Re:Uhm...

[Jack9]

Practical question about Rails implementation with Ruby.

I concede that "scaffolding" is used by EVERY PROGRAMMER. That's the idea behind code reuse. "I'll adapt my authentication I made for a BB system to use as auth for an entire website." "I'll use my pretty table CSS from last year for displaying this data."

Can you alter the templates generated? If I have coding standards implemented, I have serious doubts the default RoR scaffold templates specifically adhere to mine. If I can't alter these templates, the answer to the article is no. If I can alter these templates (I assume it's possible), the answer to the article is yes.

How is this article generating all this Ruby-anti-Ruby nonsense when it's a question of Rail implementation? More importantly, why isn't there a PHPoR?

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.