http://www.perlmonks.org?node_id=509282

I swear I'm not trying to start a language war, but for the first time, I've been looking at Ruby On Rails, after having heard about it so many times.

I read this OnLamp tutorial, Rolling with Ruby on Rails and came away somewhat unimpressed. Even leaving aside the fact that there seem to be major version and compatibility problems (see the comments at the end of the article), it doesn't really live up to his claim that building web apps will become ten times easier. And whatever value of n you substitute for ten, it's still not the difficult bits it makes quicker, just the boring bits, surely? Plus, the moment I want to do stuff my way, it leaves me with a messy code-embedded-in-HTML setup, which I swore I'd never touch again.

What do monks think about it? Is it a just a buzz-word technology, or a useful example of integrating technologies so that we aren't all reinventing the wheel? How hard would it be to recreate that kind of rapid development tool in Perl? Is there anything like this in Perl 6?



($_='kkvvttuu bbooppuuiiffss qqffssmm iibbddllffss')
=~y~b-v~a-z~s; print

Replies are listed 'Best First'.
Re: OT: Ruby On Rails - your thoughts?
by Ovid (Cardinal) on Nov 17, 2005 at 04:52 UTC

    Ruby on Rails is a fantastic technology and, from what I've seen, it really does make creating Web apps much faster. However, that being said, I've been hearing more and more that one of the strongest strengths of Rails is not the code, but the evangalism. Whether or not that is really true is not something I can say, but you'll find some pointed comments about the RoR developer's database knowledge in this thread.

    Also, if you sign up for the Catalyst mailing list, you can peruse a recent thread I started about this topic. The people have many interesting things to say about each solution. The (rough) consensus seemed to be that Rails is easier to use, harder to customize. Catalyst is the reverse. Which matters more to you will depend upon your needs.

    There were also assertions that Catalyst is faster and more scalable and the only objection I heard was "yes, but Ruby 2.0 is just around the corner!" Needless to say, waiting for an upgrade of the underlying language is not a good option. Catalyst also has much poorer documentation and that's usually a huge obstacle to overcome.

    Cheers,
    Ovid

    New address of my CGI Course.

Re: OT: Ruby On Rails - your thoughts?
by davorg (Chancellor) on Nov 17, 2005 at 09:43 UTC

    Ruby on Rails looks great. There are a lot of things in there that really make it easier to develop great looking web apps very quickly. In particular I'm thinking of the built-in mini web server, the helper scripts for building components and the division between dev, test and live environments.

    There are, however, three points I'd like to make:

    1. Catalyst also has all of that. What it doesn't have is the marketing.
    2. The database access part of RoR (which is called ActiveRecord) looks really amateur. You have to redefine all of your database tables in the Ruby code. It's like using Class::DBI without Class::DBI::Loader. It gives the impression of being designed by people who don't know much about databases. Or who don't like databases.
    3. A lot of the buzz about sites build with RoR is the innovative new interfaces that they use. But this really has little to do with RoR. The interfaces are built using clever javascript libraries like scriptaculous or prototype. Perl has interfaces to these libraries too.

    So I think that we should be looking closely at Ruby on Rails and making sure that our frameworks provide all of the same facilities as it does. But the most important lesson I think we can learn from it is how to market a web framework so that it goes from being unknown to the name on everyone's lips in a year. That will be a lesson worth learning!

    Update: Fletch points out below that I was misremembering how ActiveRecord works. He's right, you give it a class name, and it works out the name of the associated table and creates attributes for all of the columns. What it doesn't do (and what you can do with Class::DBI::Loader) is to a) automatically create classes for all tables in a given database and b) automatically set up the relationships between your tables.

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

      You have to redefine all of your database tables in the Ruby code.

      Erm, what? Presuming your tables conform to the Rails conventions (granted that is a substantial caveat when dealing with existing schemas and is an acknowledged weakness of Rails) you need one two line file for each stand alone table. Any relationships between tables are then specified within this class declaration.

      class User < ActiveRecord::Base has_many :projects end

      With Class::DBI you'd have to have MyDB::User->has_many( projects => "MyDB::Project" ) declarations somewhere to do the same thing, so I don't really see how this is really a substantial deficiency.

      Update: Just to clarify, the above declaration would suffice to get a User class which has accessors for all columns of the users table in the default database; it would also setup relationship so that a_user.projects would return an array of Project instances associated with the User instance in question (presuming of course there were an appropriate Project class with a belongs_to :user declaration). If the DB doesn't adhere to Rails' expectations as far as table and primary key names it's pretty simple to correct it (set_table_name "web_user_names"); similar options are available for foreign key names (Class::DBI has similar expectations and mechanisms for allowing variation from them). Additionally, there are code generators which will write the stubs for you so you just run script/generate model User once when creating your app and the grunt work is done; you just go in and add the relationship information.

      Catalyst also has all of that. What it doesn't have is the marketing.
      Not just Catalyst - Perl needs better marketing ...

      What do you think. Would TPF grant funds for a PR/marketing project?


      Have you tried freelancing? Check out Scriptlance - I work there.
