|
in reply to OT: Ruby On Rails - your thoughts?
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:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
|
Re^2: OT: Ruby On Rails - your thoughts?
by sri (Vicar) on Nov 17, 2005 at 17:24 UTC
|
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. | [reply] |
|
|
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:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply]
[d/l]
[select] |
|
|
package MyApp::Model::DBIC;
use strict;
use base 'Catalyst::Model::DBIC';
__PACKAGE__->config(
dsn => 'dbi:SQLite:/Users/sri/MyApp/test.db',
relationships => 1
);
1;
Thats all you need, table classes are generated and releationships auto-detected by analyzing foreign keys.
You don't even have to write it by hand, Catalyst has helpers to do it for you. ("script/myapp_create.pl model DBIC DBIC dbi:SQLite:/Users/sri/MyApp/test.db")
Bundle::Catalyst suggests only DBIx::Class, definitely not Class::DBI.
Yes Ruby looks a bit cleaner in "your" examples, but bad programmers write bad code in any language.
Ruby is also missing a lot that disqualifies it for me, especially Multiple Inheritance, i like NEXT and Class::C3 very much. (mixins are no alternative!)
Not to mention the bad performance and lack of modules...
So what exactly can't be written in Perl?!?!
Do you really think a tight integrated framework for Perl makes sense? Why?
The Perl community is very fragmented, we have many alternatives(TIMTOWTDI), TT, HTML::Mason, HTML::Template, DBIx::Class, Tangram, Alzabo, SPOPS... which two components would you choose for tight integration? They all have their strengths and weaknesses, so why not choose the best for the task at hand? Why not use multiple template engines, multiple orm's in the same application?
So far i've not even seen a single Rails app dealing with more than one database!
Oh, did i mention Catalyst now also supports PAR, ship all prereqs with your app, something Rails people can only dream of... | [reply]
[d/l] |
|
|
|
|
[ fields[ 1..4 ], fields[ 4..5 ], 0, 0 ].flatten should work in Ruby; passing a range to Array#[] returns the specified subarray.
Update: And additionally it'd be more idiomatic to use do . . . end rather than {} around your blocks. Granted I don't think it makes a difference in this case but the later does bind more tightly than the former.
| [reply]
[d/l]
[select] |
|
|
|
|
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 ;)
| [reply] |
Re^2: OT: Ruby On Rails - your thoughts?
by perrin (Chancellor) on Nov 18, 2005 at 06:28 UTC
|
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. | [reply] |
|
|
| [reply] |
|
|
