Do you know anyone who is language-agnostic and has chosen a Perl MVC framework to build a new web application?
All of the people I know who have been using Perl frameworks (and there are many who have been using them very successfully) are people who would choose to do any programming task in Perl. But I don’t know of anyone who has thought to themselves “I need to build a new web application, let’s review all the framework options in all the languages - oh look, that Perl-based framework looks good, we’ll use that”. Do you?
I think that at least part of the problem is the sheer range of options that Perl gives you. There’s Maypole, Catalyst and Jifty. There are lightweight frameworks like CGI::Prototype and CGI::Application. I’ve almost certainly missed some. And now there’s Woodstock. Woodstock is the new framework which will be designed by Sebastian Riedel to fix “a lot of design mistakes in Catalyst”. And let’s not forget that Sebastian originally started the Catalyst project as a fork from Maypole because he didn’t like the direction it was taking.
Part of this stems from the perfectionism of the Perl community. If you’re not completely happy with the way that a module works, you fork it and write another version that works how you want it to work. This means that a new user looking for a module can now have more choice and choose one that works exactly how they want it to work. But the evidence would seem to indicate that they are unlikely to do that. They’ll either add another fork or they’ll decide that they can’t decide between the two very similar looking modules and go off to use something completely different (probably a different programming language completely).
The Ruby community doesn’t work that way. Rails isn’t perfect. I’m sure they realise that. But you don’t hear of people creating forks to make it work just the way they want. They just work within the restrictions and present a united front to people looking for an MVC framework. If you want an MVC framework in Ruby, there it is. Take it or leave it. And as it works well for the majority of cases, a lot of people take it.
So, as I see it, you have a choice. You either give people options and they decide it’s too hard to choose and go eslewhere. Or you tell them “this is how we do it” and hopefully they’ll like your solution. I used to think the Perl way was the right way to go, but now I’m not so sure.
Perhaps I should be a Ruby programmer :-)
It's an fairly standard point you make, and one those drinking the Rails Koolaid absolutely love. And economists grapple with these issues too quite a lot.
Sometimes too much choice is bad. If choice leads people to confusion, they get stressed and hate you (Perl in this case).
A similar point was brought up by a group of University people teaching Perl, one of whom had set an assignment meant to teach people to use modules. It involved Roman Numerals.
But the students had problems, because on CPAN there are 4 packages for dealing with roman numerals. But students are trained to look for the right answer... "What's the right one miss?"
Trouble indeed.
And of course, sometimes you can be stunningly successful by limiting choice because you've crafted the ultimate expression on a concept. The Model T Ford. The iPod. The IBM ThinkPad :)
But the trouble is, by limiting choice you limit flexibility. Maypole may have pioneered the MVC concept on CPAN, but how could Simon possibly have predicted that his default Class::DBI model class would go through an upheaval and become a scary choice for many people.
What happens if ActiveRecord turned out to be terrible at handling parallel databases (which don't exist yet, since I just invented them in this sentence).
What happens if they bet on a bad Ajax system (and they have! prototype.js for all it's poineering ideas is horribly abusive to the Javascript object model and doesn't play well with others)
In deciding to JFDI (pun intended) and choose an "integrated best of breed" approach (to use the bizspeak), how sure are you that you come up to the standard of the iPod or the Model T Ford?
In the long term, it's very often the most flexible that triumphs over the fittest. And in IT, this is particularly so at the big corporate end of town. Catalyst, possibly unlike Maypole, has certainly survived the Class::DBI-->DBIx::Class transition relatively cleanly.
Jifty certainly looks like a Maypole-killer. Catalyst is looking more and more like a Mason(etc)-killer. They are both quite possibly the definitive examples of the two different approaches.
But the really interesting question is, will the Jifty approach or the Catalyst approach survive the best over a long period of time...
I can't wait to find out.
Harry Fuecks is a PHP advocate and author. In November 2005 he wrote a series of articles over at SitePoint on why he chose to use Catalyst for a project.
Articles:
Perhaps you should :) - a lot of us used to be Perlers, you know.
Rails certainly isn't the only MVC framework for Ruby, either.
Have a look at Nitro and Og sometime:
http://www.nitroproject.org/rdoc/nitro/index.html
Well, Perl isn't the only language with a surfeit of choices when it comes to web frameworks. We've been trying to pick a Java framework at work recently, and it's bewildering to say the least...
Python is suffering from multiplicity too, what with TurboGears vs Django (which is built onto CherryPy some ORM whose name I don't remember which are components that some people use individually without a big framework), and then there's web.py.
Remember too that most of the Perl and Python frameworks that are now seen as RoR competition are older than Rails.
I guess what happened in Ruby was that the language as a whole had no entrechned community, much less entrenched framework communities. So the 37s crowd built a strong framework and then started to crank up the hype machine for the language as much as the hype machine for the framework. The name Ruby on Rails alone is pure marketing genius. Right now, there isn't much of a Ruby community to speak of that is not a subset of the Rails community. I'd say that things will stay neatly converged for as long as the set of productive developers at the core of the community doesn't grow or shift too much. But I don't believe that Ruby can remain the Language With A Single Web Framework indefinitely.
Now, you have to factor in the culture. Perl has a culture of TMTOWTDI; it's hardly surprising that the community spreads out every which way and does every thing in more than one way. Python has a culture of TSBOOWTDI, so the community generally tends to condensate into entrenched factions, although generally smaller and fewer in number than in Perl-land. Ruby's culture is not as clearly definable, but if it's anything I think it's "convenience matters most". Time will have to tell if that's it, and how the Ruby culture affects balkanisation trends.
I predict some fragmentation in the Ruby community, but only in several years from now. We'll see.
Err, that was supposed to say that TurboGears is built on CherryPy + foo + bar - not Django.
I think part of the problem with most Perl frameworks ( I haven't investigated most of the others other than Django ) is that when you choose a framework you are really choosing a set of contraints to live by. People don't like constraints. By constraints I mean "Oh if I use framework X I must use ORM Y or Z, too bad I like ORM W, I guess I'll go build my own."
This comes from trying to do, IMHO, too much for you.
One framework that I've been involved with named Gantry is nice in that it doesn't force too many constraints on you, but takes care of the main aspects a framework should take care of, but doesn't tie you into OneTrueWay(tm) so to speak. It pretty much stays out of your way when you want it to.
I think it's worth checking out if you haven't looked over it already.
Rails certainly isn't the only MVC framework for Ruby, either. Have a look at Nitro and Og sometime
But they're nothing special - Og (the ORM wrapper of Nitro) works from the other end of the object-relational bond: it is just a database-backed persistance mechanism for your existing objects.
Rails immense success is rooted in the combination of many small useful features that make development easy and fun. The thing I like most is the loose coupling between different components - which allows you to base your models on non-relational databases (LDAP for example), or to use more powerful ORM library (like ActiveRelation, which is a very promising proof of concept).
It's good to keep Tim Toady around, but he smells kinda funky, so I personally only bring him out of the closet when I absolutely, positively need to kill every motherfu... uhh, wrong movie, but you get the idea.
As for Rails being the only game in town being a negative point, it's worth noting that it's more than possible to use components of Rails outside of Rails. Check out what whytheluckystiff did with ActiveRecord in his Camping micro-framework (under 4kb!)
Frank, I'm afraid you're somewhat wrong there - the whole point of Catalyst is that it *doesn't* make those choices for you. We have active users using at least three different ORMs (DBIx::Class, Rose::DB::Object, and a few holdouts still on Class::DBI), a fair few using DBI and at least a couple using Tangram. Not to mention the people who don't have a database at all and are using Catalyst to talk to LDAP or something else entirely different.
Gantry is sort of like a quarter of Catalyst done badly, and Maypole is too restrictive and generally only useful for trivial CRUD applications. I'd anticipate the perl framework war will become a two or possibly three-horse race, with Catalyst for people who want MVC and choice, Jifty as a "one true way" non-MVC system and probably an opinionated system on top of Catalyst as the "one true way" for MVC. Sebastian's new project should be an interesting experimental system but I suspect anything useful will probably get rolled into Catalyst by the core team (although at the moment we're currently busy refactoring stuff and stealing the best bits of Jifty :)
Hi,
Check out http://perl.cuckoo.org/ - I've put it together as MY list of modules that you should use.
Hope that helps :)
Leo
You're touching into THE problem when it comes to Perl and it's community.
This doesn't just apply to choosing frameworks, it's the same when it comes to modules.
"It's so cool" that CPAN contain all the resources it does, but it actually is a big problem as well. Most CPAN modules are in a 0.xx state, meaning they're not finished/lacks implementation/may have bugs. And, you have a ton of different modules doing almost the same thing, but in slightly different ways.
What if the (obviously) genius minds would COLLABORATE instead of competing?
CPAN - it should have been Collaborate Perl Archive Network...
tv, what does a version number have to do with anything, especially if you believe there's too little collaboration and consensus?
Woodstock is now called Mojo. It's hard to have any opinion on it, since there haven't been many details revealed about it yet.
@tv: I think CPAN is good as it is. There is collaboration when people want to, e.g. the Catalyst project, but what we have there is evolution in progress - survival of the fittest. The modules that survive are those that get downloaded and used. IMHO, this is the strength of open source in general and does lead to the best code rising to the top (although there can be fighting along the way).
Version numbers are interesting. I think a lot of authors are a bit too modest and don't rate their work as 1.0 ready, given the number of 0.x modules there. Look at POE for example, it's really good, been there for years, people write articles about it but it is still 0.34. I think it's safe to go 1.0 now guys...
Had been hoping, that with time, the best solution would float to the top. But on the other hand, if you look at all the active templating options still out, you begin to have your doubts.
Interesting discussion. As regards CPAN having a survival of the fittest approach, is there some officially sanctioned means for the average developer to know which modules are in fact the most used or considered the best? Obviously, reading articles like this helps.
Seems woodstock never showed up anywhere??
The potential for confusion is always greater with multiplicity, but multiplicity does not imply confusion, and has many advantages over "the one
true way" approach.
What is needed is for groups/organizations in the Perl community to make it their duty to clearly articulate the features of the various/main frameworks so as to eliminate the potential for confusion.
I've largely developed in Django/Python (2005 - present) but I've decided to make Perl my main interpreted language.
You know, it's a real pity I fell for all the crap talk about Perl being line noise etc, I would have chosen it over Python initially were it not for this hype. Most good programmers document their code anyway and if it was really a write-once language as some of these people claim, how come large companies like IBM use it and have been using it for all these years?
I've been looking at the language intensely for about a week and a half now and I'm liking the syntax and constructs much more than those of Python -- and why does Guido think he needs to tell me how to indent my code? This s**t ticks off scores of programmers, programmers are creative people, don't like to be put in a straight jacket. I always thought snakes were flexible?
If communities stop over-hyping their language people may find and gravitate to the language that fits them more naturally.
I'm not saying that I won't program in Python anymore, but a want to focus more on Perl and I'm looking for a good Perl MVC framework. I may try Gantry first. I'm hearing good things about it -- and I can access the site and the documents.
Also heard about Catalyst, been trying to access the site yesterday and today -- seems that the domain name has expired. These things turn serious people off! You are the biggest badest Perl framework with the most features and you let your domain name expire without renewing it! Can you really be serious?
Actually ruby, has more than 10 different frameworks. Merb is quite popular (and considered to be better than rails by some). The real problem with PERL is PR. It's good that we all love it, but if newbie programmers don't dig it what's gonna happen to it after we are gone?
I've decided to make Perl my main interpreted language
Shame it's not an interpreted language then :-)