
Why I Use Perl: Reliability - ZeroMinx
http://www.modernperlbooks.com/mt/2012/05/why-i-use-perl-reliability.html
======
staunch
Any language would be improved if it had Perl's testing and library culture.
Two things it's absolute unsurpassed at so far.

~~~
Goladus
I once had a large CPAN dependency install fail because one of the modules'
tests included an http request to a 3rd party website which happened to be
down that day. I wanted to strangle that developer when I finally tracked down
the error (it wasn't failing with an obvious error that would let me easily
recognize what was happening, I had to read the code itself). That is going a
bit _too_ far with the testing, I think.

And though I admit the culture is great overall, that does seem to be my
experience with CPAN. You never know what you're going to get. It's like that
to some degree with every language but with CPAN there's so much trust in the
system it can be harder to identify and filter out the lesser quality stuff.

~~~
cytzol
IIRC, the correct protocol with network testing is to prompt the user first
that it's going to connect to another host, so they can skip the tests if
there's something wrong with their network (or the site on the other end).

The other way to do it is to start an HTTP server locally and use that (which
is what WWW::Mechanize does)

~~~
jleader
Prompting the user seems like a bad thing for an automated test to do!

The whole point of automating tests is so you can run them unattended: at
install time, or under a continuous integration system after code check-ins,
or for git pickaxe to find which change caused a bug, or whenever else you
want to confirm that a whole lot of code still works as intended.

------
rcthompson
For any value of $LANGUAGE, imagine this situation: your boss comes to you and
say "Hey, they just released a new major version of $LANGUAGE today. Can you
go upgrade it on all our production servers?" What is your emotional response
to that request? For many values of $LANGUAGE, there would probably at least
some element of terror (for many languages, probably much more than just
"some"). But Perl is one where, depending on the circumstances, the response
could plausibly be as article says: boredom. "Yeah, sure, whatever. I'll go
upgrade them." (Certainly there are others, but Perl is definitely one of the
best in this regard.)

~~~
Goladus
> What is your emotional response to that request?

Heh the worst upgrade experience I've had with any language was with perl. The
issue wasn't with changes to language features, it was chaos resulting from
CPAN XS module compatibility and compilation failures. I remember one trivial
module (array::compare) went from a having few core dependencies to dozens of
CPAN dependencies (including all the moose OO modules). And that was just one
module, there was a list of others that had issues.

To be fair, that was a Solaris environment and was the only time I had issues
that serious. But I'd argue documentation of dependencies is a much bigger
factor no matter what the language.

~~~
zby
I think it has improved much after 5.10, of course most companies are not yet
there - so what chromatic describes is far from being a standard experience.

~~~
Goladus
Interesting, the upgrade I mentioned was 5.8 to 5.10.

------
pauljonas
7-10 years ago, Perl was my daily bread and butter. It was the language I used
the most, and not only did it supplant a lot of C code, but was the optimal
scripting solution.

Now, for me, Ruby has supplanted Perl in nearly every conceivable way -- OO
Perl was always painful, and I do not miss ever having to bless a refrent
again…

~~~
ZeroMinx
I do Perl on a daily basis, and I can't remember when I last blessed a ref.

use Moose;

~~~
irahul
Do you use Moose, or MooseX::Declare? Moose has a startup penalty, but when I
am willing to accept that, I would rather use declare extensions as well.

~~~
iloveponies
If the startup penalty is such a concern, There is Moo. And Mo. And M. Or
failing that tools like Class::Accessor.

------
jwr
I was about to note that the OP clearly hasn't used Clojure if he uses it as a
negative example in terms of reliability, but then I remembered — I promised
myself not to get too deeply into these kinds of silly discussions.

So, dear OP, good luck writing your large-scale multithreaded high-performance
distributed applications using Perl.

And BTW, I do use Perl quite a bit and I really like it, for certain tasks.
But I'd never make these kinds of comparisons.

~~~
adrianhoward
_I was about to note that the OP clearly hasn't used Clojure if he uses it as
a negative example in terms of reliability, but then I remembered — I promised
myself not to get too deeply into these kinds of silly discussions._

Erm... He didn't? He said:

"While so much of the shiny-chasing buzz in the micro-ISV startup built-it-
and-they-will-fund world seems to chase Clojure and Node.js and app-in-a-page
tricks, Perl 5 continues to be my workhorse."

No comment on the reliability (or otherwise) of Clojure.

