Slash Boxes
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.
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 cutti

    • 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 framework to survive when one of those building blocks goes boom.

      Where you referred to "choice of database abstraction layer", notice that Alias referred to it as a "default choice". That hints at Catalyst's answer to his main question, what's the right amount of choice? While Catalyst does offer a lot of options, it takes a middle-way, Pythonesque approach of providing "one obvious way to do it", via both documentation and helper scripts that use good, default options.

      I don't think Maypole's choice of Class::DBI has much to do with Maypole's being relatively less popular than Catalyst.

      Here your criticism is well taken. The "Class::DBI debacle" Alias refers to occurred well after Catalyst forked from Maypole, and Maypole's popularity was already waning. The fork occurred for many different reasons, several of which probably have something to do with the popularity difference. Not that the reasons for the fork are the whole story, either.

      However, a look back at the old Maypole list (start here []) shows that "amount of choice" was a big issue that led to the fork. While Sebastian Riedel found Maypole "too CDBI/TT2 focused", many respected developers thought it was a very bad idea to provide more choice in building blocks. Tony Bowden actually wanted Maypole to be "even more entwined with them [CDBI/TT2]." [] And while it's true that Simon Cozens had given up maintainership, he had hardly "lost interest" in Maypole. Simon more than anyone else pushed Sebastian to fork, and one could argue that the "amount of choice" issue was one of the reasons.

      All that said, I find the comparison of Catalyst to Maypole too narrow. I'll be making a long term comparison of Catalyst to Jifty [], which takes a more Maypole-like approach of limiting choice in favor of simplicity, but is starting to achieve a Catalyst-like level of hype [].

      • 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