Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is Ruby on Rails Maintainable?

Cliff posted more than 8 years ago | from the would-you-want-to-edit-the-code-later dept.

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

cancel ×

348 comments

Sorry! There are no comments related to the filter you selected.

link sucks. (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14310457)

Slashdot editors need to get their act together. Fire them already.

MOD THE TROLL DOWN!!! (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14310458)

MOD THE TROLL DOWN!!!

OUTGOING (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14310461)

HELLO WORLD
23626 23626
HELLO WORLD
24056 24056 86299 86299 64911 64911 12941 12941 12510 12510
81018 81018 46278 46278 36318 36318 21677 21677 05066 05066
96316 96316 17042 17042 10008 10008 73702 73702 89564 89564
30453 30453 65728 65728 65146 65146 73644 73644 04204 04204
50573 50573 40023 40023 78241 78241 72363 72363 14930 14930
73814 73814 80393 80393 68211 68211 23720 23720 25009 25009
55692 55692 88807 88807 10185 10185 33910 33910 20812 20812
10234 10234 11330 11330 82653 82653 80836 80836 64348 64348
11050 11050 99575 99575 37644 37644 40024 40024 80482 80482
13285 13285 92056 92056 99555 99555 57622 57622 11516 11516
28489 28489 60813 60813 94251 94251 80575 80575 08403 08403
45984 45984 47632 47632 44554 44554 61246 61246 64323 64323
23074 23074 78754 78754 14657 14657 94456 94456 13095 13095
86679 86679 74354 74354 43269 43269 01633 01633 27422 27422
38054 38054 44455 44455 49396 49396 98350 98350 04677 04677
00352 00352 35609 35609 62721 62721 08095 08095 76094 76094
96807 96807 00671 00671 18368 18368 95988 95988 62227 62227
72301 72301 35224 35224 33483 33483 95430 95430 84967 84967
28898 28898 36349 36349 13007 13007 75363 75363 94179 94179
81077 81077 46246 46246 77769 77769 07351 07351 56448 56448
00125 00125 85229 85229 16003 16003 23753 23753 62367 62367
58322 58322 21590 21590 40734 40734 57022 57022 80763 80763
05541 05541 23130 23130 84485 84485 14319 14319 64822 64822
71307 71307
K-BYE

Re:OUTGOING (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14310494)

What is this?

Some sort of encrypted terrorist communication?

Re:OUTGOING (-1)

