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?"

Uhm...

[Black Parrot]

> Automatic code generation sets of alarm bells in my mind

Do you have a beef with compilers and assemblers?

Gem up on Ruby First!

[Boss, Pointy Haired]

Rails has created quite a buzz in the Web 2.0 community, which means a lot of people jump straight into Rails without any prior knowledge of Ruby; and then when they find they can't get very far they blame that on Rails.

It's like hacking the Linux Kernel without ever having programmed in C. You're bound to think it sucks because you won't have a clue what's going on.

This is your typical dev-versus-admin mentality.

[old_skul]

Devs are always looking for ways to reduce the amount of time it takes to code something. Admins are always looking for ways to automate their jobs. RoR is nice for devs but makes the admin tasks pretty hard - unless the admin knows his way around the product about as well as the dev does.

Now add the additional idea of a custom-designed project that the dev put together - and didn't document (because devs never document, right?). Chaos ensues.

Bad OO Substitute?

[cheesedog]

I'll make a bold counter-claim: Object-oriented programming is a bad substitute for straight-forward dynamic binding and typing.

I've been doing almost pure OO programming for the past 8 years (using mostly C++ and Java), but recently took up Python (for python-twisted and pyWxWindows) and Ruby on Rails (for server-side development), and I can tell you that it is much simpler, easier to debug, and quicker to get done than taking the time to create massive class hierarchies whose inheritance structures and interfaces only exist to satisfy type-safety requirements.

Don't get me wrong. I like writing class hierarchies as much as the next guy. I've spent years doing it. But when I compare what I can get done in 30 minutes in, say, Python, to what I can't get done in 3 hours in C++, the advantages start to become very clear.

Scaffolding is exactly what it says it is.

[Boss, Pointy Haired]

Automatic code generation sets of alarm bells in my mind;

You're reading too much into it. Just like when you're building a house; you put the Scaffolding up to give you something to work from. When you're done building your project, the Scaffolding is gone.

Re:Uhm...

[Pxtl]

Well, if you have to do maintenance work on the resulting machine code, then yes, it does alarm me. Otherwise, not so much. Likewise, any code gen environment where you're maintaining the generated code instead of working on the generator should worry people.

Code Generation - Negative Image

[ajwitte]

I think a lot of the "it's not maintainable or scalable" assessments of Rails come from people who have seen its code generation and "scaffolding" features and think that those are the main advantage of Rails. It's true that one can only do so much with the "scaffolding" which is simple and generic. However, the real power of Rails comes not from the scaffoldings but from the framework Rails provides in which to write custom code. I've written two Rails applications and maintained several others. None of them used the scaffolding provided by Rails - they had all hand-written code inside the bare-bones Rails-generated structure. Those applications have proved to be easily maintainable. It's a shame that most of the introductory tutorials/examples/videos for Rails focus on the scaffolding features, because that leads people without much Rails experience to believe that the scaffolding is all there is to Rails and form a (usually poor) opinion based on that.

Code Generation in Rails is No Big Deal

[fthiess]

I've been using Rails for several months, and I think it's "automatic code generation" is no big deal, and nothing to worry about. If you're worried about maintainability, it the wrong place to focus.

The only time code gets generated for you automatically is at the very beginning of a project to create "scaffolding". That scaffolding is great, because it lets you get something up and running very quickly, but in my experience, it NEVER survives in the body of the project for long--you always want to do something differently, or more elaborately, than what the scaffolding provides.

So, I think of Rails' scaffolding as "stub" code that happens to include some (very) basic functionality. Like code stubs, they just provide placeholders for you to use to flesh out your own code.

Once the project is underway, it's unlikely you will generate any more code automatically--you don't need to.

It's worth noting that what I've described here is the behavior and usage of code generators that are included as part of Rails. There *are* some cases where people have written code generators that attempt to automatically generate entire subsystems for you in a Rails app--and those generators are the subject of interminable support questions in online forums, and a lot of discussion within the Rails community as to their wisdom. . . which is why no generators like that are included as part of the Rails distribution.

Beyond code generation, I can't say anything definitive about Rails maintainability because it's so new, but my feeling from having worked with my own code, and from having studied the code of others, is that Rails apps should be wonderfully maintainable. After all, the "opinionated" style of Rails leads all Rails apps to be laid out the same way, with the same directory structure, the same application architecture, coding standards, naming standards, etc.

From my experience so far, all these things are likely to make Rails a winner from a maintainability standpoint, as well as in terms of productivity and fun!

Re:Bad OO Substitute?

[Bruce Perens]

Ruby doesn't contradict the Object Oriented programming paradigm. If you go back to the origins of OO in Smalltalk, it was much closer to Ruby than some tightly-typed OO languages like C++ and Java. Perhaps the lesson to be learned is that tight typing of class references isn't that good an idea.

Thanks

Bruce

Re:Uhm...

[Bastian]

I think the author is thinking of this from an attitude of generating code using RoR and then maintaining the generated code. Which is the wrong way to do it. If there's a bug in the original RoR code, change the original code. If there's a bug in the generated code, you change code generator.

If you're writing the original app using a code generator and making all subsequent modifications to the software by modifying the product of the generator, you've sort of missed the point.

Re:Uhm...

[Bruce Perens]

You have two options with scaffolds: let them be generated every time the program starts, or get the code generated into view source code that you can edit from then on. So, you either have code that you don't have to maintain at all, or code that's yours. Pick the best for what you're doing. It's brief and clear code. If you use the generated-every-time option, you can override it method-by-method simply be creating a view source file for that method.

Bruce

Re:Yes, very

[jarran]

Of course, Java doesn't require inheritence either. What you have described is exactly what Java interfaces are for.

Ruby's lack of typing does make it incredibly flexible, but it has significant disadvantages to, namely that a whole class of programming errors which should be found at compile time, go totally unnoticed until the program tries to execute that code path and finds that it has an object of the wrong type.

Don't get me wrong, I program Java at work and hate it, and I program Ruby for play and love it. But I still think we can do significantly better.

Languages like O'Caml, manage to get the best of both worlds. For example, you can write a method in O'Caml which takes a object as it's parameter and uses a "compare" method on that object. Elsewhere in your program you try to call this method with an object that doesn't have a compare method. Not only will O'Caml detect this error at compile time, it can do so without forcing the programmer write type declarations everywhere.

Sadly O'Caml isn't the answer either, it doesn't have a remotely decent web application framework. But I think that combining strong typing with type inference is the way to go for rapid prototyping environments.

Re:Yes, very

[Abcd1234]

Yeah! And if in, say, Java, you have a superclass and subclass, how do you know the subclass didn't override superclass methods to do totally different things!

It's called not doing stupid stuff. Now, I don't know much about Ruby, but in Objective-C, these things are called Protocols, and in Java, they're called Interfaces, but the rule is that if you implement a given protocol, then you must conform to a given contract. Can a developer deviate from that contract? Yes. Are they fucking retards if they do? Absolutely! If you want to prevent that, your only option is to work with a language like Eiffel which incorporates design-by-contract at the language level... of course, even that isn't foolproof.

Re:Yes, very

[Hognoxious]

how do you know the subclass didn't override superclass methods to do totally different things!

And how do you know that a method does what its name implies anyway? Or that it works as intended? At some point, you have to trust the author of them. Or verify the source yourself.

Re:Yes, very

[the chao goes mu]

Give it time. Ruby and RoR is still young. It takes a while to accumulate a body of stupid coders and the associated body of bad code.

Re:Yes, very

[spludge]

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

I disagree with this. I recently had to debug some RDoc code to create a custom generator. RDoc a big chunk of mostly uncommented Ruby code. Trying to debug and understand it was somewhat reminiscent of trying to debug Perl. Ruby gives a programmer the same expressiveness that allows them to write highly cryptic short statements that are very difficult to unravel. Not as bad as Perl for sure, but still difficult. The other big problem is that Ruby is so dynamic. I found it very difficult to trace the runtime behaviour of code because it is so easy to modify the runtime behaviour of an object from anywhere in the code!

I agree that Java can sometimes be so verbose that it is hard to debug, but Ruby does not strike the right balance. I'd prefer to see a statically typed language (for easier debugging and refactoring in the IDE) that is also dynamic, but that enforces that runtime modification is somehow easier to follow.