And much as I love Clojure - there's an element of truth there. Lots of folk
using it because it's the new-and-shiny rather than it being necessarily the
best solution. I know I've binned some Clojure stuff that would have been fun
for me - because adding the JVM to the mix in production wouldn't have helped
us actually get stuff done.

(and while it's an unfair comparison - since it's a vastly younger language -
the transition to 1.3 wasn't fun for many folk :-)

~~~
jshen
"Lots of folk using it because it's the new-and-shiny rather than it being
necessarily the best solution"

How do you know what is in people's head? I assert that lots of folk are using
perl because it's comfortable to them rather than it being the best solution.

~~~
kamaal
The difference between computer science and software engineering is Software
engineering is real work for the real world. Often the constraints are money,
time, resources.

So demands of a software project in the real world are very different than the
academia. Although you can argue that Lisp is far more a better language than
Perl, based on some parameters you wish to evaluate. Others might have totally
different parameters, for example in terms of mere usability and pace of
getting things done, Perl will fare better than Lisp.

While evaluating two technologies it is really important to define the
parameters you wish to evaluate them upon. Without that we are just comparing
Apples and Oranges and then arguing that nutrition on one isn't better than
the other. Unless we define who needs an Apple and who needs an Orange for
what reasons, we won't be able to say which is better than what for what
purposes.

There fore comfort is really a subjective term. For a professor sitting in a
university with endless time at his disposal Lisp will make the perfect and
most comfortable language. But me sitting on P1 ticket assigned to me, and
given 45 minutes to provide with solution has no other option but to use Perl.
In other news I just have a weekend to hack up a automation or produce a quick
prototype. You know what language I'm going to use, Its Perl.

Not because I hate Lisp or I'm uncomfortable. Its just there is no other
option.

~~~
hkolek
You said it yourself, comfort is a subjective term. So why do you talk as if
Lisp were objectively more complicated. If I'm familiar with Lisp but have no
clue about Perl I don't need to be a university professor with endless time to
choose Lisp over Perl every time. To me, Perl looks vastly more complicated
than Lisp. I believe you'd find that if you'd know Lisp like you do Perl you'd
be _at least_ as productive as you're in Perl.

~~~
adrianhoward
_To me, Perl looks vastly more complicated than Lisp. I believe you'd find
that if you'd know Lisp like you do Perl you'd be at least as productive as
you're in Perl._

As somebody who loves both Lisp and Perl I'd probably say you'd be as
productive (unless you were sitting in a domain that one language or the other
was a better fit for). Well - apart from CPAN and the testing infrastructure.
And the editor/IDE support is worse unless you're already an emacs person...
but those are just coz Clojure is young.

I'm thoroughly sick of the Lisp == academic == hard myth. It's just nonsense.
I've taught newbie devs Lisp and Perl in the past and both groups seem to take
it on at about the same pace.

------
f055
Perl is like C++ for the Web. Bulletproof. Unless you intentionally remove the
kevlar plates. But then it's on you ;)

~~~
ma2rten
I heard some else say Perl is COBOL of the web. (COBOL is also used by banks
for it's reliability)

~~~
pwaring
Is COBOL still used by banks? The people I know who work in two different
major UK banks suggest everything is Java now, with Oracle as the preferred
database solution.

~~~
adrianhoward
_Is COBOL still used by banks?_

Short answer: Yes :-)

Still the backbone of many banks, building societies, credit card companies,
etc. See <http://www.careerjet.co.uk/cobol-jobs.html> for some of job adverts.
This old 2009 article [http://www.guardian.co.uk/technology/2009/apr/09/cobol-
inter...](http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-
programming) is still pretty much true AFAIK.

~~~
pwaring
Thanks for the links - looks like the COBOL jobs are not promoted as much (I
couldn't find any on the four bank sites I looked at) but still there, and
reasonably well paid too.

~~~
pauljonas
Most of those COBOL jobs were offshored or are now performed by Indian/Asian
vendor non-immigrant visa holders imported.

Within hour drive from my house, I can tally at least a half-dozen corporate
IT shops that outsourced heavily in this way, axing thousands (in aggregate)
of jobs that normally were served by internal/domestic consulting houses.

Yes, on the backend there is still a lot of COBOL, even if it is running on
micro-hardware as opposed to the old big iron. Claims adjudication, utility
metering, charge card processing, billing for just about any corporation that
existed pre-1980, etc.…

------
michaelpinto
Yes Perl is a great language -- stability, maturity, etc. But does anybody
realize just how hard it is to find decent Perl programmers? It's not a large
community to begin with and the pool of decent programmers is even smaller.

~~~
jerf
Unless you're completely impatient, you can pretty much take anybody with a
"scripting" language background and throw them in and it's fine. Works the
other way around, too. Python, Ruby, and Perl are all nearly the same language
under the hood, with Javascript and Lua somewhat more distant but still not
_all_ that different. (Also, I mean someone who _knows Javascript_ , not
merely someone who can copy and paste some snippets of jQuery.)

Yeah, they may not know the exact APIs you're using, but that's usually the
case anyhow.

What doesn't work so well, or at least takes a lot longer, is to take somebody
with only Java, C/C++, or other such languages, and throw them in.

~~~
michaelpinto
My old CTO would have argued with you that Perl was not a mere scripting
language* and that our shop's style of coding was indeed object oriented. The
other problem we ran into was that the programmers who loved other languages
were very religious about it.

In fact I use to visualize that each programmer worshipped the specific animal
that shown on the O'Reilly book cover: And I'm still haunted in my dreams by
that camel. Of course the best programmers in my experience like to work in
multiple languages -- but again there aren't that many of them...

* This was a few years ago so this was a reference to PHP and Cold Fusion which tended to get mashed into HTML. Python was around then, but a very new thing -- and this was before the age of Ruby on Rails.

~~~
jerf
"that our shop's style of coding was indeed object oriented"

All of the other languages I mentioned are roughly as OO as Perl. (You
sometimes have to go looking for it, and Perl's probably ultimately the
weakest at the core, but it's still there and mostly strong enough it doesn't
matter.)

~~~
michaelpinto
Well keep in mind that the above quote was made about twelve years ago. The
problem that we had was that the people who would take up languages like PHP
were what we'd call "script kiddies" who would copy and paste code and call
themselves coders. Keep in mind that this was right before the bubble burst so
there was a ton of BS going around too. Of course since that era I've seen
programming languages mature -- and I've also seen the industry mature as
well. Although i still see a great deal of BS... : D

------
grout
The readability arguments need to include such modules as
Method::Signatures::Simple, which replaces the old manual method (no pun
intended) with:

    
    
       method foo ($a, $b) {
          $self->blargh($a + $b);
       }

~~~
jrockway
Is "my ($self, $a, $b) = @_" really that hard to read? It's slightly more
characters but I've never found it particularly annoying.

~~~
gdog
The problem is in practice @_ is abused like crazy. For example:

1) I've often seen people shift from @_ half way in the middle of a function.
If you _really_ want to be certain about a method's formal parameters you have
to read the entire function.

2) Also @_ is used in other circumstances which can cause mass confusion. For
example Try::Tiny uses @_. It is difficult to guess if you getting a formal
parameter or something else entirely (I"m not a fan of magic variables in case
you can't tell). If you're Chromatic you might be able to know the probably
hundred of uses of @_, but for a normal programmer you're screwed.

3) What if you want to use named parameters? You essentially have make a
pointer to a hash, populate it, and unreference it. my $p = {'name' => 'val1',
'name2' => 'val2' }; f($p); sub f { my $name = $_[0]->{'name'}; my $name2 =
$_[1]->{'name2'}; }

