CPAN Quality

acme on 2001-11-09T10:08:05

CPAN is one of Perl's greatest achievements, and is the one of the reasons why it makes easy things easy (by being lazy, we just reuse other people's code). However, occasionally some of the code on CPAN is not up to the quality we expect. Some of it is not enterprise ready. Some of it has poor documentation. Some of it is unperlish. Most have few tests. Some have bugs. Some are just stupid.

CPAN is the public side of Perl. If my manager finds out that a certain module I'm depending on is not up to scratch, he'll mumble something about J2EE. While kwalitee is a fine idea, what we really want is quality. I want code on CPAN to be good the moment it is uploaded and made public, not twenty revisions down the line.

Of course, we can't change CPAN. We fear change. Change may make it wither and die.

So what can we do? I say we use the following argument:

  • Programming is an art
  • One cannot judge whether art is good or not in the general case, only in the personal case
  • So stop sending me bug reports

Yes, I love CPAN really. And no, the act of sending bug reports can not be considered "Art" ;-)


Art?

2shortplanks on 2001-11-09T11:12:46

Who are you to say if Bug reports are art or not? Stop repressing me man!

Do you remember going around Amsterdam at YAPC::Europe::2001, seeing all these weird statues in the street. IIRC the conversation went something like this:

"What's that?"

"Dunno. I don't understand it."

"Must be art"

I could draw comparisons to CPAN. CPAN does have very cool stuff that can make water seem like it's running uphill, but it also has stuff that keeps making you walk off the side of the path too.

I'm sure I had a point here somewhere.

*sigh*

hfb on 2001-11-09T15:05:09

CPAN is an archive, nothing more. If it were for the benefit of corporations it would have an 'E' in there somewhere like "The Comprehensive Enterprise-ready Perl Archive Network".

This doesn't prevent someone from making their own archive of enterprise-ready modules, however this would take a lot of work. With the current upload rate of ~15 modules a day on average, it would take at least one person doing review 40+ hours a week.

Also, I hear there are some who believe in Open Source but want bugs to be a closed source kind of thing. Right.

CPAN is an archive. If you want something management will get a boner over, I encourage you to make an archive and maybe it will catch on. Whither CPANTS and NAPC? If you have modules that irritate you, write an article for use Perl; . One thing we can all be sure of is that talking about it doesn't bring you any closer to fixing the problem you wish to solve.

Re:*sigh*

2shortplanks on 2001-11-10T11:54:36

I think you're missing the sarcasm in acme's journal. Maybe it's a brittish thing...I blame all that monty python myself. Next thing you'll be beliving that davorg really does want to have Symbol::Approx::Sub in the standard Perl distribution. ;-)

Anyway I think the point acme was trying to make is that CPAN is different and odd and good and all of these things at once, and judging it just a from a buisness perspective is a really silly thing to do. Maybe it is all art! Maybe people do just do it because they can, and it's a good thing in general not just for buisness. Isn't that the point acme was trying to make?

Re:*sigh*

davorg on 2001-11-13T12:01:05

Next thing you'll be beliving that davorg really does want to have Symbol::Approx::Sub in the standard Perl distribution. ;-)

You misunderstand. I want it in the Perl core. You know it makes sense!