Of the “big three general purpose scripting languages”, Perl is improving most quickly, has the best libraries and the most jobs available. There is no compelling reason to switch to Python or Ruby and plenty of good reasons to stay with Perl.

At my job Perl is one of the sanctioned languages and it makes work fun. Over the past 18 months, improvements have been coming thick and fast (go go Moose and regular release cycles). For Windows development Strawberry Perl is getting better and better.

Outside of web development CPAN is better than the Python and Ruby equivalents and Python has inferior scoping anyway.

None of the minority languages mentioned in my previous post such as Clojure, Scheme and Haskell have gained any traction so there is no need to discuss them further here.

@Caleb – my understanding is that Clojure has “multi-processing” capabilities almost as good as Erlang but with better syntax and access to more libraries. In any case, both Clojure and Erlang suffer from the problem that they are not approved for use at work.

@andre – as chromatic points out, first of all number of modules is not a useful metric as one module can’t be compared to another. Secondly, the slashdot article uses the wrong number. It should be using 88,919 rather than 18,928.

88919 + 8x = 18894 + 27x

Solving for x gives 3685 days, or a little over 10 years. I think we’re good for now.

I’m happy there’s been a push to improve practices in Perl recently, but its growth is after what, by outward appearance, seems to be neglect.

And as I say that, I *know* a lot of folks have worked very hard to make Perl 5.10 great. But it really should have been 2004 – 2006 when Perl “got better.” Not 2009 and 2010.

I still use Perl at my day job, but my side-projects are all Ruby now. Why?

– While CPAN may have a larger number of modules than Ruby Gems, I feel I’m more likely to find code that’s been looked at and maintained more recently with Ruby
– Ruby’s community feels more vibrant. No, not something you can measure. It is a feeling.
– I like tools like irb, gems –server daemon, RSpec and others. Yes, there are equivalents in Perl, but they are far rougher. Again, not really measurable, but a feeling.
– The Ruby community seems to be where Perl is drawing a lot of ideas from lately. It’s great when language communities trade ideas. But it feels healthier when ideas flow in both directions. I don’t have that sense that Perl’s contributing. It’s catching up.
– While Moose is great, it’s bolt-on mental overhead that simply isn’t required with Ruby (or Python). The languages are OO from the ground up.

What about CPAN vs. Gems?
– The best metric isn’t number of Gems or CPAN modules. The best metric is “can I find a common solution to a problem I need to solve” I have yet to find a problem there isn’t a good or excellent solution to with a gem or other shared lib.
– “Outside of web development Python and Ruby have no answer to CPAN”
Incorrect. RubyGems.org is robust and while many things are web-related, there are many things that are not, or are not necessary (see Ruby’s standard lib). I can’t speak for Python.

If you’re happy with and enjoy Perl, by all means continue. But, speaking as someone who was a very dedicated Perl dev until 2007, there’s a lot else out there that’s worth a legitimate look.

@brad – from my superficial knowledge of Haskell, I agree – Haskell and Perl fit into different problem spaces. The issue for me is that Haskell isn’t an approved language at my firm, and most other firms as far as I know, which means I’m loathe to invest a lot of time in it.

@Nathan – apologies, I can’t figure out how to come up with a cohesive answer, so I’ll take them one at a time.

The irb Ruby REPL – I’m used to REPLs from my work with emacs lisp and it isn’t a deal breaker. If I needed one, what is wrong with Devel::REPL?

Idea’s flowing in both directions – didn’t most of Ruby come from Perl in the first place, with small-talk’s OO and blocks bolted on the top? I’m not sure how absorbing the best bits from a language and adding improvements a la Moose for example can be viewed as a bad thing.

RSpec – how is this better than the Test::* set of modules?

[Moose’s] bolt-on mental overhead – Does this mean I need to load a library? Surely there’s a whole bunch of stuff you need to load a library for in Ruby too. Not everything is in core right? And does Ruby have anything like Roles built in?

As chromatic is fond of pointing out, the OO model built-in to Perl 5 is identical to Python’s OO.

I note that you still do Perl at your current job. So is the problem that you can’t find a job doing Ruby, or is the job so good that it makes up for having to do Perl? Sorry for asking wifebeatery questions.

@Jared cool, I can’t really speak about erlang or closure at all, but the auto parallelization seems cool. I wish it was on the feature list of parrot/rakudo

@Nathan > Incorrect. RubyGems.org is robust and while many things are web-related, there are many things that are not, or are not necessary (see Ruby’s standard lib). I can’t speak for Python.

Wait are you saying that Ruby’s standard lib is a fine example of ruby-ware that’s not web related? or that it’s not necessary? I’m pretty sure that saying any languages standard lib is not necessary is wrong. I’m also pretty sure that saying it’s a good example of a languages non web related stuff…. is the same as saying a language doesn’t have non web related software/libraries.