In other languages like python you can just do something like: def f(name,
name2): ...

f(name = 'val', name2 = 'val2')

I've never seen a language handle function parameters as poorly as Perl. I
forget almost all the Ruby I once knew but I'm pretty sure it is handled in a
reasonable way similar to Python.

~~~
rcfox
1) Adopt a convention of extracting your arguments at the beginning of the
function.

Also, sometimes you just want to work on an arbitrary list of items. If you
process one item and then shift it, that's a reasonable thing to do.

2\. If you adopted the convention in 1, this shouldn't bite you. (I've never
actually encountered this issue myself...)

3\. You are misinformed. You can easily do something along the lines of:

    
    
        f({a => 'foo', b => 'bar'});
        
        sub f{ my ($args) = @_; say $args->{a}; }
    

There's probably a module of CPAN to do this even nicer.

~~~
einhverfr
Agreed. There is plenty of awful perl code out there. I have worked on
codebases that did things like:

some_func(\%$some_object, \%some_hash);

and used variables like $a and $b as mainline code parameters...

However, if having dangerous features were something to hold against a
language in general, nobody would be using C (maybe Linux in such an alternate
universe would be written in Fortran or some other abomination). On the whole,
I think that well-written Perl is very good. Poorly written Perl is... well,
poorly written.