Re: OT: Ruby On Rails - your thoughts?
by perrin (Chancellor) on Nov 17, 2005 at 04:56 UTC
    I've been puzzled by the hype too, and have written about it a little on use.perl.org. Pretty much all of Ruby on Rails has been available in perl since before Rails became public, albeit not in such a well-documented and heavilly promoted form.

    My current theory is that most of the cheerleaders are people who have never seen a high-level (scripting) language before. They are probably coming from using nothing but Java for years, and can't believe how much simpler the code is. The prejudice against Perl as a serious development language may have kept them away from from it, so they needed something new without Perl's reputation for unreadability to get them interested.

    The tone of the articles can get pretty irritating though. For example, many of the authors are taking pot shots at Perl for having unreadable syntax, while lauding Ruby. Ruby looks like a slightly crazier syntax than Perl to me. I'm surprised more of the Java guys didn't get behind some kind of Python framework instead. Go figure.

    UPDATE: Speak of the devil.

      Ruby looks like a slightly crazier syntax than Perl to me.

      Having used Ruby a bit and Perl a lot, I definitely prefer Ruby's syntax. It has a lot of the same shortcuts that Perl does, but is significantly more regular. With better defaults. And I find that as I go to more complex conceptual code, Perl is far more likely to get ugly on me.

      As a random (unfair) example. Suppose that I want to do a sort on an array of arrays based on the contents of the first column. In Ruby that's array = array.sort; In Perl that's @array = sort {$a->[0] cmp $b->[0]} @array; Suppose that I want to do a lexicographic sort (first column, then second, then...) In Ruby that's the default. In Perl that turns into truly ugly code.

      That is not an isolated example. Suppose that I have a hash of hashes and I want the keys of one of the subhashes. In Perl that's keys %{$hash_of_hashes{$foo}} while in Ruby that's hash_of_hashes[foo].keys. Which would you prefer to figure out in a hurry?

      This is not to say that there aren't warts to Ruby's syntax. For a start, I loathe optional semicolons. Secondly, I strongly dislike the lack of a variable declaration, meaning that there is no easy equivalent of strict available. Thirdly the Ruby philosophy of, "Oh, add every alias someone might expect for this" has a conceptual cost when reading someone else's code.

      But I still prefer it to Perl's. Significantly.

        That's reassuring to hear, actually. What I like about the recent success of Ruby is that it seems like a language which most Perl programmers would be pretty happy to work with, if it continues to grow. It's open source, unlike Microsoft's offerings, and higher level than Java.
        That's exactly what I think. In fact, I think one of the biggest adavantages Rails has over Maypole & similar frameworks in Perl is that it's written in Ruby :-)

        Yes, ruby is slower and the main developers have a tendency to choose "right" and "nice" over "simple" and "fast", but I'm very impressed with how the whole Rails system holds together as a logical, intuitive whole whithout making it look overly complex and longwinded (yes, Java, I'm looking at you)

        Having used Ruby a bit and Perl a lot, I definitely prefer Ruby's syntax. It has a lot of the same shortcuts that Perl does, but is significantly more regular. With better defaults. And I find that as I go to more complex conceptual code, Perl is far more likely to get ugly on me.

        As the AOL folk would say - me too !

        I loathe optional semicolons

        I love 'em. The less I have to type the better :-)

        Secondly, I strongly dislike the lack of a variable declaration, meaning that there is no easy equivalent of strict available.

        Curiously enough I've never found this a problem. I thought I would when I first read the Pickaxe book - before I did any coding. However I've never found it a problem in real life. My guess is that my test suites catch these mistakes early enough for it never to be a problem.

        Thirdly the Ruby philosophy of, "Oh, add every alias someone might expect for this" has a conceptual cost when reading someone else's code.

        I agree this is a pain, but I think enough people are pushing back against this idea now that it's a problem the community will fix.

