Unicode and Perl

Over the last couple of days I’ve been involved in a couple of discussions where it is clear that other people don’t understand how Perl deals with Unicode. The documentation is clear and detailed (there’s even a good tutorial) but for some reason people still persist in misunderstanding it.

Here’s a quick quiz. Can you explain (in detail) what is going on with all of these four command-line programs? And for bonus points, which one should we be emulating in our code?

$ perl -E'say "£"'
$ perl -Mutf8 -E'say "£"'
$ perl -C -E'say "£"'
$ perl -C -Mutf8 -E'say "£"'

In all cases, assume that my locale is set to en_US.UTF-8.

I’ll post explanations in a few days time.

Update: Coincidentally, Miyagawa posted something very similar on his blog.

A WordPress Critter

Perl News - Powered by WordPress
Perl News – Powered by WordPress

If you were at YAPC::Europe this week you might well have seen Richard Jelinek’s talk about how to increase Perl’s popularity (update: the slides are here). As part of that talk he suggested that the Perl community needed to run more of its infrastructure using Perl and (amongst other examples) he mentioned a discussion he had with an unnamed Perl News administrator about why Perl News is run using WordPress (which is written in PHP).

I’m happy to admit that I’m the unnamed Perl News administrator. But I think that Richard’s report of our conversation omits a lot of the detail in the points I tried to make to him. So I’d like to take the time to clarify my thoughts on this. There are three points in particular that I’d like to make.

1/ Multitasking

I have a lot of projects on the go. I should probably cut back a bit. Yes, I could start a project to create a WordPress clone in Perl, but that would mean that I would need to shelve a few other projects for some considerable time. The alternative is to quickly build Perl News using an existing tool. You know which option I chose. Of course, you’re free to disagree with me.

2/ Network Effects

Even if there was a capable WordPress replacement written in Perl I probably wouldn’t use it. You see, WordPress isn’t just the software. There’s also a huge community behind it. And that means that there are a huge number of themes and plugins available – with more being released all the time. Every time I want to add a feature to WordPress site, I just find the appropriate plugin and install it. Without that huge community, I would have to implement lots of stuff myself. Which would mean that either I’d be working on Perl News full-time or Perl News would be missing lots of features (for example the social networking hooks).

Don’t forget that I’m also involved in running blogs.perl.org. That runs on Movable Type (which is written in Perl). And have you seen the list of issues that we have with that site?

3/ Patches Welcome

Leo and I built Perl News because we thought it was a useful site for the Perl community to have. You can probably tell from the frequency of updates on the site that it’s not exactly a top priority for either of us. Personally, I’d be very happy if someone else took responsibility for it. So if you think that you can do better, or if you have a Perl system that you think could be used in place of WordPress without any removal of functionality, them please let us know. I’d be really happy to give you a dump of our database (so that you have all the existing stories) and update the DNS to point the domain at your server.

If it matters to you to have Perl web sites running on Perl code, then just go ahead and do it. I would be happy to see it happen. I just don’t have the time to do it myself.

YAPC Europe Approaches

This time next week YAPC Europe will have started and many of us will be enjoying ourselves in Kiev. The organisers published the schedule over the weekend and it looks like it’s going to be a great conference.

I spent some time trying to work out which talks I want to see and I’ve written some suggestions in an article over at Josetteorama. Let me know if I’ve missed something that you’re planning to see.

Just Build Something

The Political Web

About a month ago, JT Smith suggested that we should all stop talking about Perl and just build something. And, purely coincidentally, over the last few weeks I resurrected a project that I have been poking at for about five years and have finally turned it into something that I’m happy to show the world.

The Political Web is a site which aggregates all of the information I can find on the web about individual British MPs. I say “all of the information”, but that’s obviously a bit of a work in progress. But I think that what I already have is useful and interesting – well, for people who are interested in British politics. I have plans to bring in more information in the future.

Although I’ve been working on the site for five years, I pretty much rebuilt it from scratch when I recently returned to it. Actually getting something useful up and running took about four hours. That’s because I was building it using Perl and, more specifically, Dancer.

Pebble and Perl

I’ve been wearing a Pebble watch for a couple of months now. I really like it but, to be honest, it’s the potential that has me most excited. The number of apps currently available is a bit disappointing and the API is taking its time appearing.

But even when the API is published, I wonder if I’ll have the time to learn all the necessary technologies in order to write Pebble-aware apps. All I want is to have some way to send a notification that pops up on the phone. Surely there must be an easy way to achieve that. Preferably one that I can use from Perl.

