Let’s be honest. Perl 5, Python, Ruby, they’re almost the same. There are some differences, but when your compare them with C, Java, Haskell or some such they suddenly feel rather superficial. They suitable or unsuitable for pretty much the same tasks, occupying a niche that Perl pioneered: that of a high manipulexity and whipuptitude.

They each operate at the same abstraction level. Even if a language is lacking a feature that the others have, it’s easily implemented using other constructs. There are plenty of valid reasons to prefer one over the other (taste, library availability, programmer availability), but they all offer the same power. Perl 6 is going to change that.

Perl 6, like Perl 5, Ruby and Python steals a lot from other languages. As you may expect, it steals too many things to mention from Perl 5. It steals chained comparisons from Python, objects from Smalltalk (in particular Squeak’s traits should be mentioned). It thankfully steals nothing from PHP.

Hi Folks

At some time in the distant past, the CGI::Session distro contained the file CookBook.pm.

It still lives, in V 3.95!

CGI::Session is up to V 4.42.

Firstly how do I arrange for this file to be deleted?

Secondly, how many other derelict files await their obliteration, both in different versions of this distro and in other distros?

I already ran two quick polls about IDE usage in the Perl community.
Let me run a new one asking What is the primary operating system you use for developing Perl applications?. I'd appreciate if you invested 5 secs to answer it.

Just released the above two modules to support the ElasticSearch server version 0.6.0, which you can read about here: http://www.elasticsearch.com/blog/2010/04/09/0.6.0_released.html

New features include:

• support for the _all field, which allows you to search across all indexed fields
• fuzzy_like_this and more_like_this queries
• simpler range queries using Perl's gt, gte, lt and lte operators
• Index aliases
• attachment indexing
• search highlighting
• ... and more

The ElasticSearch API has gone through a big rename, moving from camelCase to the more Perlish underscore_style.

You can download them from CPAN (as soon as they arrive) or here:

• ElasticSearch: http://github.com/clintongormley/ElasticSearch.pm/downloads
• Alien::ElasticSearch: http://github.com/clintongormley/Alien-ElasticSearch/downloads

The Challenge

Last week on stackoverflow I came across an interesting challenge. Since my new module threads::lite seems to have stabilized enough for such a task I decided to to port the erlang submission to it (while using some helper routines from the perl submission). The porting was a fairly straightforward process that resulted in a pleasantly readable program (specially when compared to the other entry).

Then I ran it. It ran almost 6 times as slow as the other perl program!

Reason enough to profile it and see what was going on. Renodino's comment proved to be quite accurate: Storable and locking seemed to be the main culprits.

To tackle the first issue I added a simple but effective feature: if a message contains only simple elements (no references or undefined values), it is packed instead of frozen.

Yes.

the latest version of perl was released 4 days ago. It was interesting to see how it was reported on various channels.

Some were sort-of comparing it to Perl 6. Others wrote that it does not have major changes just a few bug fixes. Some wrote that The Perl Foundation announces it, others were stressing the release of ActivePerl 5.12 by ActiveState.

In any case I'd be interested to collect the news coverage about the release. So if you saw any other articles - either in English or in any other language - please post it on the wiki page of The Perl Foundation or just leave the links here as a comment and I'll copy them over to the wiki.

Since 5.12 got released a lot of bugfixes have been flowing into blead and one new feature. The prctl() support for $0 that I previously blogged about just got commited by Steffen Mueller.

With this patch you can finally killall programs you write in perl on Linux without killing all of your perl processes indiscriminately.

Last night I finished and released the first version of Dancer::Plugin::Database, a plugin for the Dancer web framework to provide easy database connections using the venerable DBI.

It takes the database connection details from the app config file, and provides a database keyword which will return you a connected database handle (taking care of ensuring that the DB connection is still alive, etc).

So, usage can be as simple as:

my $books = database->selectall_arrayref(
    'select * from books where author = ?', 
    { Slice => {}}, $author
);

(Calling database() simply returns a DBI database handle, so you can obviously do anything you can do with DBI).

Also, at the moment, if a database connection could not be established for any reason, database() will just return undef, so you will need to handle errors appropriately. After considering whether it's wise, I may tweak it to die, so that Dancer will handle the failure with a pretty 500 error for you (in which case, I'll make it possible to disable that via the config).

It's been pointed out to me that many programmers have issues with my blog because I'm writing about allomorphism, exceptions as flow control and other topics that are, frankly, not something a beginner programmer is going to warm to. I think that's a fair point and I'm going to try to start including information aimed at those new to Perl and those new to programming.

I'll start with subroutines. Specifically, an old, horrible example.