Re: OT: Ruby On Rails - your thoughts?
by dragonchild (Archbishop) on Nov 17, 2005 at 14:35 UTC
    First off, Catalyst is the attempt to port Rails to Perl. CGI::Application, Mason, Bricolage, AxKit and others are all solutions to the same problem. They all have their strengths and weaknesses.

    I'm currently learning Rails and Ruby. Here's my experience. Basically, and I've said this on the P6 language list, Ruby is the closest to Perl6 that we have today. I want Perl6, and will joyfully use it when it's available. However, it's not, so I will use the thing closest to it, and that is Ruby. Perl is an excellent language and I will continue using it, as well. Perl has a number of strengths that Ruby cannot hope to match, not the least of which is CPAN.

    BUT ... Ruby is a dream to code in. It has its shortcomings, just like everything else. But, as an experienced Perl developer, it solves the problems I have with Perl without exposing too many shortcomings to how I code. And, you cannot understand it without actually having programmed in a truly OO language that also has the same dynamic facilities that makes Perl great.

    Rails is also a dream to work in. It has the same MVC architecture that Catalyst provides. But, the tools it has at its disposal are much better. A few examples:

    • Since everything in the language is an object, the xUnit framework actually works in Ruby vs. Perl. This makes testing quite a bit saner, and easier.
    • ActiveRecord makes Class::DBI look ... well, it makes it look sad. I spent two weeks rewriting Tree::Simple into Tree, borg'ing half the Tree namespace in the process, just to add a transparent persistence layer so that changes to $tree are automatically reflected in the database. Last night I read that ActiveRecord provides acts_as_tree() and acts_as_nested_set(). End. Of. Debate.
    • ERb is a templating system that provides everything TT does, everything JSP does, yet doesn't get in your way. It's the first JSP-like templating system I've even considered using, and I wish it could be done in Perl in such a clean fashion.

    This is in addition to what Rails does for you:

    • This is what pagination looks like in Rails:
      def list @product_pages, @products = paginate :products, :per_page => 10 end
      One line of code, a few items in the associated template, and it's done. How many questions do we get on PM about pagination per month?
    • How about status messages back to the user? Well, this is how you send a message back to the user:
      def update @product = Product.find(params[:id]) if @product.update_attributes(params[:product]) flash[:notice] = 'Product was successfully updated.' redirect_to :action => 'show', :id => @product else render :action => 'edit' end end
      That flash[:notice] line is it. But, there's more! How about errors from whether or not the update was successful? Well, through the magic of ActiveRecord, if an error occurs, then the flash is updated with the list of errors. Through the magic of the right templates and CSS, those errors are sent to the user in the edit page (because we said that if update_attributes() fails, render the edit page) and the form is sticky. STICKY! And, it's just done for you.

    The sample application in the book is a shopping cart. The fact that they consider this type of application simple enough for a demo (and it is, in Rails!) should be a good indication of the power that Rails puts into your hands. I haven't even discussed the configuration capabilities, logging, or anything else.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Wrong, Catalyst is not a Rails port.
      Yes, Class::DBI sucks bad, but we have DBIx::Class, which does a lot more than ActiveRecord.

      Follow Ovid's links above if you want to know more.
        When DBIx::Class can do what Re^2: OT: Ruby On Rails - your thoughts? describes, then I'll be impressed. Why isn't DBIx::Class required by Catalyst vs. Class::DBI? Why isn't DBIx::Class being trumpeted to the rooftops? Why is CDBI still forced onto poor unsuspecting users?!? The world wants to know!

        A huge win that ActiveRecord and Rails have is the fact that they use Ruby. For example, here's some code I wrote in Ruby that directly uses DBI.

        This is the equivalent code in Perl.

        Which one is easier to read? Which one is easier to modify? Which one is easier to verify in terms of variables staying in scope? And, this is an example that is not only written by someone who's an expert in Perl vs. a novice in Ruby, but it's an example that's catering to Perl's strengths! And, Ruby still is a win in my eyes. Just imagine this kind of code within a much larger application. By using the first-class blocks that Ruby provides, that's a huge amount of scoping ... for free!

        The only true win Perl has in those snippets is the array slicing at the bottom. I'm pretty sure that's because I suck at Ruby and not because Ruby sucks vis-a-vis Perl.

        Rails may suck relative to Catalyst, but it couldn't be written in Perl (or Java or any other language). I hate to say it, sri, but Catalyst could be written in Ruby.

        For the record, Catalyst is my preference for new webapp development in Perl and I think it's an excellent step forward. Rails is my first choice for new webapp development in any language.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        Yes, Class::DBI sucks bad, but we have DBIx::Class, which does a lot more than ActiveRecord.
        ...and Rose::DB::Object, which does more, faster ;)
      These ActiveRecord features don't seem all that impressive. Auto-relationship discovery? Class::DBI has that. Coding a tree structure in Class::DBI to the extent that acts_as_tree provides doesn't take much code.

      What's looking more interesting to me lately is Rose::DB::Object. In addition to much better performance, it provides a reasonable answer to the question of how to handle more complex queries without totally abandoning the o/r mapper.