Of course, it turns out that there is. The secret is an app called Pushover. Pushover is a web service that sends notifications to your Android (or iOS if you’re that way inclined) device. There’s an app that you install on your device (it’s not free – I think it cost me £3.30) and you need to sign up for a free account. Then you can send notifications to your device either from their web site or using their API. The API is a simple HTTP request-based system. There’s an example on the Pushover web site that uses LWP::UserAgent, but you can make it even simpler using WebService::Pushover.

That’s all well and good. We can now send arbitrary notification from to our phone. How do we get from there to the watch?

The standard Pebble Android app is currently a little disappointing. In particular, it only supports pushing notifications from a tiny number of apps from the phone to the watch. But there’s another alternative. There’s an app called Pebble Notifier which will forward notifications from any app on the phone to the watch. When you install Pebble Notifier you can choose which apps you want to forward notifications for.

So, in summary, sign up for a Pushover account and install Pushover and Pebble Notifier on your phone. Then install WebService::Pushover on your computer. Then you can write code like this:

use WebService::Pushover;

my $push = WebService::Pushover->new
or die( "Can't create Pushover interface.\n" );

my $status = $push->message(
message => 'Hello Pebble',
# Signing up to Pushover gives you these tokens

And that will send a message to your Pebble.

Now all I need is something useful to do with it.

Update: I’ve just noticed that there’s also an IFTTT channel for Pushover. It has nothing to do with Perl, obviously, but would be an easy way to trigger Pebble notifications for certain triggers.

Removing Modules from Core

I was on holiday last week and missed most of the discussions about removing Module::Build and CGI from the Perl core in the next few years. I hope you won’t mind if I chime in a little late with my thoughts.


I’m a little bemused by the Module::Build story. Well, perhaps “bemused” isn’t quite the right word. Perhaps I should say “embarrassed”. Embarrassed because the discussions around Module::Build just show how out of touch I am with important parts of the Perl ecosystem.

I remember seeing Schwern’s MakeMaker Is DOOMED! talk ten years ago. What he said made a lot of sense to me and I switched all of my CPAN modules to Module::Build over the next few years. And then I rather took my eye off the ball. I was vaguely aware that people were complaining about Module::Build and were switching to things like Module::Install and Dist::Zilla. But I was happy with Module::Build and just stuck with it.

Now I’m hearing people saying that Module::Build is fundamentally flawed. Someone whose opinion I value mentioned that he lowers his estimate of the IQ of any CPAN author who uses Module::Build. That, presumably, includes me. But when I ask people what the problems are with Module::Build, I can’t get anyone to give me a detailed and dispassionate answer.

I’m quite prepared to believe that there are problems with Module::Build. Given the calibre of the people who are telling me that these problems exist, it would be astonishing if it wasn’t true. But it would be nice if there was a good explanation available somewhere of just what these problems are.

And I think that this is indicative of a deeper problem that the Perl community has. I like to think that I’m pretty much in touch with what is going on in the Perl community. I read the blogs. I’m subscribed to (too many) mailing lists. But it appears I’m not following discussions of the CPAN toolchain closely enough. I guess it’s something that I just expect to work. And I guess I expect that if there are important discussions going on, then I’ll hear about them through other channels – blog posts, for example. But that doesn’t seem to have happened here. Of course I can subscribe myself to another mailing list or two to correct that, but I don’t think I’m unusual in not trying to follow every single Perl discussion. There are surely many people like me who would like information like this to be disseminated better. This is part of the reason why Leo and I set up the Perl News site. But we have a tiny number of editors and we can’t know everything that is worth publishing. If you think we’ve missed an interesting story then please let us know about it.

So I’m not going to object to Module::Build leaving the core. I’m sure there are good reasons, I just wish I knew what they are. I am, however, slightly disappointed to find that Schwern was wrong ten years ago and that ExtUtils::MakeMaker wasn’t doomed.


CGI.pm and I go back a long way. In fact I think CGI.pm was added to the Perl core at about the same time as I started using Perl.

It’s obvious why it was added to the core. Back in 1997, Perl and CGI were tightly bound together in many people’s minds. I had people telling me that Perl could only be used to write CGI programs and other people telling me that CGI programs could only be written in Perl. Both sets of people were, of course, wrong; but it’s easy to see how they reached both of those conclusions.

Before CGI.pm was added to the Perl core, people used to parse CGI parameters using horribly broken code copied from Matt Wright (code which he had originally copied from Reuven Lerner). Of course, adding the module to the Perl core didn’t magically rewrite all those horrible CGI programs to use CGI::params, but at least it meant that the option was there.

This became important to me when I started the nms project. This project rewrote Matt Wright’s scripts using a better standard of Perl code. The problem was that many people started by installing one of Matt’s scripts on their server and later, when they wanted to move on from using other people’s code, they would use Matt’s code as a template for their own first steps into Perl. This is partly what made Perl so popular. But it’s also what lead to the preponderance of terrible Perl code that you still find on the web today.

We wrote the nms programs to work, as far as possible, in the same environment as Matt’s scripts. Matt said that his scripts would work fine on Perl 4 (back then, there were still many cheap hosting plans that came with Perl 4). We decided not to put ourselves through that pain and to target Perl 5.004 – because that was the first version to include CGI.pm. Remember, we were targeting Matt Wright’s users. And they were people who used cheap hosting plans with basic FTP access and little or no chance of installing anything from CPAN. We had to rely on core modules. If CGI.pm hadn’t been in the Perl core, then the nms programs would have been far harder to write and the project may have never been started.

The nms project was started over ten years ago. What is the situation like now? Those cheap hosting plans still exist. People still use them for simple web sites. Some of those people still use Matt’s scripts or the nms alternatives. But the numbers of people using those programs are far smaller than they used to be. These days, people wanting to add simple dynamic functionality to a web site are far more likely to use a PHP program. And those cheap web hosts are far more likely to want to support PHP.

Of course, these days, no serious Perl developer uses CGI.pm to write web programs. We’d be far more likely to use something based on PSGI. And even if we did want to use CGI.pm, we’d know how to get it installed from CPAN. The only people who are going to suffer from the removal of CGI.pm are the people using something like the nms programs on a cheap hosting plan. I worry a little about the influx of support email we will get when some cheap hosting company updates from Perl 5.18 to Perl 5.21 and suddenly all the nms programs stop working. It’s slightly galling to realise that Matt’s scripts will continue to work at that point. Of course, the kinds of companies that we’re talking about tend to lag well behind the bleeding edge of Perl versions, so this might not happen for eight or more years. So I think it might well be someone else’s problem.

All in all, I think it will be sad to see CGI.pm removed from the core. It will effectively see the end of even half-decent Perl code being used on bottom of the range hosting plans. But Perl has been losing that market for years and, speaking as someone who spent a lot of time helping out on support forums for basic Perl/CGI code, I’m far from convinced that I’ll miss those users. So my sadness at seeing CGI,pm go, will be purely historical.

But I’d really like to see some cut-down version of PSGI take its place!

Perl School: DBIx::Class

Update: I’m sorry to have to announce that this course has been cancelled. I hope to reschedule for later in the year.

Tempus fugit and another Perl School rolls around.

Next Saturday (June 8th) I’ll be running my one-day course on Database Programming with Perl and DBIx::Class. As always the course will take place at Google Campus in London and tickets for the course cost £30.

The course is aimed at people who know Perl but would like an introduction to modern database programming using DBIx::Class. Full details of the topics covered are on the Perl School web site, where you’ll also find a booking form.

What New(ish) Perl features Do You Use?

Over on LinkedIn, someone asked me “What core PERL[sic] features do you use regularly that are new since 95?” It’s hard to be sure as the perldelta files only seem to go back to 1997 (for example, when were qw(...), q(...) and qq(...) added?), but here’s a quick list off the top of my head.

  • my was, of course, added in 5.0. But 5.004 added the ability to use it in control expressions – while (my $foo = <>) – and in foreach loops – foreach my $foo (@foos)
  • use VERSION
  • Regex extensions – (?<=RE) and similar. Oh, and qr/.../
  • Data::Dumper (added in 5.005)
  • Unicode support – first added in 5.6.0 and improved in every release since
  • our
  • Three-argument open
  • Omission of intermediate arrows in data structure lookups – $foo[$x][$y] instead of $foo[$x]->[$y]
  • use warnings
  • Memoize
  • Test::More and Test::Simple
  • say
  • defined-or
  • use base (or, more recently, use parent)
  • yada-yada operator

Have I missed anything obvious? What new Perl features do you use most?


I’ve been writing articles about Perl for a number of years. Because I have written for many people, the articles are currently spread out over a lot of different sites. I’ve decided to do something about this.

There’s now a new articles section on the site and over the next few weeks I plan to pull all of my Perl articles together in that section.

Currently, it just contains the seven articles that I wrote for perl.com. If you read them, please bear in mind the fact that they are all around ten years old and may well no longer reflect current best practices.

This coming weekend is a long weekend in the UK. This means that I may well find the time to republish a lot more articles.

Moose Course This Saturday

I’m running another Perl School this Saturday (6th April). This time the subject is Object Oriented Programming with Perl and Moose. I ran a two-hour taster version of this course at the London Perl Workshop back in November, but this is the full six-hour version. Tickets are £30 each.

The course is run at Google Campus on the outskirts of the City of London. There’s a full list of topics and a booking form over on the Perl School web site.