in reply to The Limitations of the CPAN

It seems that you don't like Perl 5 for OO programming in the large, but you like Ruby for some unspecified reason, and you seem to vaguely favor Java as well. You also decry the lack of proper OO training in the schools. And CPAN seems darn near useless as well. Having a bad week? :)

I can't discuss the problems you see with the Perl 5 object model, because I don't know what they are. So I'll address the useless nature of CPAN.

The main problem you seem to have with CPAN is that the modules that would have been useful to you in your most recent enterprise project were in their infancy or not available. That is unfortunate, but I think it proves the opposite point you intended to make. You wanted to use CPAN, to not reinvent. If Class::DBI or one of its derivatives was in its infancy, why not use and help develop it, rather than starting your own OORDBMS module? In that CPAN has hundreds of mature modules and thousands of promising starts, CPAN is valuable, and getting more so every week. Communities for other dynamic languages recognize that CPAN is one of the strengths of the Perl and seek to emulate it. Some of them may have problems with Perl's object model, but easy reusablilty of class modules is not one of them.

I agree that for large projects, CPAN modules tend to make up a smaller portion of the code. But I think this misses the point. CPAN modules are not meant to do everything you might need in an enterprise application. But if it is a common task, or involves some sort of agreed upon standard, there is probably a CPAN modules for it these days. CPAN modules make easy tasks easy, which makes time for coding the hard stuff possible.

-Mark

Replies are listed 'Best First'.
Re^2: The Limitations of the CPAN
by Anonymous Monk on Nov 17, 2004 at 19:07 UTC
    No, he's NOT saying CPAN is useless, per say, but that for large scale applications CPAN is a minor minor piece that doesn't play a big role, and what you normally get from CPAN can be found elsewhere.

    "CPAN modules make easy tasks easy, which makes time for coding the hard stuff possible."

    As does most of the Ruby language and it already has a huge set of libraries already available. The point is that folks use CPAN as a crutch, it is a very very nice feature, but at some point language cleanliness is not balanced by CPAN. That is, CPAN is not a member of the language cleanliness argument, and CPAN could exist in any language, nothing makes it a Perl-ism other than the way it happened.

    The OO argument is very valid. Languages with a strong OO culture that get it right (Ruby, Smalltalk) are ones typically with very good language design. Java goes one way, Perl goes another.

    A weak (or just sleep deprived or rushed) programmer is prevented from doing damage by what Java makes hard, but is enabled by what is made clean in Ruby. In Perl, he's likely to introduce some obscure errors. It's about language tools, not language shackles. Perl offers something akin to language TNT. Very powerful if properly directed, but can create maintaince nightmares.

    Yes, I *have* unfortunately written code that I didn't grok three weeks later. It's true. Of course there is java code I've never groked at all. Just from experience, Ruby is ultra spiffy clean, and I can't wait for Perl 6.

[reply]

      No, he's NOT saying CPAN is useless...

      Thank you for writing that. I thought maybe I had explained myself properly, but since you get the point I was making, I don't have to remake it :)

      Cheers,
      Ovid

      New address of my CGI Course.

[reply]
Re^2: The Limitations of the CPAN
by Ovid (Cardinal) on Nov 17, 2004 at 19:36 UTC

    The anonymous monk made most of my points for me, but I wanted to clear up one thing: I do not favor Java. Java has some good points but it is certainly not my first choice of programming language. For a given problem that both are suited for, a skilled programmers will still get more done in Perl than in Java.

    Cheers,
    Ovid

    New address of my CGI Course.

[reply]
      For a given problem that both are suited for, a skilled programmers will still get more done in Perl than in Java.

      A skilled programmer ... huh. Either we're speaking about skilled programmers or we're not. If we are, then Perl is a perfectly good enterprise-level language. If we're not, then Java is the better language all around. Which is it?

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

In Section Meditations