Anonymous Coward | more than 8 years ago | (#14310546)

George Bush, Is that you?

Re:OUTGOING (-1)

Anonymous Coward | more than 8 years ago | (#14310597)

no you fool, it's Ted Rogers

Haha... (-1, Flamebait)

eosp (885380) | more than 8 years ago | (#14310463)

1st psot!!!! Try recoding /. in RoR

Article is a troll. (0, Troll)

Anonymous Coward | more than 8 years ago | (#14310472)

Anyone who'se spent more than 30 minutes with RoR will realize that the automatic code generation really serves the purpose more like examples from books for other frameworks.


You'll re-write them entirely and check your new code into whatever source-control system you prefer (SVN, Darcs, etc) before your first day is over.

Have you ever used it? (0, Troll)

realmolo (574068) | more than 8 years ago | (#14310473)

You seem to be under the impression that the "scaffolds" in Ruby On Rails are all there is. That's not true.

Once you abandon the scaffolds, you can do whatever you want. And it's easy to maintain.

You don't know what you're talking about, in other words.

Re:Have you ever used it? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14310536)

that's why he asked a question. the cockiness of you rails people annoys me.

Re:Have you ever used it? (-1)

Anonymous Coward | more than 8 years ago | (#14310580)

Go have another latte, jerk.

Re:Have you ever used it? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14310621)

I hope Santa Claus comes down your chimney and rapes you this year.

Faggot.

Uhm... (4, Insightful)

Black Parrot (19622) | more than 8 years ago | (#14310498)

> Automatic code generation sets of alarm bells in my mind

Do you have a beef with compilers and assemblers?

Re:Uhm... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14310572)

"Automatic code generation sets of alarm bells in my mind"
 
My sets of alarm bells in my mind have more problems with human sentence generation methods...

Re:Uhm... (5, Insightful)

Pxtl (151020) | more than 8 years ago | (#14310599)

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.

Re:Uhm... (4, Insightful)

Bruce Perens (3872) | more than 8 years ago | (#14310664)

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:Uhm... (2, Funny)

eclectro (227083) | more than 8 years ago | (#14310635)

Do you have a beef with compilers and assemblers?

No, but interpreters have always slowed me down.

Re:Uhm... (4, Insightful)

Bastian (66383) | more than 8 years ago | (#14310641)

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... (2, Insightful)

Dracolytch (714699) | more than 8 years ago | (#14310963)

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

Re:Uhm... (1)

chroot_james (833654) | more than 8 years ago | (#14310651)

He clearly means to imply that it's hard and he isn't sure he can handle it. WIMP!

Re:Uhm... (0, Redundant)

SporkLand (225979) | more than 8 years ago | (#14310659)

Do you have a beef with Lisp Macros?

It's obvious... (5, Informative)

eruanno (598239) | more than 8 years ago | (#14310500)

It's quite obvious that the concept of the automatic code generation done in Ruby On Rails was either not completely grasped or completely missed by the author. The whole purpose of the code being generated was to give you a basic structure to take and change until it was what you needed it to be. This is precisely why it is called 'scaffolding', because it gives you the framework to get started with.

As far as the Ruby On Rails framework itself is concerned, it is extremely capable and flexible for handling a great deal of web application projects. Of course there will be specific functionality that Ruby On Rails will not handle very well — there never are perfect solutions.

I wouldn't consider the reviewers objections completely devoid of import, just misguided. You must always be careful about anything you didn't do yourself, but you must exert the same care and attention to the stuff that you do create yourself! Often we put far too much confidence in our own coding skills.

So, in the end, the concept of Ruby On Rails is simply to alleviate the mundane, rote programming that goes into the basics, particularly the structure and minimalistic database interaction, and make it surprisingly simple.

M.T.

Re:It's obvious... (5, Interesting)

qslack (239825) | more than 8 years ago | (#14310763)

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 [rubyonrails.com] .

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.

spelling? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14310503)

I to was a fan off ruby untill I turned of my peecee and installed windows ans used notepad.

Yes, very (5, Interesting)

Bruce Perens (3872) | more than 8 years ago | (#14310512)

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:Yes, very (0)

Bruce Perens (3872) | more than 8 years ago | (#14310535)

Oops. Duck typing is like virtual base classes, not virtual functions.

Re:Yes, very (2, Informative)

Atlantic Wall (847508) | more than 8 years ago | (#14310555)

If you had to use something more than once in Java, why not just write it once and overload the method or the object. That statement that you have to edit the same thing in different places does not make sense if Java is coded correctly.

Re:Yes, very (2, Informative)

Bruce Perens (3872) | more than 8 years ago | (#14310588)

It's mostly declaration that has to be repeated endlessly, rather than implementation.

Bruce

Re:Yes, very (1)

CastrTroy (595695) | more than 8 years ago | (#14310662)

On the other hand, just because a person quacks, it doesn't make them a duck. If you have an object with methods that you are calling, just because those methods exist, doesn't mean that they're doing what you want them to. If you have 2 objects with the same 5 functions, who's to say that the implementation of a function in one class has anything to do with the same function in the other class.

Re:Yes, very (5, Insightful)

Abcd1234 (188840) | more than 8 years ago | (#14310726)

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 (1)

Bruce Perens (3872) | more than 8 years ago | (#14310804)

Hm. Is it possible to add DBC to Ruby? Has anyone already done it? There are enough instrumentation entry points in Ruby that you could probably do it without modifying the interpreter.

Thanks

Bruce

Re:Yes, very (2, Insightful)

Hognoxious (631665) | more than 8 years ago | (#14310823)

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 (2, Interesting)

Eivind Eklund (5161) | more than 8 years ago | (#14310803)

No, you're not guaranteed that something that respond to the same methods with the same parameter counts is really implementing the same interface. However, while writing an article and a bunch of code for type checking in Ruby, I read've read probably hundreds of discussions on this and certainly thousands of messages. I've not once heard anybody claim that they'd seen this happen or heard of it happening as a problem in practice.

Eivind.

Re:Yes, very (4, Insightful)

the chao goes mu (700713) | more than 8 years ago | (#14310824)

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 (4, Funny)

Bruce Perens (3872) | more than 8 years ago | (#14310913)

Hm. Then perhaps the best way to maintain code quality is to change languages every few years :-)

Re:Yes, very (4, Insightful)

jarran (91204) | more than 8 years ago | (#14310720)

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 (2, Interesting)

Bruce Perens (3872) | more than 8 years ago | (#14310864)

Not only will O'Caml detect this error at compile time, it can do so without forcing the programmer [to] write type declarations everywhere.

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:Yes, very (2, Insightful)

spludge (99050) | more than 8 years ago | (#14310835)

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:Yes, very (1)

Bruce Perens (3872) | more than 8 years ago | (#14310894)

To be fair to RoR, RDoc isn't part of it.

Thanks

Bruce

Re:Yes, very (0, Troll)

spludge (99050) | more than 8 years ago | (#14310941)

I am commenting on the Ruby language, not RDoc. The RDoc parser which I was writing an extension for happens to be written in Ruby. It may not be part of RoR, but you can make the same comment on ActiveRecord. It suffers from same issues. It's extremely hard to trace ActiveRecord execution due to the dynamic and cryptic nature of Ruby.

Java Interfaces (2, Informative)

bunglebungle (777874) | more than 8 years ago | (#14310851)

Java interfaces allow you to declare that something is a Duck, so it must be a duck. However, with Java, I can ensure that anything I think I want to call a duck does indeed fulfill the contract of being a duck. What in Ruby forces you to properly export the collection of methods in Enumerable when you defined is_enumerable to return true? Nothing?

In Ruby, you can write code that assumes a parameter has a method called foo. In the future if I make a new object, I can add a foo method to it and pass it into that code. In Java, all it takes is the oh-so-hard task of creating an interface called, say, CanFoo, that declares a foo method, and typing my parameter to that. For anything I want to pass into that code, I just implement method foo, which I have to do anyway, and add CanFoo to my list of implemented interfaces. Classes don't have to inherit from any particular class, and they can implement as many interfaces as they want. So that was no more work. However, now the compiler helps me to ensure that I properly fulfill the contract of CanFoo. Plus if I want to do anything useful like find things that think they CanFoo, or rename foo to something else, the compiler will know where all of these references are and help me.

I'm not anti-Ruby, but I just plain don't understand arguments like this for the language.

Also, "say it only once" may be somewhat forced by the framework, which is a good principle of a framework, but that transcends languages, so I don't buy that, either.

I'm not arguing that Rails isn't maintainable, just that your reasoning for why it is aren't exclusive to Rails or Ruby.

Re:Java Interfaces (1)

Bruce Perens (3872) | more than 8 years ago | (#14311021)

DBC is useful and would be a good feature to add to Ruby. But even DBC doesn't guarantee that anyone implements a method correctly, only that they return the right type. As I've noted elsewhere, some degree of static checking of Ruby is theoretically possible, and a compiler is in development.

Bruce

Re:Yes, very (0)

Anonymous Coward | more than 8 years ago | (#14310855)

Stop perpetuating the term 'duck typing.' Use 'latent typing.' In the case of Ruby this is 'latent dynamic typing.' In terms of type theory 'untyped' would adequately describe Ruby, but using such terminology would likely send the typical Ruby programmer into a fit.

Get the basic premise right, first (5, Informative)

blakeyez (827270) | more than 8 years ago | (#14310517)

Rails is _not_ a code generation framework. Note the period on that sentence.

Rails may provide the some simple scaffold generation, but that's only there if you _want_ to use it, and it happens to fit the way you'd like a particular part of your app to work. The code produced is concise, easy-to-follow, and thus easy-to-maintain.

For my own applications, I barely ever use scaffolding. It works well for simple admin screens where I just want 'something' that works for now, then will spend some effort on designing it a little better, later.

Rails is as maintainable as you make it. If you're a poor programmer, you're likely to write unmaintainable code, no matter what language or framework you have to help you. Rails helps point you in the right direction, but in the end, it's up to the _developer_ how maintainable his/her code is.

Of topic (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14310519)

This topic really just pisses me of.

Gem up on Ruby First! (5, Insightful)

Boss, Pointy Haired (537010) | more than 8 years ago | (#14310524)

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.

Re:Gem up on Ruby First! (2)

secolactico (519805) | more than 8 years ago | (#14310694)

Somebody mod this guy up!

Myself, I'm in that situation. I've never done any coding professionally except to support my own work as network admin. Having started in Perl, every problem I come across I try to solve in perl (even when a simpler shell script would suffice).

Now that I'm giving rails a try, I find myself frustrated because I realize I know nothing of ruby. So next step (for me) is to put aside rails and learn some ruby. Rails will come afterwards.

If you want rapid application developement, I'd say you are better off with a tool like CodeCharge (http://www.yessoftware.com/products/product_detai l.php?product_id=1 [yessoftware.com] a try. It's not free and it's not very customizable. But you will have a completed app in a very short time.

It isn't really code generation (5, Informative)

Anonymous Coward | more than 8 years ago | (#14310526)

Ruby on Rails script/generate generates very little code. If you choose "File, New class" in Eclipse, you get the about the same amount of code, as you would get if you used rails generation features. The only difference is that ruby on rails also generates a test class for the model.

Scaffolding generates a bit more code, but it is never intended to be actually used. It is ment to be slowly replaced, piece by piece, by your own code. So I don't think the disadvantages of code generation really applies here.

So yes, in my experience a ruby on rails project is maintainable.

Bah (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#14310531)

You're an idiot, read or watch a video if you're too fucking lazy to digest words.

"favoring convention over configuration" (2, Informative)

leather_helmet (887398) | more than 8 years ago | (#14310537)

My limited use of RoR has been favorable - no issues, as of yet, regarding maintainability or spheghetti-O code

It has worked as promised and I have been pleasantly surprised by its functionality
btw, my main use was creating a new database for an intranet application

This is your typical dev-versus-admin mentality. (3, Insightful)

old_skul (566766) | more than 8 years ago | (#14310543)

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? (5, Insightful)

cheesedog (603990) | more than 8 years ago | (#14310552)

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.

Re:Bad OO Substitute? (1)

leather_helmet (887398) | more than 8 years ago | (#14310619)

100% agreed - I have experienced the same situation/enlightenment - After coding C++ exclusively for about 4years I moved over to python to help with game scripting - It was pretty amazing to me how much I was able to accomplish in much less time

there are obvious pros and cons for each language, but I enjoyed the experience of moving over to python for a bit and recently being able to code a couple of small DB apps with RoR

Re:Bad OO Substitute? (4, Insightful)

Bruce Perens (3872) | more than 8 years ago | (#14310625)

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:Bad OO Substitute? (3, Insightful)

the chao goes mu (700713) | more than 8 years ago | (#14310867)

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:Bad OO Substitute? (1)

radarsat1 (786772) | more than 8 years ago | (#14310853)

I totally agree with you here. I was writing a small configuration program in C and GTK when I had little experience with GTK programming. Been writing in C++ and C for years. After a few days of hacking at it, I switched to PyGTK and finished the thing in one day. Since then I've been trying out Python in all sorts of other situtations, and I'm really impressed. I'm really loving its clarity and dynamic binding, and it's incredibly useful for prototyping ideas even if I end up implementing them in another language, because I can do it so fast.

However, I fail to see how you don't consider it Object Oriented?

Try Ruby here! In your browser! Painless! (5, Informative)

5n3ak3rp1mp (305814) | more than 8 years ago | (#14310554)

Try Ruby (the language) here [hobix.com] . Integral to understanding much of Rails.

I released my first production Rails app last month. I like it a lot. I have a background in ASP/SQL Server/PHP. Not having to use Microsoft Windows itself is a huge win. But I like the design of the language and the framework and the built-in separation and a thousand little other things. Check out #rubyonrails on irc.freenode.net, great community there too.

Wrong Idea (3, Informative)

AntiDragon (930097) | more than 8 years ago | (#14310568)

The "Automatic Code Generation" is a slight misnomer. It would be better to think of it as "Semi Automatic Code Generation". (Mental image...hehe).

It's just a part of the system that can *if you so desire* generate basic classes and parts of an MVC system by inspecting your database. It's basic and is designed to give you something to work with while you build the actual application you want.

The real strength of the Rails framework is the various support libraries and the way it gently encourages you to follow specific coding conventions (Hungarian notation fans, run for the hills!). If anything, this not only speeds development but makes maintenance a breeze - Ruby is a very readable language when not abused.

Hmm...that does all sound a bit fan-boyish, doesn't it? Well, I'm a PHP convert to Ruby and I have to say I wish I'd decided to take a look sooner.

Short answer - Rails systems are probably more maintainable than your average ASP/PHP system.

submitter has no clue (0)

Anonymous Coward | more than 8 years ago | (#14310569)

The submitter hasn't done the barest of investigation into rails. if he had, he'd know that there's hardly any actual code generation (apart from generating stubs, which is actually useful).

rails apps (of which i've written several) have the smallest codebase i've ever seen for any application, and are therefore eminently maintainable.

ruby itself is a significant contributor to the success of rails due to its concise nature, and phenomenal abilities with regard to modification of instances at runtime.

submitter needs to do some homework.

Get rid of RoR entirely? (0)

Anonymous Coward | more than 8 years ago | (#14310573)

seem to be under the impression that the "scaffolds" in Ruby On Rails are all there is. That's not true.



Once you abandon the scaffolds, you can do whatever you want. And it's easy to maintain.



Very helpful answer. Gee, I can also get rid of RoR and just use Ruby too. So is your answer: RoR - scaffolding is maintainable? Is there other stuff you need to jettison? Any best practices, real world experience? Thought so.



You don't know what you're talking about, in other words.

Well this is *Ask* Slashdot, not *Tell* Slashdot. And not that you know much of anything either judging by your entirely useless commentary.

Scaffolding is exactly what it says it is. (2, Insightful)

Boss, Pointy Haired (537010) | more than 8 years ago | (#14310574)

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.

We've been told... (3, Funny)

fury88 (905473) | more than 8 years ago | (#14310576)

To stay FAR FAR AWAY from Ruby on Rails here. In fact, they sent us java developers to the Java conference and we were forbidden to go into any of those seminars. Why? Probably because they don't want us picking up any bad habits.

Have you actually USED rails? (0)

Anonymous Coward | more than 8 years ago | (#14310581)

Yes, there's a lot of "automatic" code generation in the demo video(s), but the reality of rails programming isn't anything like that.

There isn't little to none code generated when you use the generate script, mostly it just creates the files, class definition, and maybe a default call to 'scaffold'. That's all there is, so you wouldn't have to "re-generate" anything when a new version comes out. And the "scaffolding" is only good while the site is "under construction", you should have implemented all of the methods the scaffold offers yourself by the time the project is ready.

The only maintenance you'd have to do is when the API changes, and ruby is as vulnerable here as any language.

Awesom/e 7p (-1)

Anonymous Coward | more than 8 years ago | (#14310585)

Lis7 of other the 'cuommunity'

Code Generation - Negative Image (2, Insightful)

ajwitte (849122) | more than 8 years ago | (#14310604)

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.

Re:Code Generation - Negative Image (1)

CastrTroy (595695) | more than 8 years ago | (#14310741)

Besides the scaffolding, what is it that differentiates RoR from any other language. Most languages have the same constructs when you get down to it. Loops, conditionals, functions, classes, variables. What really sets apart a language is either A) the Framework/API as in Java or .Net, or the ability to quickly generate code to do more complex things quickly. I can learn just about any language in a couple days. It's learning to use the framework/API and the other features of the language such as scaffolding that take longer to get a hang on and use them to your advantage. Even this kind of thing can be learned pretty fast. In the end, every organization has their own way of using the languages and tools at their disposal. I sometimes wonder why organizations even ask for experience with a particular language. In the end, people who know the language spend just about as much time as those who don't learning the intricacies of the ways that things are done at the organization. Learning a language and a framework is nothing compared to this.

Rails is more then meets the Eye (4, Informative)

TheUncleD (940548) | more than 8 years ago | (#14310607)

Rails provides more then the scaffolding capabilities and simple framework of designing a blog as seen in the video. It provides the structure for fast and organized ruby application development by setting up for the user a foundation of modelling, views and controllers that are easy to use and distinguish. It is not the magic wand to a great web application. The magic wand comes with Ruby programming experience and learning to tie it into Rails application development. You could even go as far as stepping beyond the "narrow view" of what rails is doing and see the bigger picture, understanding that Ruby is supporting all of this webmagic and rails is providing the "rails" as it claims to. One challenge many of the "why is this better than Php?" questioners have difficulty seeing past is the far smaller community rails has, the less clear translation between what php can do and what rails is capable of, and the predefined examples of rails applications in action. Many people leap to using PHP becuase it provides pre-existing code snippets that make the same thing true of many php users, "simple cookie cutter codejobs." Rails offers you a chance at not only using a great framework, but also a great programming language that its built on to make more pragmatic and simpler design tactics to getting your website online and active. Another alternative to rails is Iowa which offers a lighter approach to maintenence, though remains less documented. It can be found here: http://enigo.com/projects/iowa [enigo.com] Whatever you choose to do, look deeper into the situation then the surface of what appears to be "cookie cutter" programming and realize that a powerful tool lies beneath all of this: Ruby.

ORM and MVC in the same framework (2, Informative)

stelmach (894192) | more than 8 years ago | (#14310611)

I find it unfortunate that most of the 'newbie' tutorials jump right in to how to generate scaffold code. This code is a bit unmanageable and hard to modify, but I think it has a certain 'WOW' factor associated with it. Once the novelty wears off and you need to develop real applications, you will rarely use the generated scaffold code, and the code you write within the framework will certainly be manageable.

Where I think Rails comes out on top is the fact that it includes a full blown ORM and an MVC implementation under the same, configuration-less framework. No more XML. No more duplicate java beans...More of this on my blog [joestelmach.com] if interested.

Code Generation in Rails is No Big Deal (2, Insightful)

fthiess (669981) | more than 8 years ago | (#14310617)

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!

Is Ruby on Rails Maintainable? (1)

nfstern (707551) | more than 8 years ago | (#14310626)

In short, yes. I have been working with Ruby on Rails since the beginning of November. I found it to be fast, easy to learn & Maintainable. I am working on an application at work where I have had to make several modifications due to changing requirements. In each case, it was very easy to figure out where in the ROR framework to make the changes and apply them. The results (due to Ruby) were instantaneous and the Users loved the rapid turnaround time. My experience w/Ruby has made me a convert.

Nobody even uses the scaffolding anymore (3, Funny)

bloodroot (816177) | more than 8 years ago | (#14310642)

Unless they're making a promotional movie on writing a slashdot replacement in 5 minutes

Here's an AJAX example - how good is RoR for this? (1)

Hugo Graffiti (95829) | more than 8 years ago | (#14310656)

I've been wondering whether to plunge into RoR for a simple AJAX app I'm planning, but all the talk about automatic code generation and mySQL worries me a bit. For an example of the kind of AJAX interaction my app will perform, imagine a remote file directory browser that does the usual kind of explorer things: you click on a directory and it expands to show what's below etc. The files and directories are on the server of course. The expanding/collapsing of the tree is all done in Javascript by manipulating (eg) nested lists.

Is that fairly easy to do in RoR or is that not how RoR is meant to be used?

Re:Here's an AJAX example - how good is RoR for th (2, Informative)

zardo (829127) | more than 8 years ago | (#14310704)

I've been using rails for over a year, I think that would be really easy and a testament to how great a language ruby is, in addition to how great a framework rails is. The filesystem classes you will be amazed with, and you don't even have to know javascript to get some pretty amazing AJAX functionality out of your app.

I honestly couldn't think of a better way to do something like that than with Rails.

Eh kindof (1, Interesting)

oGMo (379) | more than 8 years ago | (#14310657)

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.

Re:Eh kindof (3, Informative)

brian_olsen (564201) | more than 8 years ago | (#14310759)

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

Which type of things can be done automatically, you see? Also, what is so bad about writing SQL queries *for complex queries*? I know in my case, I will not be hopping from database system to database system to worry about SQL compatibility issues.

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

You mean its use of ERb?

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

I have no problem using it with PostgreSQL.

Re:Eh kindof -- Idiot (1)

zardo (829127) | more than 8 years ago | (#14310769)

Forgive me but I've been using rails for over a year and it would seem the parent is posting FUD. You'll have to explain yourself in more detail.

Many of the features it provides are more academic proof-of-concept implementations than well-tested, well-polished ones

Which features are you talking about?

It requires you to do a lot of things manually that could easily be done automatically

Give an example. This should be pretty easy, but I've found I'll often try and automate something and down the road it turns out to be more maintenance than if I were to have just hacked it out.

...and you still write bits of SQL in your code

I have a pretty large ecommerce app and the only raw SQL I have to write are where conditions, which arguably could have been written out in Ruby but that would probably be more work and no gain.

Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface.

I'm not sure I know what you are talking about, because my interface is for the most part completely separate from my processing. Interface goes in my views and the processing happens in my controller. Explain this please.

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.

Pretty much tied to MySQL? It comes with connection adapters for both MySQL and PgSQL, and it works fine with both of them. This aught to be a pretty good reason not to trust anything you have said. You have no idea what you're talking about. It doesn't make use of any MySQL-specific features like enums, everything is abstracted down to basic SQL.

If you're developing a more serious app, you may look at stuff like PageTemplate for the frontend, ObjectGraph for your ORM, and soap4r for services.

There hasn't been nearly as much testing and development going on with those projects. I don't know how you could say they are for "more serious apps". You would probably spend at least twice as much time developing an application with one of those.

Re:Eh kindof -- Idiot (1)

zardo (829127) | more than 8 years ago | (#14310790)

Typo: It comes with connection adapters for both PgSQL and Oracle, in addition to MySQL, and a few other databases.

Re:Eh kindof -- Idiot (1)

oGMo (379) | more than 8 years ago | (#14311053)

Criminy, that's a hard post to read. Use blockquote instead of bold! ;-) Anyway:

Which features are you talking about? Give an example. This should be pretty easy, but I've found I'll often try and automate something and down the road it turns out to be more maintenance than if I were to have just hacked it out.

Rails requires you do a lot of stuff like do manual updates on objects, write literal SQL strings in your code, and other similar little things that could, with some creative ruby, be done automatically. On the count of SQL, and at the risk of self-promotion, check out Criteria [mephle.org] , which lets you write literal Ruby statements that are transformed into SQL, all in a ruby-esque manner.

For the latter count, it is easy (or at least, not very difficult) to implement a system that does implicit object persistence. I have such a system called mephle [mephle.org] , which you can see the latest version of in the SVN repository [mephle.org] , but it's not documented well enough for general use, and I wouldn't advertise it as such. However, it shows that such a thing is not only possible, but pretty straightforward.

Give an example. This should be pretty easy, but I've found I'll often try and automate something and down the road it turns out to be more maintenance than if I were to have just hacked it out.

This is just poorly-designed automation, then. There is a clear line for where automation should end and where manual usage should begin. Follow these rules:

If it's something the system can figure out automatically based on specified information, it should be automated.
If it's something that's always unique, it should be manual.
If the information has been specified once, it should not have to be specified again.
If there can be special cases, it should be possible to hook in code to handle them.

If you have a system that follows the above rules, you will find yourself writing much, much less code and focusing almost entirely on the problem at hand. And it's possible to write such a system, especially in ruby---see above.

I'm not sure I know what you are talking about, because my interface is for the most part completely separate from my processing. Interface goes in my views and the processing happens in my controller. Explain this please.

The fact you have HTML in a separate file from the code is not sufficient for full separation. You should be able to entirely drop the web interface and instead write, say, a GTK or commandline app, without changing any of the backend code.

Pretty much tied to MySQL? It comes with connection adapters for both MySQL and PgSQL, and it works fine with both of them. This aught to be a pretty good reason not to trust anything you have said. You have no idea what you're talking about. It doesn't make use of any MySQL-specific features like enums, everything is abstracted down to basic SQL.

Then you have not seriously used it with other databases. I recommend you hop on #ruby-lang on irc.freenode.net (I'm there as oGMo as well), and ask around for people's experience with Rails and other databases.

There hasn't been nearly as much testing and development going on with those projects. I don't know how you could say they are for "more serious apps". You would probably spend at least twice as much time developing an application with one of those.

Uh, you have metrics for this where? All of the above modules are much older and more developed than Rails. Rails is the new kid on the block, and it's still got a lot of growing up to do.

Re:Eh kindof (4, Informative)

znu (31198) | more than 8 years ago | (#14310951)

I've been using Rails for about 7 months, and have done two major projects in it. I completely disagree with your assessment. For starters, it's not at all tied to MySQL. PgSQL support is also very good. My understanding is that Oracle support is not so great at the moment. But I expect that will change. My real point here is that Rails is not inherently tied to any specific database; it's just a matter of what ActiveRecord adaptors happen to be out there right now.

As far as requiring the user to write SQL code, yes, you do have to write fragments of SQL code, sometimes. But SQL is a useful way to describe queries -- that's the whole point. Would using some other query language, that got translated to SQL, be any better? I don't see why it would.

Your comment about Rails not abstracting functionality from interface seems off base as well. Rails adopts a standard MVC architecture, which is pretty much the standard method for abstracting functionality from interface. If you're not getting such abstraction in your Rails apps, you probably just need to think about exactly what should go in the models, what should go in the controllers, and what should go in the views, and rearrange things a bit. Like any other MVC environment, Rails can't prevent you from e.g. putting view-specific code in your model. All it can do is provide a structure that allows you to properly separate these things if you take the time to think about your design properly.

Finally, on the charge that Rails only provides proof-of-concept features, I think you've misunderstood one of the major design principles of Rails. Rails is intended to provide a framework to build on, not a bunch of components you can plug together to get a web app without writing any code. As such, many of its components focus on the core functionality that's really useful, to the exclusion of other stuff. That other stuff might sometimes be nice to have, but it frequently locks you into doing things the way the framework does them, instead of the way that's most appropriate to your app. The Rails approach is a very refreshing change, for me anyway, and I hope the project will continue to maintain this focus.

Re:Eh kindof (1, Informative)

Anonymous Coward | more than 8 years ago | (#14311056)

Rails isn't tied to any database. For example, I use a sqlite3 for development. For production, I then move to postgresql (read below about keeping data). You can even create an "in-memory" database if you want to prototype something really simple.

Here is a short prototype:
require 'rubygems'
require 'active_record'

ActiveRecord::Base.establish_co nnection(
  :adapter => "sqlite3",
  :dbfile  => ":memory:"
)

ActiveRecord::Schema.define do
  create_table :users do |t|
    t.column :name, :string
  end

  create_table :posts
    t.column :post_id, :integer
    t.column :title, :string
    t.column :body, :text
  end
end

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::base
  belongs_to :user
end

me = user.create :name => "me"
me.create_in_posts :title => "Blah", :text => "look at all the text I am writing!"

Isn't that neat? I defined my schema in Ruby. Rails will translate this code into SQL statements for any SQL server it supports. Rails also has this neat thing called migrations. You can mess around with your schema, and not effect the data that is already in there. You can even pick up your data and move it to a different SQL database (sqlite3 -> postgresql)

Re:Eh kindof (1)

draed (444221) | more than 8 years ago | (#14311091)

Have you even used rails? It's just as easy to use Postgres or sqlite then it is to use MySQL.

Author has it all wrong (2, Informative)

wackysootroom (243310) | more than 8 years ago | (#14310669)

Judging by how this article was written you haven't used rails at all, or maybe used it for something extremely trivial. The "automatic code generation" (scaffolding) is only there to help you get started on a project. You can completely bypass it if you want.

I'd be willing to bet that if you used rails for an hour or two, you wouldn't have written this article. In fact, the entire article depends on your assumption that the code *has* to be generated automatically.

So what are you waiting for? Try it and see! [rubyonrails.com]

Java and Tapestry? (1)

flyboy974 (624054) | more than 8 years ago | (#14310671)

Tapestry is also doing a lot of code generation in Java. You simply write your classes as abstract, create abstract bean members (getters/setters), or other annotated values, and it'll generate the underlying code.

This is great for rapid prototyping and getting your application to a usable point. Then, as you need to, just implement the members as needed. Many times you won't need to set things, because you'll be reading from an underlying object and then doing set's on all the properties, and doing get's to set the underlying object during a save.

It takes some getting use to. The jury is still out for me too.h

Perhaps (1)

discoMingus (940547) | more than 8 years ago | (#14310699)

It depends what you mean by maintainable. Is it maintainable by the lone cowboy coder (or small group) who writes their own apps? Sure! When you talk about maintainability in a large production environment it's a little different. I've run into issues at work where the Rails apps I've written are hard to maintain because the people who run our server farms aren't familar with the technology and how to support it. (They don't like that I'm running Apache!) So, maintainability in that sense, I'd say RoR is not quite there (but it's getting there real fast).
As for the "automatic code generation" it's not quite that, it's all done behind the scenes (and scaffolding is only part of it). I see how the "alarm bells" can go off because seeing the actual 'code' generated makes a programmer feel all warm and fuzzy inside but really, it's not that big a deal.

You're right .... (1)

GavrocheLeGnou (929922) | more than 8 years ago | (#14310714)

i think you're touching a sensible subject.
with autogeneration can you really maintain your applications and more important, what happens with future versions of RubyOnRails ?

Will thoose autogenerated scripts still be usable ?

Does the ROR developpers have to write migration scripts for your scripts everytime ?

With plateforms like Zope, as soon as structure is not changed the scripts are much more reliables.

----
Gavroche Le Gnou
Flash Xml Multi-User Socket Server [gavroche.net]

TurboGears (2, Interesting)

ultrabot (200914) | more than 8 years ago | (#14310733)

In the meantime, if you want rails-like development but with Python check out TurboGears [turbogears.org] .

It's been raising quite a storm lately, and for a good reason!

Template System for RoR (1)

DigitalRaptor (815681) | more than 8 years ago | (#14310744)

I'm interested to hear what the Slashdot community thinks is the best templating system for Ruby on Rails.

I'm a PHP / Smarty developer and have really liked it.

I know there are some great templating systems out there, like Canny (very closely based on Smarty but not made for Rails).

Ideally I'm looking for something that works seamlessly with Rails and is close to Smarty in concept and functionality. Canny for Rails would be perfect. (Or has someone found a way to use Canny with Rails?)

Re:Template System for RoR (1)

Diomedes01 (173241) | more than 8 years ago | (#14310888)

Have you looked at Liquid [leetsoft.com] ?

Before worrying about a maintenance nightmare... (0)

Anonymous Coward | more than 8 years ago | (#14310770)

you should first look at the functionality nightmare that exists. Ever try selecting a table twice in an sql query (aka joining it to itself)? It can't be done. Try a different language, something that isn't a maintenance nightmare and isn't a functionality nightmare. Try python.

Re:Before worrying about a maintenance nightmare.. (1)

eluusive (642298) | more than 8 years ago | (#14310918)

That's not true, self joins are very common and usefull.

Maintainability of Code Generation (1)

bokmann (323771) | more than 8 years ago | (#14310781)

The author's concern could be expressed about the maintainability of generated code, whether in Ruby or Otherwise.

To talk about this intelligently, lets split it into 2 kinds of generation: the 'one-off' code generation that occurs once, in order to get something up and running, which is then maintained on its own, and the 'generate every time you build' mentality of things like XDoclet (to mention one of many). Both have their pros and cons.

With one-off code generation, (which is what Rails is), you generate the code that gets the 'skeleton', but from there, it is something you have to maintain yourself. You have to understand what you are generating and maintaining... you might as well think about it as starting our having to maintain someone else's code (which really, it is). As long as you understand the generated code, this is not a problem. one-off code generation is simply a convenience for getting started, it is not a replacement for knowledge.

With build-time code generation, you are ideally automating something that you would have to understand in order to keep up with changes elsewhere in the system. While it might be automating away some drugery, often times you also end up automating away 'layers' that you don't want or need to understand. This is where the maintenance nightmares of generated code come in - you have to hook into stuff you don't understand, often by inserting code in between comments that say something like: //** your code to be put here //** end of your code

When this is done well, it leads to the dream scenario of getting 'something for nothing' where it is not done well, you create a 'culture of ignorance' that simply guarantees you won't know how to solve the problems you inevitably end up creating.

In my humble conclusion, rails-generated code is VERY maintainable, but you are not off the hook for understanding what has been generated.

I use Ruby on Rails and Java (1)

MarkWatson (189759) | more than 8 years ago | (#14310807)

Wow - what a bogus premise: off course Rails based web applications are maintanable. I consider maintenance and modification costs to scale fairly linearly with code size and Rails applications are concise.

After heavy experimenting with Common Lisp, Python, and Smalltalk based frameworks I have decided to base my consulting business on just Ruby on Rails and a subset of the Java J2EE stack. I am a little prejudiced on language choice since I have written 5 Java books and I am working right now on a Ruby book for Manning; and on Monday I spent a half day creating the RubyPlanet.net news site. Still, I enjoy Lisp, Python, and Smalltalk and gave web frameworks written in those languages a good evaluation.

Ruby sin Rails (1)

Anonymous Coward | more than 8 years ago | (#14310844)

I just use a Ruby dispatcher [telperion.info] that doesn't require rails, it just loads Ruby apps like php-cgi.

How about a little research first (1)

blunte (183182) | more than 8 years ago | (#14310925)

Before posting a question like this, how about researching RoR just a little.

RoR generates complete, readable code for you when you ask it to (the scaffold), but once you've done that, you're typically going to go modify that yourself. It's relatively simple, logical code. And it's a one time deal. You will typically intentionally go modify that scaffold code, unless you're doing something really simple.

Besides, if you wanted to know how maintainable RoR code was, you could have followed any of the many tutorials to see how they make changes after having "generated" code.

Don't Repeat Yourself (DRY) (1)

Baldrson (78598) | more than 8 years ago | (#14310927)

The idea of the Rails specification (and any program generator including compilers) is to express yourself at a higher level so as to avoid redundancy by closing the gap between program specification and code. Avoiding redundancy is otherwise known as succinctness, factoring and even compression [geocities.com] .

While working with the corporate software process group at SAIC (I was managing the automated ordnance inspection software department at the time) it became apparent to me that most of the software process is reducable to a human-mediated build/compilation process where the "source" language is the formalism used for specification. Since the highest level language for specification is predication (largely of pre and post conditions of the system's operations) it became apparent that predicate calculus tools -- not necessarily direct execution thereof -- could be very important for automating large portions of the software process.

Since Rails isn't high enough level, its specification language is inadequate and the resulting code generated must be edited directly. But it is a step in the right direction.

If you think Ruby on Rails is scary... (2, Funny)

NardofDoom (821951) | more than 8 years ago | (#14310953)

You've obviously never worked with ASP.NET.

You obviously haven't used Rails beyond the 'demo' (0)

Anonymous Coward | more than 8 years ago | (#14310962)

The code generated by Ruby on Rails is intended just to get you started. It also happens to be a completely optional step. You can choose not to use generated code. In my experience so far, the generated code is not adequate for writing real applications, but serves more as a pointer on best practices to use for dividing the work to be done between the model, view and controller.

I didn't like the scaffolding code that was generated and went off to change it, basically, removing a whole generated view/controller, and merging it into another view/controller. After I did that, it seemed to have too much duplicated functionality, and I had a choice between making methods that take classes as additional arguments, and splitting the functionality into similar but separate files. I chose the latter and after refactoring, guess what? I was back to the beginning, which sort of taught me that the default division of labour is a pretty good one.

I don't plan on using the generated code to write the rest of the views and controllers in my project. Why? Just looking at the one class for which I generated a scaffold, gives me a good idea on how I can handle the rest of the code. To believe that Ruby on Rails will write your application for you (which is what you seem to think, as you are complaining about maintaining lots of the generated code) is not correct. No computer will write your code for you properly.

Scaffolding is just to help you get started. You aren't supposed to use it in production. Why don't you also complain that the scripts/console in Rails doesn't print out HTML? After all, because you got a tool to help you look into your domain model, and it shows you what is going on, and let's you type in your own Ruby as well, then why not complain that it doesn't write out the HTML too?

My point is that the point of scaffolding is not to build your application for you ... so don't complain if you selected the wrong tool for the job. Would you blame dBase for not letting you speak SQL to it?

Repeat after me (0)

Anonymous Coward | more than 8 years ago | (#14310969)

"Rails is not a code generation tool"

Have you really use it?

RoR & Maintainability (2, Informative)

Whatchamacallit (21721) | more than 8 years ago | (#14310983)

RoR (Ruby on Rails) is simply a very nice API for doing web apps with Ruby. It will auto-generate some code via what Rails calls Scaffolding. This is meant to get something working extremely quickly and it allows you to enter some data into a table with minimal fuss. The code it generates is quick and dirty and you are supposed to re-write each method as you move forward. That said, it's not a real code generator in the traditional sense. The Wow factor of the videos on rubyonrails.com show off the Scaffolding but that is only a very small part of Rails development.

Ruby itself is very maintainable because the syntax is so very clean. However, it's up to you to document your code with meaningful comments, check it into CVS or Subversion, and implement your own Unit Tests, and include RDOC tags in your comments, etc. All code regardless of language is maintainable if you eliminate the code monkey bad habits. i.e. if you've been coding in PHP and all your code became unmaintable then it's your own fault and not that of PHP. Ruby in my opinion is better organized then PHP and encourages good code standards but ultimately, it's up to the programmer. If you are a neat freak and are very detail oriented and you tend to go back and cleanup, test your code before you check it into your version control system then your code will always be maintainable.

I like the way the RoR ActiveRecord mapping system; maps my classes to database tables and objects to my records. You can programatically create records in the table by creating additional objects. The scaffolding will read an existing database table and generate working classes so you can utilize CRUD functionality. You don't have to use scaffolding but it comes in handy for me even when I throw it out one method at a time and re-write it.

RoR HLL maintainance nightmare (2, Insightful)

recharged95 (782975) | more than 8 years ago | (#14311075)

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..

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>