Re: OT: Ruby On Rails - your thoughts?
by Roy Johnson (Monsignor) on Nov 17, 2005 at 15:42 UTC
    it's still not the difficult bits it makes quicker, just the boring bits, surely?
    Sometimes getting through the boring bits is the most difficult bit. Don't underestimate the value of easy ramp-up. Consider the proliferation of Module::Simple modules. People want things that make basic functionality a snap, especially in areas where they very often don't need more. Not having explored RoR or Catalyst very much, I can't say whether a Catalyst::Simple module would be a great draw, but it does seem an obvious direction to consider.

    Caution: Contents may have been coded under pressure.
Re: OT: Ruby On Rails - your thoughts?
by tmoertel (Chaplain) on Nov 18, 2005 at 00:55 UTC

    Back in February I used Ruby and RoR for the first time, on a month-long project. My impression: Ruby is a great language. It feels cleaner and more consistent than Perl yet remains powerful. Further, its cleanliness and consistency encourage programmers to gain a deeper understanding of the language's underlying semantics, and that has enabled the Ruby community to develop elegant and sophisticated meta-programming techniques and incorporate them into the culture. And that is what excites me about Ruby.

    Rails is a great example of this. It uses meta-programming extensively to embed domain-specific mini-languages into Ruby. These mini-languages make object-relational mapping, controller-view integration, and other aspects of web programming seem natural, effortless even. In many ways, Rails offers what Damian Conway argues for in his talk about Sufficiently Advanced Technologies.

    Catalyst, in comparison, seems clunky. While it may offer advanced technologies for web programming, they fall short the more "sufficiently advanced" versions that Rails offers. In many ways, this isn't a failing of Catalyst but merely a reflection of Perl and Perl culture. Many of the Rubyisms that make Rails elegant don't resonate within Perl. Using them in Catalyst would make it seem less Perlish and perhaps even awkward.

    Don't get me wrong: while I like Rails, it's by no means perfect. All in all, I would characterize it as darn good but not amazing. (Well, maybe if you're coming from Java/.NET, it might seem amazing.) Its caching model has problems. The Rails culture is somewhat enamored of sexiness and often overlooks things like web accessibility and safety (see, e.g., Google Web Accelerator vs. unsafe linking: Round Two!). Also, the incessant hype is annoying.

    Nevertheless, Rails is changing the way web applications are written. If you ignore Rails, you're guaranteed to miss something important.

    If you want to know a bit more about Ruby/RoR, I gave a talk about my experiences for the Pittsburgh Perl Mongers. You can get the slides here: Ruby and Ruby on Rails: A Perlish First Impression.

    Cheers,
    Tom

Re: OT: Ruby On Rails - your thoughts?
by Your Mother (Bishop) on Nov 17, 2005 at 07:34 UTC

    Spake the devil: Ruby on Rails. (disclosure: I've never used Rails, though I did try once and couldn't get the example from the movie working so gave up b/c it was just a lark--I've been using Catalyst a bit and haven't had any sticking points save the dearth of docs.)

Re: OT: Ruby On Rails - your thoughts?
by ciderpunx (Vicar) on Nov 18, 2005 at 11:27 UTC
    ... it's still not the difficult bits it makes quicker, just the boring bits, surely?
    That doesn't seem an entirely bad idea to me. I'd rather spend my time doing difficult stuff than boring stuff!

    I've been redoing our organizational intranet - previously built with a mish mash of perl, php and static html - using rails, and my overall impression is that it is very nice.

    Plus of all the languages that I've checked out, ruby seems to have picked up the expressive power of perl, and made object orientation (and closures) a lot more intuitive.