Re:Bad OO Substitute?

[the chao goes mu]

Actually Java's biggest problem in my experience is inconsistent typing. Why does the method to fetch a port return an Integer object, but socket connections want an int primitive? Or how about the eight million different date/time object types? I think if that mess were made even a bit more consistent, Java would have a significantly faster development cycle.

Re:Uhm...

[Dracolytch]

So the code generator should be able to automatically generate any potential output? Hmm... I'm not sure I agree with that.

RoR HLL maintainance nightmare

[recharged95]

Granted that RoR is a nice alternative from Java or scripting--can RoR generated code be a nightmare to maintain?

Yes, if poorly written and

Yes, when applications get very, very complex--which is a given. And they will get very complex, just wait 2 yrs.

Consider the great development tools of RoR such that you end up with a Microsoft environment/paradigm--great for RAD, not so great for critical systems that need to be up 24/7, 100%.

I'd still go with XML Schema-based code generation, much more stable as it forces you to thing about state and behavior before you write your first GUI title bar. And since the web is XML-centric, makes sense..

Structure generation vs code generation

[Erisynne]

As others have noted, what Rails generates for you are stubs. Even if the stubs are full-featured enough to let you add, edit, view, and delete objects, they're still stubs. It's just that RoR is succinct enough that generating 150 lines of code (including action views and layouts) is all that's necessary to provide all of that functionality in a very basic way.

But, two links for your consumption.

My article on the topic of what I call Scaffold Withdrawal
http://www.slash7.com/articles/2005/12/07/the-fall -from-scaffolding [slash7.com]

Structure generation vs code generation (from the Rails' creator's blog)
http://www.loudthinking.com/arc/2005_10.html [loudthinking.com]

It's true that "Ask Slashdot" is vehicle for enlightenment, but I didn't think it was a vehicle for the basest laziness. I don't understand why someone would go Ask Slashdot instead of looking at a couple F/OSS Rails app packages and deciding for himself whether or not they look "maintainable."

If the submitter did, he'd find that it's clear that maintaining Rails apps is no problem. You don't have to know much about a given app to even do serious "maintenance" on it. As long as the programmer hasn't tried really hard to break all the benefits Rails brings to the table (regular file structure, MVC separation, clean models, helper classes, etc), then you'll already know a lot about how the app is structured before you even unzip it.

Static vs Dynamically Typed maintainability

[TheNarrator]

Ruby is not statically typed, which means that if you have a very large program and you change an API in that program you have to go and find all the instances of calls to that API in your program yourself, either through running automated tests or seeing the broken calls in the debug log of your application. Compiled langauges on the other hand such as Java,C,C++,C# have static calling conventions which means that when you break an api the compiler will point out all the broken calls to you and not let you run your program till you fix them all. This tends to make statically typed languages more maintainable. If you need to break out of static calling conventions you can in Java at least using introspection and bytecode enhancement but this is usually only done in well defined scenarios inside of application frameworks instead of for every class like in Ruby.

Re:It's obvious...

[happyemoticon]

