Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

How many CPAN modules on the same topic is too many? 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I'll leave the "too many choices" part alone, as I basically agree with hfb. :) Also there have been a couple threads on "separating the wheat from the chaff" on perlmonks recently, so it no longer interests me.

    But I do have to offer another suggestion for the relative success of Maypole and Catalyst. You claimed:

    Just look at Maypole, who could never have predicted that the ORM module they chose (Class::DBI) would so suddenly fall out of favourite with developers and suddenly turn Maypole from the cutting edge into a second-tier choice amoung the Perl technorati.

    It is notable that its logical successor Catalyst embraced choice and diversity, and so when the Class::DBI debacle occured, it was quite a different story. While maintaining Class::DBI for compatibility, they have switched their default choice to DBIx::Class and have moved on with relatively little negative effect.

    I wouldn't claim to know for sure, but I don't think Maypole's choice of Class::DBI has much to do with Maypole's being relatively less popular than Catalyst. My impression, having followed Maypole's initial development, is rather that Simon (Cozens) intended it to be more of a proof-of-principle framework that he worked on while he had funding from TPF. Catalyst got started as a fork of Maypole, after Simon lost interest in it. See for example the list of maintainers of Maypole [cpan.org] to find that Sebastian Riedel maintained Maypole for a while. Until he forked it into Catalyst. If you look in the Changes file of Maypole, you'll also see that several of its contributors are Catalyst developers.

    So my conclusion is that the choice of database abstraction layer has little to do with the popularity of Catalyst.

    • So my conclusion is that the choice of database abstraction layer has little to do with the popularity of Catalyst.

      I agree, but here you're refuting a point that Alias didn't make. He didn't say it made Catalyst more popular than Maypole. His point was that, because "Catalyst embraced choice and diversity", they were able to switch "their default choice [of ORM] ... with relatively little negative effect." That's just one example of how a certain amount of choice in building blocks can allow a frame

      • It's true that there was already some muttering on moving away from Maypole at the time, but it WAS still considered to be the dominant choice for web MVC.

        While it may have happened in any case that people moved away, having Class::DBI going boom most certainly accelerated the migration.

        From the point of view of someone not actively involved in the web MVC developments (since I have my own MVC framework) it was almost an overnight migration, much much faster than you would normally see.

        As for Catalyst vs Ji
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.