Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^4: Perceptions of Perl - views from the edge

by gamache (Friar)
on Feb 20, 2008 at 20:08 UTC ( [id://669095] : note . print w/replies, xml ) Need Help??

in reply to Re^3: Perceptions of Perl - views from the edge
in thread Perceptions of Perl - views from the edge

Which is frustrating, because I like perl, and I think perl could easily meet the challenges posed by rails.

I don't.

Technically, of course, Rails could have been written in Perl. Not even in a "Turing tarpit" sense of "could", either; Perl would be as good a choice as any language, all other things being equal.

Rails, however, benefits greatly from the attitude that a few ground rules can simplify everyone's life. In other words, convention. Joe Perl does not like other kids telling Joe Perl what Joe Perl can and can't do in Joe Perl's sandbox. Joe Perl is allergic to convention.

Now, before anyone starts hucking Molotov cocktails at my delicately handcrafted strawman, let's compare and contrast RoR with its closest Perl counterpart, Catalyst.

  • Language: Ruby and Perl are just about even in the sort of things you can do; they're both modern dynamic languages which support most common design paradigms. Differences of style are just that; anything expressible in one language isn't too hard to say in the other. Perl has a steeper learning curve, due to its rich syntax, but also greater support for shell-like file manipulation and quick-and-dirty coding. Tie.
  • Model: Rails uses its flagship ActiveRecord class as the basis for its data modeling. ActiveRecord is a highly reflective object-relational mapping framework which supports most SQL databases. Its capability to predict the sort of class methods you want, and write them for you, is second to none. Catalyst, conversely, leaves the choice up to the programmer. DBIx::Class? Class::DBI? Class::DBI::Sweet? There's more than one way for the idiot who you're replacing as lead programmer to have done it, and none of them match ActiveRecord in ease of use OR features. Winner: Rails.
  • View: RoR gives you ERB. If you know Ruby, you are about twenty seconds away from knowing ERB. It is very similar to HTML::Mason, actually, which is available in Catalyst; Ruby is ERB's template language, just like Perl is Mason's. ERB, however, is much better and more concise at HTML form generation. Catalyst again declines to enforce anything. Want to use HTML::Template, TemplateToolkit, or ZOMG::D00d::T3mpl4t3? No problem. They all suck more than Mason and ERB though. Winner: Rails.
  • Controller: RoR has it all over Catalyst. More features, cleaner syntax, easier routing (rewriting) control. No holdover bits from either. I haven't found an easier way to specify a web app's internal plumbing. Winner: Rails.
  • Leftovers: Rails' DB migrations are just super. No equivalent on the Perl side. Likewise for Rails scaffolding, which can take a DB table definition (as from a DB migration) and spit out skeleton models, views and controller to implement the "golden seven" actions: index, new, edit, create, show, update, delete. Winner: Rails.

If it sounds like I'm on the verge of gushing, I am. If it sounds like I am fed up with Perl's bullshit, you're right about that too. If it sounds like an unordered list full of bullshit, you're going to have to convince me of that. And if it sounds like muted, low-frequency tones at a spoken cadence, your head might be in the sand too.

There is something to this Rails thing.

  • Comment on Re^4: Perceptions of Perl - views from the edge