One of the first things a Perl programmer will notice when learning about Data::Dumper is: how weird and "inside out" the OO interface is. This is, I think, another unfortunate accident in the Perl history, as Data::Dumper, being the first of such modules, gets into the core in early Perl 5 and remains popular up until this day. But the interface and default settings apparently annoy a lot of people so much that alternatives and wrappers like Data::Dump, Data::Dumper::Again, Data::Dumper::Concise, among others, sprung up to life.

A loose analogy would be CVS which was popular for (too long) a time, and following it the explosion of alternative version control systems. Eventually after this phase a winner will emerge or dominate. In the version control system case it appears to be git. And in the Perl case I think it will be a builtin perl() method/function, like in Perl 6. Probably in 5.14? 5.16? 5.18? Don't you think it's about time Perl can "natively" dump its own structures in Perl, just like Python, Ruby, PHP, etc have been able to for a long time?

(Btw, lest anyone thinks otherwise: I do love DD. It has lots of options and has served its purpose well over the years.)

Dear lazyweb,

I am about to upload a new Alien:: distribution that downloads, builds, and installs a very, very large library. The installation of this Alien:: distribution occupies about 240MB on my laptop and compile times are huge even on my fast computer.

Is there a way to flag a distribution as unsuitable for CPAN testers? I'd rather not abuse the volunteer infrastructure by having them compile a library over night.

Over the weekend of the QA Hackathon, which by all accounts was another great success (and I think David, Ricardo aand I all wish we could have been there too), various work on CPAN Testers 2.0 was underway. With the submission to the Metabase and the feed from the Metabase into the cpanstats database being two very distinct parts of the eco-system, it has made work on both parts a lot easier as it only requires one interface between them. While much of the interface has been evolving, it has for the most part been fairly straightforward. However, unfortunately while testing the interface, I noticed that several reports had been posted with no text report. Seeing as this is the part that authors really need to see, it means that we now have to discard those reports. In addition, David also found a problem with how S3 names objects, which was causing a problem for storing facts within the Metabase.

I recently blogged about extending the Perl debugger. Basically, if you use xx $some_var, you get love Data::Dumper output instead of the confusing debugger output:

The dichotomy of List::Util and List::MoreUtils is one of the unfortunate annoyances in Perl. One is without s, one is with s. Which function belongs to which? And no, you can't simply say, "f*ck it, just import everything!" as List::Util doesn't provide the usual ":all" import tag (RT).

Some thoughts (from someone who is largely ignorant on the history of both modules), all IMO:

1. Since List::Util is basically a convenient library, convenience should've been its main design goal. It should've been inclusive enough. The decision to deny the inclusion of any(), all(), none() just because they are too "trivial" to implement in one line of Perl was a bit strange, since max(), min(), etc are also trivial to implement in Perl.

2. List::MoreUtils should've included all the functionalities of List::Util, so one can use it *instead of* List::Util.

But hey, what happened happened.

Btw, we also have Perl 6's junction taking the "all", "any", "none" keyword.

OH YEAH!

Just finished installing the brand spanking new Perl 5.12 on the netbook on my "perl" account, with which I tested already earlier -RC releases with my personal code.

It's fair to say that the user experience has gone a long way from the "old days" of manual configuration, installation, swearing and $ENV madness. Hell, one doesn't even need local::lib anymore!

All I had to do to test 5.12 after creating my "perl" account was:

Perl 5 core development was in a downward spiral for a couple of years. Releases happened less and less frequently, the number of contributors dropped and the general outlook was getting worse and worse. For the Perl 5.12 release I wrote a post on the ActiveState blog how the downward trend has been reversed and how fun, optimism and even excitement has returned to Perl 5 language development.

Perl is far from dead/dying nowadays, with 5.12 being released recently, and the yearly timed-based release plan and all. In fact, just after I start to be comfortable using some of the 5.10 niceties, here comes a whole new version with even more niceties waiting to be explored!

Features in 5.10 I'm using regularly.

Defined-or (if there's only one feature I can have in 5.10, I pick this one).

State variables (love it!).

Features in 5.10 I'm starting to use.

-E switch (but my reflex still says -e all the time).

Recursive pattern in regex (e.g., via Regexp::Grammars).

say() (maybe if I say it often enough I'll start to say say more).

Features in 5.10 I rarely/ever touch.

Smart match (I know it's a godsend, but strangely I never feel the need for it so far).

given/when (I'm sticking with if/elsif/else, especially since given/when cannot be used as an expression yet).

There are some tests which pass, but routinely fail in the debugger. Here's one example: