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

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Tuesday August 22, 2006
04:49 PM

How many CPAN modules on the same topic is too many?

[ #30724 ]

Once I finished writing PPI (a process that spanned 3 years) it occured to me that I had reached my scaling limit. There was just no way I was ever going to be able to write anything larger than that on my own and remain effective.

Ever since, my favourite area of computing has become what we call "Programming in the Large". Dealing with the effective design of code and implementation of concepts far larger that you could ever hope to actually write yourself.

It means learning as you can about things like iteration and evolution can be intentionally applied to your design, learning how to treat concepts like "trust" and "property" as fundamental elements of design. And learning how to anticipate areas where, if you just give it a little bit of a push (like the Win32 Perl effort), you can get things past a sticking point and the natural inventiveness of others will take over and do the rest of the work for you (and a big thankyou to everyone that has been putting so much work in lately finding and fixing CPAN modules on Vanilla/Strawberry Perl)

Because I really like this area, I've also gotten much more heavily involved in the CPAN. After a couple of years immersed in it, I think I mostly "get" the CPAN. Exactly why it works so well, when others have failed, and the areas it should be doing better.

But one issue has remained a bit of a challenge for me, and that is the concept of "choice" as an element of design.

When it comes to common areas, CPAN often has more than one module that does the same thing. As a result, people searching for modules need to choose. That we have choice, and that people can upload any old crap they like, is one of the ultimate reasons for the CPAN's success, because in an iterative and evolutionary environment, betting on any single solution exclusively can be very risky.

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.

But one of the perplexing problems with choice is the problems of too much choice.

I've had it put to me by several Perl trainers that teach university students that having 4 modules for roman numerals is completely silly. It causes a problem for them, because students are trained to look for the one correct answer, so any university assignment featuring roman numerals causes much consternation.

The message from trainers on this issue of choice has been very consistent.

And one need only look at the number of modules for parsing Windows .ini files (my Config::Tiny included) to see how one could be completely flustered by the choices.

Sometimes having 5 modules to choose from, each for a different situation or that makes different trade-offs, is good. Sometimes 5 is too many...

So I was curious to see today that there is work being done on this very problem. On exactly how MUCH choice is a good level of choice. And how too much choice can make people sick.

For all those Programming in the Large devotees, the following video is recommended viewing.

Sorry about the RealPlayer format, but thanks go to the ABC for making it available to the world for free, from their (co-incidentally named) Catalyst science TV program.

http://abc.net.au/science/broadband/catalyst/ram/choice_hi.ram

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • book of all the most frequently annoying questions and criticism of the CPAN and post it somewhere...not that it would ever get read, but at least I'd have cut and paste.

    Nobody ever asks why there are 15 different mustards to choose from in the grocery, so I'm never quite sure why people get fussy about the selection on CPAN unless a) they have a module that fits in a namespace they want but is already taken or b) think everyone elses' module is shite save for theirs. It's a free archive...pick and choo

    • "Nobody ever asks why there are 15 different mustards to choose from in the grocery..."

      Agreed. That's why I'm going to take a cue from Shin Honda [cpan.org] and release File::STat, File::STAT, File::staT, and File::StaT tomorrow!

      Because, hey, variety is the spice of life.

    • If you had watched the video, you'd have perhaps gotten my point.

      If you offer people 24 mustards to try from, lots of people will come and look, but not many will buy.

      If you offer people 6 mustards to try from, fewer people will come and look, but MORE people will buy.

      That is the critical point here.

      Where I'm curious about is IF this applies to CPAN modules.

      I'm not complaining that it does.

      I don't know anyone left related to CPAN, me included, that honestly thinks that only having one choice for a single to
    • I should expose a few things up front. I run Perl Training Australia [perltraining.com.au], and my full-time job for the last five years has been teaching people how to use Perl. I've got a good idea what newcomers to the language like, and what they don't like.

      They don't like the CPAN. They absolutely adore it. One of the best parts of running an introductory course is letting our students play with the CPAN. It's very rare for a student not to find a module that directly helps them with their day-to-day work, with the

  • It causes a problem for them, because students are trained to look for the one correct answer, so any university assignment featuring roman numerals causes much consternation.

    This is such a crime! What ever happened to critical thinking? If anything could sum up my dissatisfaction with the education systems I've been exposed to it's that they train people to put blinders on and find "the" answer. :-(

    You may be interested to know that there was a Scientific American article not too long ago entitled "The Ty

  • 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 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