[jsrn]

    > Vim's recent resurgence can largely be traced
    > to development of Textmate grinding to a complete
    > halt.

makes sense - but then why didn't Emacs see an equivalent resurgence (although personally I think Emacs did see a resurgence, not because of Textmate but because of Org Mode).

    > Git beats seven shades of shit out of SVN.

you could argue the same for Mercurial (or darcs, for that matter). But Git had the better initial marketing, Github, the Ruby folks used it etc.

    > I cannot think of anything that's changed in Perl
    > that'd justify any such interest.

hm, CPAN (and the arguably failed attempts to copy it by other language communities), Moose, MooseX::Declare, Devel::REPL, Dancer, Mojolicious, Task::Kensho, ...

[mechanical_fish]

I think emacs did see a similar resurgance, for the same reason that vim has. We just each tend to notice different resurgances depending on which editor we use...

And here's some constructive criticism for the aspiring Perl advocate: Stop talking in acronyms and obscure library names. What the hell is Moose and what real world problem does it solve significantly better than the popular alternatives?

Same for CPAN, frankly. Most people younger than me don't get it when you name-check CPAN. What does that stand for?Give me a killer app for CPAN, preferably one that people care about.

Note that the parent post speaks in use cases: Ruby is for problem X, Erlang is for problem Y, JavaScript is for problem Z. What is Perl for, and why won't Ruby work just as well?

[Su-Shee]

Well....

How about Django, Evently, Moustache, CLOS, Hackage, Sinatra, Merb, OMQ as acronyms? ;) (None of it Perl..)

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.

Which is something what many languages (some still don't) have these days one way or another but really nothing compared to CPAN in number, service, search, testing facility and so on. You plainly _never_ have to bother searching your ass off to find some library you might need.

Moose is Perl's OO system - as with JavaScript you can do different OO styles with Perl and Moose is a framework to do a role/trait based (please see Smalltalk for details or Perl 6's spec) OO with a heavy twist on metaprogramming.

Perl is for writing things like Amazon or the IMDB and keep it running for 12 years in a row or for creating Nagios and SpamAssassin to watch over half of the Internet. Thanks to Perl, everybody can easily imagine what push, pop, shift, unshift on Arrays/Lists does and thanks to Perl everybody has very shiny Regex these days. That's why Vim has a magic/nomagic flag and what the P in PCRE stands for. The Ruby world gladly thanks Perl's DBI after which it modeled its own database interface.

That's what Perl is about. Sharing shiny features and establishing a culture of "getting things done who run really fast".

[jcoby]

The problem with perl is that it got a bad rap and has never shaken it. The "perl is line noise that makes magic" sort of reputation. The people who love perl don't seem to be interested in moving the language forward and shedding the old ways of doing things.

Now.. CPAN.

Let me explain my latest round with fighting Perl/CPAN. I wanted a perl interactive mode. When I want to test out something in Ruby I use irb. In Python, I can type in `python` and enter interactive mode. Even PHP has a rudimentary interactive mode now.

So I try looking at `perl --help`. Nothing there. So I turn to google and find that I need a REPL whatever that is. So I try to figure out what a REPL is. Find that. Now I find that I need to run a little script to run Devel::REPL. Doesn't work. So I load up CPAN and type in `install Devel::REPL`. No less than thirty minutes later, 150 or so screens of noise, and at least 25 questions that I have to hit [enter] for I get a failed install. I have no clue what failed -- something to do with tests (the error is 4 screens back in the middle of even more text) so I try to force the install. I'm now 45 minutes into this and finally get Devel::REPL installed. I fire up re.pl and I get `SCALAR(0x100b81070) is not of type SCALAR at /opt/local/lib/perl5/site_perl/5.8.9/namespace/clean.pm line 56`. All of this for a feature that should come with a base install.

This is just one example of why I avoid perl as much as possible.

[mst]

As the author of Devel::REPL, I've never seen that error or have it reported.

If you want to email me (address in profile) I'd love to figure out what went wrong so nobody else has the same problem in future.

[jcoby]

Email sent.

[jcoby]

For the record, upgrading Package::Stash fixed it.

[microtherion]

Notwithstanding your apparent problems with CPAN, the traditional way to go to an interactive mode in perl is

perl -de0

which still seems to work.

[jonknee]

> Perl is for writing things like Amazon or the IMDB and keep it running for 12 years in a row or for creating Nagios and SpamAssassin to watch over half of the Internet.

Perl was the hip thing back when those projects were being developed. If they were being made today, it's overwhelmingly likely that Perl would not be used (see Facebook).

[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.

[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.

[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.

[ack]

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

[mmb]

CPAN is large and comprehensive but every time I've had to use it I've had to watch a minimum of 20 minutes of scrolling compilation, installing dependencies and running tests. Ruby and python install what I need in a few seconds so I can get back to work.

Maybe it's a question of perl putting a lot of things in CPAN versus other languages putting more in the standard library?

[draegtun]

CPAN is large and comprehensive but every time I've had to use it I've had to watch a minimum of 20 minutes of scrolling compilation

Have a look at cpanminus (http://search.cpan.org/dist/App-cpanminus/lib/App/cpanminus....). Its a lightweight and JFDI alternative to the default CPAN client.

Maybe it's a question of perl putting a lot of things in CPAN versus other languages putting more in the standard library?

Swings and roundabouts really because there is no definitive advantage in either approach.

Advantage in CPAN approach: Its more darwinian. Your libraries are more up-to-date (stdlibs often get stale)

Advantage in stdlib approach: Less dependencies. Batteries included out of the box.

After installing Perl first thing I do is load a few important CPAN modules (like Moose, AnyEvent, Coro, Devel::Repl, DBIx::Class) and then all your big loads are pretty much done.

[jsrn]

    > And here's some constructive criticism for the aspiring Perl advocate

point taken, thanks.

Perhaps the Perl success stories should be mentioned more often, too:

Want to launch a one-man search engine? Perl makes the easy things easy and the hard things possible: http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-arc...

Amazon.com, del.icio.us, Craigslist, the BBC? All have significant parts written in Perl: http://www.fischerlaender.net/perl/perl-used-for-web-develop...

http://perl.apache.org/outstanding/success_stories/bbc.html

[fendale]

For me, I use Ruby for everything I used to use Perl for, unless I can't get ruby on the system (still haven't managed a successful compile on HPUX!). The other use case is that Perl has a library Ruby does not, which still happens now and then.

[pwpwp]

emacs? Stop talking in acronyms and obscure names. Same for vim, frankly. Most people younger than me don't get it when you name-check vim. What does that stand for?

:P

[evilduck]

The differences I see here are that

a) emacs vs. vim has been a holy war that has gone on since both were conceived and is a debate which is often older than the programmers discussing it. To be ignorant of recent language developments or internal acronyms is excusable, to be ignorant of vim/emacs is less so.

b) emacs and vim are not specific to any one language. Dropping acronyms that are non-specific to the topic (perl vs ruby, python, whatever) doesn't have some domain specific knowledge attached to it. If you're on either side of the debate, vim can be equally familiar or obscure.

[pwpwp]

Terminology has context.

Complaining about an article on perl.org not mentioning what CPAN is, is like complaining about an article on cars.com not mentioning what BMW is.

[nuxi]

Regarding a) - that was emacs vs. vi, not vim. vim was first released in 1991.

[tsuraan]

CPAN (and the arguably failed attempts to copy it by other language communities)

I haven't used perl, but I do use ruby and I'm learning haskell. What does CPAN do that make rubygems and cabal failures? They both work really well from what I can see (especially cabal), but since I don't know perl, my POV is obviously limited. What am I missing out on?

[Ingaz]

Hackage, rubygems, PyPi - are all modeled after CPAN

[tsuraan]

Right, modeled after, but I'm wondering why they would be considered failures. Rubygems and cabal both work really well for me, and cabal is both the nicest package management system and the nicest build system I've ever used. I'd love to know why somebody would call it a failure.

[zaphar]

You obviously have never tried to compile profiling binaries for a haskell I would not call cabal the nicest build system I had used. Cpan beats the pants off it.

[jsrn]

with "failed attempts to copy" I meant they (Rubygems, Hackage, ...) did not succeed (yet?) to replicate the size, diversity, test coverage, community etc. of CPAN. I do agree that they are useful.

Sorry for the misunderstanding.

[wladimir]

Yes, that's clear. But what I don't understand is why the author thinks they have failed? I only have experience with PyPi, combined with easy_install it's an incredibly easy way to install packages and their dependencies.

[unoti]

Failed in the sense that they've failed to recapture the glory of cpan for solving problems from the late 80s and early 90s. Personally I've been very pleased with library support in Python.

Counting a library's worth by the number of things in it is probably not a good measure of its worth. But it'll be who knows how long before pypi or gems overtake cpan in terms of sheer quantity.

A better measure of worth would be a deathmatch showdown between seasoned perl people and seasoned ruby/python/whatever developers, where each can bring the powers of his libraries to bear.

But anyone who has had much exposure to perl people will tell you: never, ever underestimate them. They'll come at you with solutions to problems out of left field that solve the problem in 34 characters of self morphing regular expressions or something while everybody else is turning in comparatively huge 8 line readable programs.

[Mithaldu]

Or they come up with a 5 line solution, using a CPAN module that has had it's battery of unit tests automatically run through on 200+ different os/hardware/perl combinations, which also comes with its own little test suite and works out of the box; while everyone else runs their stuff and discovers they still need to catch a dozen weird edge cases.

Until other languages reach this kind of solidity and thoroughness in testing CPAN will stay at the top of the bunch.