A Foray into Perl 5 land

Usually I use Perl 6 as my programming language of choice. But about a week ago I started to plan and code an application for which the richness of the Perl 5 ecosystem outmatch the design weaknesses of Perl 5, compared to Perl 6.

I have quite a bit of Perl 5 experience too, but so far I mostly used it for smallish tasks, and didn't have too much use for many frameworks.

Here is a list of some tools I used, and my experience with them. I hope that my experiences can help the Perl 5 community to improve some edges here and there, and serve as an inspiration for Perl 6 modules authors what problems to approach.

cpanminus - painless module installation.

cpanminus gives easy access to the wealth of the CPAN. The module installation worked perfectly without any configuration or interaction.

Just when a XML parser had a dependency on an external C header file (expat.h), a module installation failed. Since Perl modules don't have a way to declare external dependencies, that's probably as good as a module installer can work. Kudos! The only improvement I can think of is directly showing the error message, instead of having it to dig up from a log file. I don't know if there's an easy way to automate that though.

DBIx::Class for the database

I store data in a postgresql database. From lowest to highest abstraction, the Perl modules involved are DBD::Pg (the database driver), DBI (the driver-independent database interface) and DBIx::Class, an object relational mapper.

Postgres itself is fantastic, and DBD::Pg and DBI look rock solid to me. I've worked with DBIx::Class before, and liked it. Upon rereading the documentation, I found that since my last usage the recommended usage pattern has changed. Writing result classes into the Result::MyClass namespace and result set into ResultSet::MyClass has made the result sets more accessible. Since they are a key feature of DBIx-Class, I welcome this change, and adopted it very naturally.

A small left-over from the previous scheme made the transition a tad harder than it had to, but upon reporting it on the #dbix-class IRC channel (on irc.perl.org), I immediately got commit access, and fixed it in the source.

Since I deal with trees, I was happy to discover a DBIx::Class plugin for nested sets. I was less happy to discover that it broke basic object creation, and had a bug that prevented merging of trees, a feature advertised in the documentation. Luckily both were very easy to patch, the patches now live in the bug tracker. I hope the maintainer applies them soon.

The nested set extension comes with a good test suite, but it seems it hasn't had much real world usage. I think that with some more usage (and maybe a few more bug fixes), it'll turn into a very good module.

Mojolicious for the web frontend

While waiting for the Catalyst dependencies to install, I decided on a whim to try out Mojolicious, a new-ish web framework. Or more precisely Mojolicious::Lite, a simplified API that lets you keep the whole application in a single file.

Now there were a lot of small, rough spots in Mojolicious. The community on IRC was very helpful, and asked me to record my findings on a wiki page - which I did.

What really bugs me about Mojolicious is that the built-in template system produces very incomprehensible error messages. It uses a mixture of verbatim text and perl code, separated by tags with various semantics (for example tags that just execute code, those that execute and insert the result, optionally with HTML/XML escaping).

Unfortunately that means that the code you write differs from the code that perl executes, which makes the error messages pretty useless.

My first suggestion to improve that situation is to display the generated code in the error message, in addition to the template code (and make the generated code as simple as possible.

If the generated code is non-trivial, it would help to add some markup to distinguish the user-written code from the code that the generator adds around it. I have no idea how easy or hard that would be to implement, though.

Conclusions

The Perl 5 modules were mostly very easy to use, and the corresponding communities very attentive and helpful.

If there's something the authors can learn from Perl 6, then it's a love for better error messages.

The Perl 6 world can aspire for such a rich and easy-to-use module system.