------
c250d07
Good article with some good points. But it did get me thinking, is Perl
getting ready to be in a prime position to become the next Cobol? Probability
will go up considerably if Perl 6 never comes out to shake up the ecosystem,
but even if it does come, what's to say that there won't be Perl 5
applications running into the next century?

Combine its shorthand and with the fact that it's already getting hard to find
Perl people, and we could see some dedicated Perl warriors doing very, very
well in the coming years.

~~~
adrianhoward
To some extent it's already true. There's a _lot_ of Perl in the financial
sector. That community is paying a lot more than the average for Perl dev's
already :-)

~~~
gouranga
We in the finance sector killed it years ago. We're now trying to kill java
and move to python.

~~~
adrianhoward
Well - since you've still not managed to kill COBOL I'd bet on there still
being a lot of Perl in ten years time :-)

~~~
gouranga
We killed that as well!

~~~
adrianhoward
Considering the number of folk dealing with COBOL systems I bumped into at
GOTO Copenhagen last week, and the number of COBOL jobs that pop up after a
quick google I would beg to differ.

I can, of course, understand why you would really want it to be dead ;-)

~~~
gouranga
I'm quite surprised actually! I've not seen COBOL in the finance sector (at
least in the UK) for about 5-6 years.

Perhaps there still are a few corners where there are some rotting corpses
hacking away on AS/400s which are actually gluing everything together!

I remember getting to sledgehammer the crap out of our AS/400 platforms and
incinerate two entire pallets of IBM manuals - was "a great day for freedom"
to paraphrase Pink Floyd.

------
tlianza
The article makes a good point. But, the title (and comments here) infer that
there are a mountain of reasons why people don't use it. Is there a compelling
argument against that mountain, or is this just a reminder that
Ruby/Python/Closure/Scala communities would be well-served to try and improve
in this area?

~~~
fennecfoxen
The worst problem with Perl as a language is hiring for a good Perl
programmer. It's easy to hire a mediocre Perl programmer, mind you, sometimes
even a mediocre programmer who's really good at Perl specifically and knows
all the packaging tricks and whatnot so he can get through the interview
before falling apart on the job, but really hard to find the good ones. It
just doesn't have much mindshare at the moment (ugh, I used the word
"mindshare", but it's true).

My last job was programming a snazzy Perl system. My current job is at a
startup that my last boss helped found. He chose Ruby because he was tired of
trying to hire for Perl programmers. After being involved with the hiring
process over there as well, I'm inclined to sympathize. Honestly, we ended up
just mostly advertising for programmers with experience in Ruby/Python/etc who
would be willing to do Perl.

That's the only insurmountable-mountain I know of.

