Category — cpan

Recently I was reading an article from the good folks at Perl Training Australia about the 5.10 Smart Match functionality. I was particularly interested in the fact that they referred to the speed of the Smart Match being “extremely fast”, so I decided to hack together a quick script to see what potential speed gains we were looking at.

I focused my investigation on comparing two arrays and using Benchmark to see how much quicker using the Smart Match would be.

Number of items in arrays different (Smart Compare: 1 Second Foreach Loop: 1 Second)

When the number of items in the array is different the Smart Match and Foreach loop perform pretty much evenly across repeated tests.

All the tests were ran on Perl 5.10.0, installed from Source on a P4 with 2 Gig of ram. Whilst these findings show the smart match to be slower when comparing arrays, this is of course only a simple test case and other types of comparisons offered by the Smart Match should obviously be investigated too.

One of the fine gentlemen I work with recently blogged about how he started out with Perl and it got me thinking about why Perl currently seems to be failing to drive the interest it so rightfully deserves.

Perhaps by thinking about how developers select a language we are more likely to understand why Perl doesn’t get the numbers. I personally can’t even remember how I started out on Perl, it was that long ago. I suspect it was because PHP wasn’t even around, and it was the most obvious choice for a dynamic site, or more likely page at the time.

So what are we doing to attract new developers to the wondrous Perl? CPAN offers a great resource for developers who already work with Perl, but what is there for developers new to Perl? Or more importantly what is there to actually entice them to Perl. Every virtual corner you turn someone is mentioning PHP or Ruby on Rails, but Perl seems to be less “down with the kids”.

Let me be the first to admit, I certainly don’t have the answers, but perhaps by looking at how we got the Perl bug, we can come up with some ideas how to hook in more users.

Recently on the Catalyst mailing list was a thread about the press release detailing the latest 5.8 version and discussions turned to the “outlandish claims” that PHP and Ruby evangelists make. But I find my self wondering do we do enough to actually proclaim the things that Perl does well?

Now I realise I’m ranting, but it’s entirely possible that I’ll need to be looking for a new job in the near future and I’m not entirely convinced I’ll be able to get one working with Perl. I’d love to be able to blame this on someone, but to be honest it’s entirely our own fault. As Perl developers we simply aren’t doing enough!

Test::Aggregate is a simple, yet fantastic module that allows, you guessed it, tests to be aggregated. This turns out to be a true god send when testing large Catalyst apps.

Previously in order to run all the tests against an app I would generally have ran a stand alone server in one terminal, and then ran the tests against that stand alone instance in another, something along the lines of:

This will load all your tests, each into their own unique package space. Meaning that only a single Perl instance is required to run all the tests and that all the required modules will only be loaded once. Both the overhead in running the entire test suite and the execution time will be drastically reduced.

Problems can occur if you are using global variables, in that they may be overwitten by the tests as they run, but of course you aren’t using them anyway… are you?

Saw a message on the Catalyst mailing list about catalyzed.org, a new blog aimed at helping the public image of modern Perl. In their first post/article they happened to mention Matt’s Script Archive. So I thought I’d take a look at the old favorite.

Even back in it’s early days I thought the code that was on there was less clean than it could be, and not particuarly maintainable, but still thousands of users were running variants of the code. So why did Matt’s Archive dominate the Perl world so much? Simply because there was very little competition. Perl was one of very few mature scripting languages suitable for the job and Matt created a collection of tools all in one place that “did the job”.

So can we consider CPAN to be the modern day Matt’s Archive? It’s where we go for scripts, or more likely modules (to “do the job”). Thankfully CPAN is publicly maintained, and if you don’t like the way a module works you have a number of options from submitting a patch to creating your own version.

Whilst there are quite a few unmaintained modules on CPAN, there are a great number of current technical resources, developed in an extensible way that can be used for any number of tasks. It can certainly be said that most, every-day, functionality is exceptionally maintained. Often even older, unmaintained modules offer a starting point for development if you can’t find something current.