Is Ruby on Rails Maintainable? 348
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?"
Yes, very (Score:5, Interesting)
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.
Eh kindof (Score:2, Interesting)
Rails is OK. It's a great way to get into the language and attract users, and for that I appreciate its existance.
That said, as a fairly long-time user of Ruby myself, I wouldn't use it. Many of the features it provides are more academic proof-of-concept implementations than well-tested, well-polished ones. It requires you to do a lot of things manually that could easily be done automatically, and you still write bits of SQL in your code. Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface. This is bad for any number of reasons. Finally, it's pretty much tied to MySQL, so if you use PgSQL or Oracle (and you should), then you're in for a big headache.
That said, if you're interested in Ruby and/or Ruby on Rails looks cool to you, check it out and play around with it. It's also not the only thing that ruby provides to develop applications, even web applications. If you're developing a more serious app, you may look at stuff like PageTemplate [coolnamehere.com] for the frontend, ObjectGraph [nitrohq.com] for your ORM, and soap4r [ctor.org] for services.
So regardless of your stance on Rails, check out Ruby... there's a lot of cool stuff.
TurboGears (Score:3, Interesting)
It's been raising quite a storm lately, and for a good reason!
Re:It's obvious... (Score:5, Interesting)
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.
Re:Yes, very (Score:3, Interesting)
Eivind.
Re:Yes, very (Score:3, Interesting)
Only if the object's type is explicit at some point in the function call tree at compile time, I suppose. I can think of dynamic scenaroios where this would not be knowable at compile time.
Static checking as you describe would involve propogating type information from the called function up through its callers while that call sequence is being checked. While nobody does this for Ruby (I think Matz's Ruby compiler is still in alpha-test) it's theoretically possible.
Thanks
Bruce
Re:Java Interfaces (Score:2, Interesting)
How? If I have an interface with a method "quack" that is supposed to print a message from a string you pass it, and I write a class implementing it that calculates the factorial of 1,023,342 instead, you can call it, and it will compile and even run, but still violate the contract of being a duck.
Coincidental naming (Score:3, Interesting)
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:Java Interfaces (Score:3, Interesting)
I call BS. Just because a Java class implements an interface, does not mean it implements what is expected of the interface. If your compare method returns a -1 when it should return a +1, you aren't a duck, you're a retarded duck and Java let's you do that just like Ruby.
Bryan
Re:Bad OO Substitute? (Score:4, Interesting)
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 [codehaus.org] - 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? (Score:4, Interesting)
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... (Score:4, Interesting)
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?
Generated Code? (Score:3, Interesting)
I do, however, use the basic "scripts/generate " scripts. They save me a minute or two of creating files and directories and class definitons. Handy, I suppose, but I am not sure if this is considered "generated code." The only "code" that Rails really generates for me is HTML and SQL (Tag Helpers and ActiveRecord) which is pretty nice, actually. The less HTML and SQL i have to write and more I can focus on the actual code, the better.
Re: code generation replacing OO model:
I have no idea what the OP is talking about. RoR is pure OO.
Probably the only thing that I find a little frustrating about RoR is the shear volumn of files involved in a project. Navigating through them gets gradually more time consuming.
-matthew
Usage of RoR (Score:5, Interesting)
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.
Re:Yes, very (Score:3, Interesting)
Hibernate, Struts, Spring, and so on add facilities to Java that bring it more in the direction of Rails. There's a famous example of a Java programmer who set out to show that he could write concise code in Java on a par with RoR. He attempted to duplicate an existing RoR program. He sent the result to the RoR creator, claiming success. It's three times the size of the equivalent RoR code. So, I'm still waiting to see someone make Java as concise.
Bruce
Re:you reveal your ignorance with your poor exampl (Score:3, Interesting)
No it can't, it's immutable. Strings can only create new objects which have grown or shrunk. Admittedly, the optimised implementation uses the same backing array for the new String, but it's still a new String. A StringBuffer (which in my books is another string class) can dynamically grow and shrink. In 5.0/1.5 there's now also StringBuilder.
Re:Uhm... (Score:3, Interesting)