Slashdot Mirror
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?"
> Automatic code generation sets of alarm bells in my mind
Do you have a beef with compilers and assemblers?
Sheesh, evil *and* a jerk. -- Jade
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.
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.
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.
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.
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.
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.
Boys from the City. Not yet caught by the Whirlwind of Progress. Feed soda pop to the thirsty pigs.
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.
l -from-scaffolding
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-fal
Structure generation vs code generation (from the Rails' creator's blog)
http://www.loudthinking.com/arc/2005_10.html
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.
---- My Design, Code, Ruby on Rails blog: http://www.slash7.com/
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.
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!"
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.
Graham
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 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.