What’s so great about CPAN anyway?(adamjctaylor.com)
adamjctaylor.com
What’s so great about CPAN anyway?
http://www.adamjctaylor.com/whats-so-great-about-cpan-anyway
3 comments
I use Perl every day in product/home and have contributed numerous modules on CPAN. The "Ratings" argument is very very thin. Yes, CPAN does have a ratings system ; nobody uses it. Even very very popular and well-written modules, for example Data::Dumper, have below 10 ratings.
There is a new release candidate for CPAN that sets up some very nice defaults for using CPAN:
http://www.dagolden.com/index.php/1339/cpan-pm-release-candi...
http://www.dagolden.com/index.php/1339/cpan-pm-release-candi...
I don't know. For a Perl hacker this is rather boring, can it convince someone new to Perl?
I think new hackers could be easily drawn into using Perl simply because of the breadth of tools available in CPAN. Chances are whatever you need to do, someone has written a module for it. Why roll your own when there's a stable module?
Of course the new user may quickly run into CPAN dependency hell, but that's a different issue.
Of course the new user may quickly run into CPAN dependency hell, but that's a different issue.
Chances are whatever you need to do, someone has written a module for it
This used to be a big argument for Perl 10-12 years ago when I was actively working in Perl, and one of the things I kind of missed when I first switched to python. However I've found that many languages have caught up with (and in some areas surpassed) Perl in this regard over the past decade. What CPAN libraries are there today that are class leading and for which no reasonable equivalent exist for other languages?
This used to be a big argument for Perl 10-12 years ago when I was actively working in Perl, and one of the things I kind of missed when I first switched to python. However I've found that many languages have caught up with (and in some areas surpassed) Perl in this regard over the past decade. What CPAN libraries are there today that are class leading and for which no reasonable equivalent exist for other languages?
Of which 50% are abandoned and 25% are alpha. And 12% are duplicates and you need to decide which to use. At least that was the state in the 90s when all I did was Perl. [Fixed some English]
The irony is that even in environments like Java and .NET, where, in theory, one person makes all the decisions with respect to what libraries to include, there are 50% deprecated classes, 25% that don't work, and 12% are duplicates and you need to decide what to use. I don't think I've ever written a Java app where 90% of the libraries I wanted to use have been deprecated in favor of AbstractSimpleTaskFactoryConfiguratorInterfaceThreePointOh.
This is a programmer problem, not a Perl problem. What's great about Perl is that you are forced to use very few of these modules, so you can ignore the bloat once you've made your own decisions. Worse comes to worst, and someone rewrites some module you use and you get new features for free. I don't get all the complaining.
This is a programmer problem, not a Perl problem. What's great about Perl is that you are forced to use very few of these modules, so you can ignore the bloat once you've made your own decisions. Worse comes to worst, and someone rewrites some module you use and you get new features for free. I don't get all the complaining.
>What's great about Perl is that you are forced to use very few of these modules
That sort of kills the claim that perl is great because of the size of CPAN, no?
That sort of kills the claim that perl is great because of the size of CPAN, no?
Nope. Its darwinian, the more modules in the gene pool means newer/better solutions need to fight harder to survive & win. So the outcome is often better for Perl/CPAN, for eg. Moose
> Its darwinian
I think you're correct, but that there are trade-offs. Take Python, for example. They have "batteries included", and when modules make it into the std lib, they pretty much stop evolving. However, on the up-side, Python gains users who like having everything packaged up nice and neat so they don't need to go looking for modules quite as much.
Perl takes the popularity hit of not having too many batteries included, but benefits from the darwinian element that works to make the 3rd-party modules better. So, perlers need to spend more time asking around (or checking cpanratings), and also dealing with it when there's turnover (the module that they chose a few years ago is eclipsed by a competitor, or stops being maintained, and now they need to rewrite some of their code).
In the end, I think Perl has better modules.
I think you're correct, but that there are trade-offs. Take Python, for example. They have "batteries included", and when modules make it into the std lib, they pretty much stop evolving. However, on the up-side, Python gains users who like having everything packaged up nice and neat so they don't need to go looking for modules quite as much.
Perl takes the popularity hit of not having too many batteries included, but benefits from the darwinian element that works to make the 3rd-party modules better. So, perlers need to spend more time asking around (or checking cpanratings), and also dealing with it when there's turnover (the module that they chose a few years ago is eclipsed by a competitor, or stops being maintained, and now they need to rewrite some of their code).
In the end, I think Perl has better modules.
Yes i've touched briefly on CPAN vs stdlib approach before (http://news.ycombinator.com/item?id=2088040). They're just different approaches and neither is better or worse than the other.
BTW... I believe all language repos will have darwinism acting upon it. I see it in Ruby & Python as well as on CPAN. Its Perl philosophy and CPAN size that just stirs the pot a bit more!
BTW... I believe all language repos will have darwinism acting upon it. I see it in Ruby & Python as well as on CPAN. Its Perl philosophy and CPAN size that just stirs the pot a bit more!
That's your assumption. Higher quantity in no way implies that the quality entries will be higher than they would be in a system with less quantity.
You're the one who keeps making assumptions!
My statements about darwinism and also about Moose being better for Perl/CPAN are factually correct.
My statements about darwinism and also about Moose being better for Perl/CPAN are factually correct.
>My statements about darwinism
Darwinism has nothing to do with this. At best you're trying to invent a connection that doesn't exist.
Darwinism has nothing to do with this. At best you're trying to invent a connection that doesn't exist.
Clearly darwinism hasn't made trolls extinct yet :)
Based on your comments here and the fact you're a newly created account then I am going to have to make the assumption that trolls do indeed exist among us :(
Based on your comments here and the fact you're a newly created account then I am going to have to make the assumption that trolls do indeed exist among us :(
You seriously think I made this account just to troll you? Talk about defensive.
You seriously think I made this account just to troll you?
Of course not, that is just an assumption of yours ;-)
Seriously though I do feel your comments have had a troll tone and my previous statement was half in jest. So I do apologise sincerely if you have taken offence to it.
So again sorry and welcome aboard HN.
Of course not, that is just an assumption of yours ;-)
Seriously though I do feel your comments have had a troll tone and my previous statement was half in jest. So I do apologise sincerely if you have taken offence to it.
So again sorry and welcome aboard HN.
Still the same. Also, few people look at bugs reported via cpan. I never got a response to any of mine. At least you can see some packages going red on more and more systems, so it's quite easy to spot the useless/unmaintained ones.
True regarding duplication - if I had a penny for every new incomplete logging framework uploaded to CPAN, I'd be a rich man...
True regarding duplication - if I had a penny for every new incomplete logging framework uploaded to CPAN, I'd be a rich man...
No, people stopped writing logging frameworks years ago. Even Log4Perl and Log::Dispatch interoperate now. The cool new thing is web frameworks. But of course, due to PSGI, those all work together too! "There's more than one way to do it", but at least you can deploy them all to production in the same way.
As for bugs; trust me, people reply to them. Take a look at how many Moose bugs are "resolved", for example: https://rt.cpan.org/Public/Dist/Display.html?Status=Resolved.... That's a lot more than "never".
As for bugs; trust me, people reply to them. Take a look at how many Moose bugs are "resolved", for example: https://rt.cpan.org/Public/Dist/Display.html?Status=Resolved.... That's a lot more than "never".
Stopped? Years ago? Log::Fine (2008), Amphibic::Log (2010), Su::Log (2011), Easy::Log (2007), Log::Smart (2007), Log::Deep (2009), Util::Thread::Logger (2011), ...
I won't even mention all the one-module-specific mini-logging scripts which do it yet another way.
I won't even mention all the one-module-specific mini-logging scripts which do it yet another way.
I doubt those figures are (meant to be?) accurate.
In the 90's CPAN would have only had a few thousand distributions and looking at some stats from circa 2002 there were 5000 distributions from 20,000 uploads so the 50% abandoned figure does not sound correct.
ref: http://stats.cpantesters.org/statscpan.html
In the 90's CPAN would have only had a few thousand distributions and looking at some stats from circa 2002 there were 5000 distributions from 20,000 uploads so the 50% abandoned figure does not sound correct.
ref: http://stats.cpantesters.org/statscpan.html