(Postscript. If you're the rare actual-really-good Perl programmer looking for
a job, I am aware of two places willing to hire you, one in Sunnyvale and one
in NYC. PPS. Sorry, probably no telecommute. But I don't work there these days
so I'm not sure.)

~~~
ralphgoodtimes
I'm interested. I love Perl, and would love to work for a company that
requires me to program in Perl. Care to share which companies are these?

Thanks.

~~~
jleader
If you're in Los Angeles, check out <http://perl.la/>. I know my employer
(oversee.net) is hiring, and I'm pretty sure many of the others on there are
as well.

~~~
wiredd
ZipRecruiter is also hiring perl programmers in Los Angeles (email in profile
if anyone's interested).

------
knighthacker
Reliability, community, and CPAN are some of the main reasons we use Perl at
Crowdtilt! Good article.

------
jhuni
A quick note on sigils: recently I have been thinking that the dollar sign
sigil could be used to denote place forms such that $_ is the top place form.
Any place form could be cast into a function to be used on any object, for
example you could use the place form $first on a collection like &$first(coll)
and you could always set the value of a place with something like setf($first,
1).

Inside any function $_ will refer to the argument of the function, so you
could program without ever using named parameters like in Perl 5. A parameters
list like ($x,$y,$z) will just create new place forms rather then variables. I
think this would make for a pretty interesting programming language semantics.
On the other hand, I don't see much use for the @ and % sigils because I just
consider lists to be structures with numeric places and maps to be structures
with general places, so I actually prefer PHP style sigils.

------
ma2rten
I remain unconvinced. Should the amount of effort that it costs to update the
interpreter really be the main consideration?

~~~
peterwwillis
Not at all. You shouldn't be updating the interpreter unless you _have_ to,
and then it should be done through your distro's package management and
standard upstream path.

The OP seems to think it's a good idea to upgrade his production code to the
newest stable interpreter just because it was released. This is a recipe for
disaster. Sometimes there are just hidden bugs you don't see until a weird use
case blows up your code, and thorough stress testing should be performed
_after_ the unit testing to ensure no major surprises after upgrade.

The best rule for keeping your software stable is: don't change anything.

~~~
jleader
Your rule ("don't change anything") is also an argument for never adding
features!

There's a tradeoff here that you're glossing over. Given that each newer
version is presumably some amount better than the previous one, eventually the
benefits of upgrading will outweigh the costs, at least if you're going to
continue making changes to your software.

I don't think chromatic was saying "everyone should immediately upgrade to the
latest version of Perl". I think he was saying "upgrading to the latest
version of Perl isn't as scary/costly as some people think; I did it, and
here's my experience."

Also, keep in mind that sometimes there are hidden bugs in the old version,
too. My employer just ran into a problem with the de-allocation of deeply
nested structures being implemented inefficiently in Perl 5.8 (which has been
in production for close to a decade); the bug was fixed in 5.14.

------
madhadron
Unleash the smug Lisp weenies! After all, Perl's stability is minimal compared
with Common Lisp's.

~~~
jrockway
Ah yes, SBCL, the runtime that manages memory with a signal handler on SEGV.
Stable!

~~~
housel
That's a feature, not a bug. Write-protecting memory areas using mprotect()
and the like, and handling the resulting SIGSEGV, is a popular technique for
implementing a write barrier needed for generational garbage collection.

~~~
chromatic
I've seen it used before to good effect, but one concern is that it's really
easy to write flaky and unsafe signal handlers. Getting that right has never
seemed easy to me.

~~~
jasomill
It's very easy to write flaky and unsafe memory management code in general,
yet memory management is used with good results in nearly every production
system. And there's nothing wrong with using "tricky" OS and hardware services
to implement language runtimes and core libraries --- that's what they're
there for.

------
danpalmer
Language keywords:

Ruby ~40 Python ~40 Java ~50 Perl ~1800

Perl can have all the community support, packages, and testing that it wants,
but I dislike programming in it and find it difficult to code in. This is not
because I have only ever done Ruby or Javascript, I would consider my
strongest languages to be Objective-C and Java, I have used C quite a lot, I
know what I am doing with programming languages. I just dislike Perl.

Did you know there is a Perl package that will catch references to undefined
symbols and fuzzy match them to the closest it can find in the current scope.
To me, that seems to be the marker for the general quality of the code.

~~~
bloblaw
This sounds wrong...so I thought I'd see what Notepad++ has built into its
syntax highlighting lexer (langs.model.xml):

    
    
      * ~ 35, Python
      * ~ 53, Java
      * ~ 59, Ruby
      * ~189, Bash 
      * ~253, Perl   <===== 
      * ~928, PHP
    

Perl has a higher keyword count than Ruby or Python, but remember Perl's
keyword list includes its core socket/network library (which Ruby/Python/Java
don't contain in theirs...according to Notepad++).

~~~
fffggg
Core network as well as many POSIX functions which other languages place in
sub-modules (but still use the same names for). eg select() vs IO.select or
mkdir() vs FileUtils.mkdir.

OP is clearly thinking of PHP.

------
TheRevoltingX
I've used Ruby, Java, and Perl professionally and my favorite by FAR is Perl.

~~~
gouranga
have you tried Python? I find it far more "normalised" than Ruby, Perl or
Java.

~~~
TheRevoltingX
Not yet, right now I have no need to learn yet another scripting language.
I've been spending most of my language learning efforts on Erlang lately.

------
nthitz
Reliability? Sure. Readability? Not so much.

~~~
jbert
Would you like to post a representative snippet in your favourite lang? I'll
try and rewrite in perl and we can compare. (All langs have particular sweet
spots, if you do an R or APL oneliner or something it's going to be much more
verbose in perl, obviously)

It's not that I think perl will be significantly (or at all) nicer, but I
think the readability difference is often overstated and I'd like to test that
thought.

~~~
afc
Lets see, what about factorial in constant memory? Exponentiation (a to the
power of b, where they are positive integers) in logarithmic time (not using
built-in exponentiation functions/syntax)? Anonymously add a constant to a
number and return it (in a way that can be passed to a function like 'map' or
some such)?

    
    
      def Factorial(x):
        output = 1
        for i in xrange(x):
          output *= (i + 1)
        return output
    
      def Factorial2(x):
        return reduce(operator.mul, xrange(1, x + 1), 1)
    

I provided two versions, both with constant memory, to show how it'd look with
explicit iteration and without it.

With this, I get:

    
    
      >>> Factorial(200)
       788657867364790503552363213932185062295135977687173263294742533244359449963403342920304284011984623904177212138919638830257642790242637105061926624952829931113462857270763317237396988943922445621451664240254033291864131227428294853277524242407573903240321257405579568660226031904170324062351700858796178922222789623703897374720000000000000000000000000000000000000000000000000L
    

Exponentiation:

    
    
      def Power(a, b):
        if not b:
          return 1
        if b % 2:
          return Power(a, b - 1) * a
        x = Power(a, b/2)
        return x * x
    

Add a constant:

    
    
      lambda x: x + 7
    

Or, if you want to name it globally:

    
    
      def TweakValue(x):
        return x + 7
    

How do they look in Perl?

~~~
jbert
Thanks for that.

First one (not 100% sure it's constant memory, I _think_ perl optimises the
for to avoid instantiating the (1..$n) list:

    
    
        #!/usr/bin/perl
        use Modern::Perl;
        use bigint;
    
        say fact(5000);
    
        sub fact {
            my ($n) = @_;
    
            my $output = 1;
            for my $i (1..$n) {
                $output *= $i;
            }
            return $output;
        }
    

(Took the value up to 5000 to get something which ran long enough to get a
measurement, on my laptop it runs (including startup time) in ~1.2s. (Can we
compare runtime too? I know we're discussing readability, but I'm interested).

The reduce version (again, I'm unsure of const mem req). Comes in at ~1.4s:

    
    
        #!/usr/bin/perl
        use Modern::Perl;
        use List::Util qw(reduce);
        use bigint;
    
        say fact(5000);
    
        sub fact {
            my ($n) = @_;
    
            return reduce(sub { $a * $b; }, 1, (1..$n));
        }
    
        

The add a constant (true lambda, closing over lexicals in scope, etc etc) is
'sub':

    
    
        sub { my ($x) = @_; $x + 7; }
    

(doesn't have the python lambda limitations). (Be aware that perl GC is
refcounted though, so ref cycles are possible).

Edit: I think the languages are comparable in terms of features and also
readability. People may dislike leading sigils and that's fair, but I dislike
python's "no need to declare your vars, just hope you don't typo an
assignment" approach to lexicals.

~~~
zem
that also highlights one of my perl peeves - having to scrape function args
out of @_ rather than declaring them as part of the function definition.

~~~
jbert
Yes, that sucks. It's not much extra typing:

def function(x, y, z):

versus

sub function { my ($x, $y, $x) = @_; }

The overhead is only really the 'my = @_;' chars, but it is annoying. On the
other hand, it does allow you to do things like partially unpack args and pass
the rest as a bundle to a super class.

~~~
pyre
You can partially unpack in Python too:

    
    
      def method(self, *args):
        a, b = args[:2]
        super(self).method(*args[:2])
    

Perl's lack of using the definition for the variables doesn't necessarily make
it 'more powerful.'

~~~
chromatic
Python's approach is very reasonable. Both Perl and Python are nicer than C
varargs.

------
nyddle
Speaking of Moose, dependencies and reliability: I love Perl but today having
to download the whole CPAN to use a MongoDB driver (based on Moose) forced me
to switch to pure javascript with mongo js interpreter.

~~~
draegtun
You don't need to download the whole of CPAN to install Moose:
[http://deps.cpantesters.org/?module=Moose&perl=5.16.0...](http://deps.cpantesters.org/?module=Moose&perl=5.16.0&os=any+OS)

MongoDB (if that's what you are using?) has a few more dependancies however it
actually uses _Any::Moose_ and so could you _Mouse_ instead of Moose:
[http://deps.cpantesters.org/?module=MongoDB&perl=5.16.0&...](http://deps.cpantesters.org/?module=MongoDB&perl=5.16.0&os=any+OS)

Were you using cpanminus to install your modules? Because its much faster than
default _cpan_ command.

I just tested using cpanminus (cpanm) on a vanilla perl install and installing
Moose & MongoDB modules took 4 minutes here.

Here's a summary:

    
    
      Install perl-5.16.0 via perlbrew - under 15 mins
      Install cpanminus - 5 secs 
      cpanm Moose       - 2 mins 5 secs (installed 22 distros)
      cpanm MongoDB     - 1 min 52 secs (installed another 20 distros)
    

Here's the log: <https://gist.github.com/2836306>