Here's how I'd look at the problem. I'm not a developer, but I'm decent with Java, C++, Python, and Perl. If I look at some random Java project, I can pretty much grok what it's saying and make the changes I need. The same is true for many languages I'm not really familiar with, like Lua and php (I've been updating a WoW mod that was dropped by its creator).

Now, mind you I might just be upset because I looked at RoR and didn't instantly understand everything. But I was generally put off by the amount of things that were being invoked as if by magic, and I'm even less of a magician than I am a developer. At least with some Java project I've got all the code in that directory, and I know which parts of the standard API and which 3rd party modules are being imported. I looked at some of the stack traces that I got and I was totally bewildered.

One thing that could alleviate this is good documentation. The majority of RoR docs I've found are written by people who either have no intention to truly impart knowledge or don't have the competence, and are directed at non-programmers. They're consummately infuriating. I would much rather hear the ugly truth (I read Programming Perl and Python in a Nutshell for leisure sometimes) than be treated like a child. This pretty much means I have to read the API specs, which ain't no walk in the park.

What this boils down to is if I were in a management situation, I wouldn't know how to hire or deal with a Ruby dev. First off, I couldn't just get somebody I thought had good character, work ethic, an excellent track record and a portable skill set, I'd have to hire a Ruby on Rails Developer. I mean, there are some times when you really want an expert in the field, but those people are hard to come by. Then if I hired him I'd be like, "Hey John, what's this function over here do?" and he'd be stirring a black pot in a pointy hat while cackling, "Double, double, boil and trouble / Fire burn and cauldron bubble!"

Code generation methodology

[gfim]

Unfortunately, that's exactly what most Visual C++ programmers mean by code generation. The "wizard" generates a huge chunk of boilerplate code that the developer never understands. He would prefer not to even look at it, but occasionally has to make some minor tweak.

When I use code generation, I generally write the generator too. As you say, there are two choices: you either generate the code once and then maintain it completely manually (i.e. it's just the scaffolding), or you maintain the generator and the input to the generator but never touch the output of the generator.

Tools like Borland C++ Builder and Rational Rose try to give you the best of both worlds with the "round trip" code generation/reverse engineering. While they do have some advantages, in my opinion they aren't overly successful at it.

Re:Yes, very

[jbolden]

You describe the program as: mostly uncommented, highly cryptic short statements that are very difficult to unravel, modifies the runtime behaviour of an object from anywhere in the code. Why do you think it was written to be maintained by an external author? It seems to me the author hadn't intended a 3rd party to maintain his code. Further my guess is that he was conceptualizing the problem differently than you were. "Highly cryptic" usually means that you need to understand how the programmer viewed the problem before trying to figure out what the program does; that is maintain it like you would translate a poem not fix a broken car.

Common Misconception

[l00k]

The idea that developing in Rails is 'code generation' is a common misconception amongst /.ers - in fact the last time a Rails article was posted sometime last week I had to do battle with a number of people that thought this.

I hope that the number of highly-modded responses which have had the chance to clarify what code generation is in Rails, and what its purposes are within the development cycle, will allay some of the FUD. When I began learning Rails I was under no impression that code would be generated beyond the scaffold, and that the scaffold was only there to get some meaningful database interaction happening right away. This tutorial [onlamp.com] which I began learning Rails from explained it clearly:

Of course, these actions and views are very plain--not the sort of thing you'd want users to see (unless they are total geeks). The good news is that we can leave the scaffolding in place and slowly, one at a time, provide our own versions of the actions and views. Each time you create one of the actions or views it will override the scaffold's version. When you're done, simply remove the scaffold statement from the controller.

The way I imagine the misinformation formed is from certain people hearing the sentiment of "faster development in Rails" and jumping to the conclusion that there must be some sort of cheat involved. Watching the video demos probably fueled this, as the demos are showing Rails off, and the scaffolding is a selling point.

Re:Automatic Code Generation sets off alarm bells?

[Anonymous Coward]

Automatic code generation itself isn't the problem. The real problem with maintainability is if the programmer has to edit both the source and the generated code. For example, if you use a wizard to create GUI code that has places to fill in some code, and then you change the GUI and regenerate the code, it can get very messy. The examples you cite (parsers and compilers) do not involve the programmer editing the generated code.

final void superClassMethod() {} //WO > RoR?

[MacDork]

And if in, say, Java, how do you know the subclass didn't override superclass methods to do totally different things!

Well, if you make a method final in Java, the compiler generates an error when you try to compile an overridden subclass method. That's one way to take care of the problem :-) Perhaps Ruby has something similar...?

RoR, codegen.. from what I gather, there's nothing there that wasn't done years ago. It's called WebObjects. [apple.com] So far, no one has mentioned to me or pointed out anything RoR does in Ruby that WebObjects doesn't do already in Java. Meanwhile you loose the advantage of TONS of mature libraries written in Java. Am I missing something? Is there something particularly compelling about Ruby perhaps? I'm not trying to be condescending toward RoR or anything, but all the 'hype' I've read here about RoR was done a decade ago with WO. Plus, WO does a number of things that I haven't heard the RoR camp boasting, like deploying database connected apps over the internet directly to the desktop with WebStart/D2JC.

Anyone care to enlighten me?