[swombat]

Anyways. CPAN _is_ the killer app. It's a HUGE, extremely easy to install module/library archive. Perl's modules aren't spread around everywhere but neatly and nicely collected there and you just do a "cpan Foobar" and get Foobar with all possible dependencies included.

Sounds like Ruby's Gems: http://rubygems.org/ or even python's PyPi: http://pypi.python.org/pypi ...

[Mithaldu]

CPAN is the killer app for developers because it is: - an archive of libraries for them to use - a publication mechanism - a documentation mechanism - a global distribution mechanism

And most importantly: It provides you globalized automated testing on a variety of systems of anything you upload, through CPANTesters.

Just as an example: I uploaded a module yesterday and now it has 38 tests on as many different configurations already: http://matrix.cpantesters.org/?dist=CGI-Application-Plugin-T...

So not only gives it a very useful and otherwise extremely expensive tool to you, the developer, it also shows you this information about other modules, so it lets you gauge the quality of the modules you are considering to use.

Edit: Also, as an additional goody: The testing culture of CPAN allows development of ancillary tools that analyze the current state of CPAN and highlight modules that are having issues with their tests: http://analysis.cpantesters.org/ This can help generate bug reports for developers who don't have time to figure out exactly why a test failed on an obscure combo and they provide an in for CPAN-Newbies by pointing out to them which distributions could use patches.

[Su-Shee]

Err.. yeah - what do you think after whom gems etc. are modeled? :)

Haskell's system is called "hackage" for example and "R" has its "CRAN" and so on.

Though it's really no fair comparison as CPAN contains what.. 89033 modules? http://search.cpan.org/

[swombat]

Just because it was modelled after CPAN doesn't mean it's not better.

I'm not very familiar with PyPi since I'm not a Python programmer, but Gems pretty much work exactly like they should. Especially when you throw RVM into the mix.

[btilly]

Ruby gems by default don't run unit tests. If you care about reliable software, this is a bad thing compared to CPAN.

[microtherion]

And CPAN itself was modeled after CTAN, as far as I recall...

[danieldon]

    89033 modules

Only 21694 distributions, though. The analogue in Ruby is a gem and RubyGems already has 19502.

[ldng]

Ok. Shitload of lib err bricks. Great. Where are the prefab houses (frameworks) that help you get the thing done ... fast ? Perl has building blocks but lacks known products. Either finished products you just have to configure (like Drupal or Wordpress) or higher level building blocks (say Rails) that help you get where you want to get faster.

Note I didn't say there is not such product/framework, just, as the articles says, they are not promoted/known.

[Mithaldu]

Mojolicious, Dancer, Catalyst (biggest and most enterprise one), CGI::Application, Jifty.

There's a whole bunch of them, with different design goals or philosophies.

[ldng]

I didn't there wasn't, just that the need better promotion. Call it screencast if you wish. They need Promotive Passionate Users.

[edit] I'm gonna pick a little bit on Catalyst and do a quick surface review at website level from a non-Perlist POV.

Homepage : ok, looks nice.

Documentation : uuh ! Dry redirect to CPAN. First impression before reading, it's not the doc, it's the API doc. Ah, wait a second, it _is_ the doc. Not very appealing and some things are so not obvious that it takes a note to understand it like "Note: Click on the heading in the previous line to jump to the actual chapter. Below is a "table of contents" for this chapter."

Download : Again directly to CPAN, at first sight confusingly looks like an API doc. For newcomers not versed in Perl it is not very friendly.

Community : not much to say, a good wiki with apparently interesting stuff to read. But the first thing you see is that the "Why Catalyst is an excellent web application framework?" is an empty page.

The perl community has every reason to be proud of CPAN. It's great tool but it's not the answer to everything. It's all therem but it lacks the last mile, the 20% of polish to make it a tad more friendly/attractive.

It's the whole point of the article I think. It's not to criticize Perl, just to say it needs a better marketing strategy.

[loewenskind]

>Though it's really no fair comparison as CPAN contains what.. 89033 modules?

Why do people keep trotting out this stupid pointless number. How much of that is duplication? How much of it is crap? How much of it is literally toys (e.g. ACME stuff)? In any case, Java has vastly, vastly more so any language that runs on the JVM automatically beats perl here.

99% of programmers will never notice any functionality missing in Ruby or Python that CPAN has.

[chromatic]

Why do people keep trotting out this stupid pointless number.

Metcalfe's Law. The value of the CPAN increases dramatically with every addition, especially because of the maturity of the entire CPAN infrastructure: CPAN testers, CPANTS, annotations, reviews, dependency tracking, BackPAN tracking, gitpan, linked documentation, et cetera.

[loewenskind]

>CPAN increases dramatically with every addition

Demonstrably nonsense. Let me add a new module called ACME::DoNothing. What have I increased besides disk space and a meaningless module count?

[chromatic]

You've tested the entire CPAN ecosystem, as well as the ability of the ecosystem to identify and remove harmful contributions, if said contribution is in fact harmful.

[loewenskind]

I'll concede that that is very good. And I'll also concede that I can't think of any other systems that do this as well as CPAN (if at all). But my point remains that for 99% of developers we want a library that provides functionality (e.g. an ORM for a common database) and in that respect CPAN will only have an advantage for very obscure requirements. And even then it still loses to Java.

The testing stuff is good and it's the direction everyone should be going but not having it obviously isn't too much of a problem because so few systems currently have it (CPAN was successful long before it had it as well).

[FraaJad]

As a seasoned Python programmer,I think PyPI doesn't even come close to CPAN.

CPAN is the only reason that I've kept my Camel book around since 2000, hoping that "someday" I'll learn Perl.

[sigzero]

Neither one of those actually holds a candle to CPAN.

[steveklabnik]

Then maybe CPAN's advantages shouldn't be explained as "gem install", err... "perl -e -MCPAN "install net::foo". Explain the _actual_ strengths of CPAN that make it a killer app.

Oh, and "It has MOAR!" isn't really a good argument. I've authored two gems, I think. Those are the only two times in two years of using Ruby that I haven't had the ability to just install the library that I needed.

(I loved Perl for years until I found Ruby, then never turned back...)

[kentnl]

Tests. Integrated Bug Tracking. There's 2 reasons.

[steveklabnik]

Sweet! Then lead with that. I'm not saying that CPAN isn't better than Rubygems somehow, but that "easy installation" isn't a selling point.

[ack]

try "cpan Module::Name", which installs the requested module

[steveklabnik]

Sweet. That's still on par with Rubygems, cabal, and everything else, though. That wasn't my main point.