Tag Archives: perl

Moving Stuff Around

A few weeks ago I talked about a few domains that I was going to let lapse unless anyone wanted to do anything with them.

No-one showed any interest so the domains will go away over the next few months.

But in order to hang on to the content, I spend a couple of hours last night moving some stuff around.

The stuff from perlvogue.com is now at perlhacks.com/perlvogue and the old proudtouseperl.com content is now at proud.perlhacks.com. I’m still holding out hope that I’ll find some people to resurrect Proud to Use Perl at some point in the future.

I’ve also set up redirections from the old addresses to the new ones – so hopefully Google will work out what has happened before the domains vanish off the web.

The perlfive.com and perlfive.org domains weren’t being used for anything, so I’m just going to let them die quietly.

I’ve never let so many domains expire before. I feel I’m growing as a person.

Perl Versions

There has been a flurry of Perl 5 releases over the last few days and there’s some evidence that this has confused a few people. So let’s take a closer look at what is available.

Perl 5.14.1
This is the most advanced stable version of Perl 5 currently available. It was released on 17th June. If you’re looking for the best version of Perl to use then this is the one to go for unless you have a good reason to choose one of the other versions mentioned below.

I’ve heard people mention the “stable Perl versions have an even number” rule as a possible reason not to use this version. They are wrong. That rule only applies to the middle integer in the Perl version number. Perl 5.10, 5.12 and 5.14 are stable versions. Perl 5.11, 5.13 and 5.15 are not. 5.14.1 is 5.14.0 with bug fixes. It is stable.

Perl 5.12.4
This version was released on 20th June. Due to a bug in CPAN, it currently shows as the most recent stable version of Perl. Well, maybe it’s not a bug as, strictly speaking, it is the most recent stable version of Perl. This version is a maintenance release on the 5.12.x branch. It fixes some bugs in version 5.12.3. Version 5.14.x is (obviously, I hope) a more advanced branch than 5.12.x. This release is intended for people who are tied to the 5.12.x branch for some reason. They get some bugs fixes but don’t have to switch to a whole new major version of Perl 5. Unless you’re tied to 5.12.x, you don’t need this version.

Perl 5.15.0
This version was released today (on 21st June). It is the first release in the 5.15.x development branch. This is the branch that will (in ten months or so) become Perl 5.16. The “stable Perl versions have an even number” rule applies to this version as the middle integer is 15. That’s an odd number. This is an unstable release.

That’s not to say you shouldn’t use this release. It has been released for a very good reason. The Perl 5 Porters would very much like you to download and try out this new version of Perl and report back to them with any problems that you see. But you shouldn’t consider putting it into production.

I hope that clear things up. If you’re wary of leaping to 5.14.x for some reason, then use 5.12.4. If you want a sneak preview of how Perl might look this time next year, then use 5.15.0. But most of you should be installing 5.14.1.

Doomed Domains

Summer is YAPC time. And YAPC means getting inspired on Perl-related projects. And that, obviously, means buying domain names for those projects. And that, inevitably, leads to lots of email from domain registries at about this time of year which roughly translate to “are you ever going to do anything useful with that domain you bought a couple of years ago, or should you just face facts and let it go?”

This year’s batch brings memories of projects from the last three years.

In Copenhagen in 2008 I gave a talk called Proud to Use Perl. To back it up I started a blog where I planned to share things that made me proud to use Perl. It didn’t last long. Even when I brought a team to help me, no-one had the time and nothing has been written there for two years. An advocacy site like that does more harm than good unless it it kept updated. So unless someone wants to take over the site (and keep it up to date) I’m going to let the domain lapse.

Lisbon in 2009 seemed to be largely about getting the Perl marketing project up and running. It was the scene of the famous Perl Marketing BOF. One of the ideas that came out of it was that Perl needed better web sites. I registered perlfive.com and perlfive.org in order to… well… I’m not really sure what they were for. Currently they both just redirect to perl.org. Do you have a better use for them?

And then last year in Pisa we had Perl Vogue. I was learning by that point and only registered the domain for a year. I’d really love for the Perl Vogue idea to really take off, but I’m not going to be the one to do it. If you want to try, then let me know.

Most of these domains expire some time in July. If you have ideas of what we can do with them then please get in touch. But, be aware that any suggestions that start “couldn’t you just…” are likely to be ignored. I’m looking for suggestions that start “I’d like too…”.

Perl Vogue T-Shirts

Is Plack the new Black?In Pisa I gave a lightning talk about Perl Vogue. People enjoyed it and for a while I thought that it might actually turn into a project.

I won’t though. It would just take far too much effort. And, besides, a couple of people have pointed out to be that the real Vogue are rather protective of their brand.

So it’s not going to happen, I’m afraid. But as a subtle reminder of the ideas behind Perl Vogue I’ve created some t-shirts containing the article titles from the talk. You can get them from my Spreadshirt shop.

 

Perl News

Remember use.perl? It’s moth-balled now, but for years it provided two valuable services to the Perl community.

Firstly it provided a hosted blog platform which many people used to write about many things – sometimes even Perl. Of course we now have blogs.perl.org which provides a very similar service.

And secondly, it provided a place where people could submit stories related to Perl and then editors would approve the stories and publish them on the front page. Since use.perl closed down, the Perl community hasn’t really had a centralised site for that.

Over the last eighteen months or so I’ve had conversations with people about building a site that replaced that part of use.perl. But there’s always been something more interesting to work on.

Then, at  the start of this week, Leo asked if I knew of a good Perl news feed that he could use on the front page of perl.org. And I realised that I’d been putting it off so too long. A few hours of WordPress configuration and Perl News was ready to go.

So if you have any interesting Perl news to share, please submit it to the site.

Evolving Software with Moose

Last night I was speaking at the Milton Keynes Perl Mongers technical meeting. I gave a new talk about how Moose (and, in particular, Moose traits) make Perlanet easier to maintain and enhance. The slides are available on Slideshare.

Too Easy or Too Hard

We hear a lot of people complaining that programming in Perl is too difficult, but I think that a lot of these problems stem from people making the opposite assumption – that writing Perl is easier than it actually is. Let me share a couple of examples. I’ve lightly disguised the companies in question – so if you think you recognise a place where we’ve worked together you’re probably wrong.

In the first, I’m working for a global organisation. Most of their bespoke software is written in Java, but (like pretty much every company) there are a few Perl programs running vital parts of the infrastructure. This company have also outsourced a lot of their maintenance work to another company in India. This Indian company has dozens of people who are dedicated to working on my client’s systems. But they are Java programmers and every once in while they need to do some work on a Perl program.

This company has an internal IRC network and there’s a Perl channel which I keep half an eye on whilst getting on with my work (which is maintaining a huge Perl program). A few times a day one of these Java programmers turns up on the Perl channel explaining a problem they have to solve in a Perl program and asking for help. In pretty much every case, the problem boils down to the Java programmer having major misconceptions about how Perl works. Perl programmers on the channel try their hardest to to help, but it’s often a frustrating experience. Usually the correct answer is “go away and read Learning Perl and Intermediate Perl, then you will understand how the code works”. But these programmers don’t have the time to do that. They need this task finished in an hour. Often it’s a task that could be easily achieved in an hour – but only after you’ve done the groundwork of understanding how Perl works.

The problem this company had was that Perl wasn’t seen as being as important as it actually was. People in the Indian company saw it as a “scripting language” that any of their (no doubt highly qualified) Java programmers would be able to use without any preparation or training. That’s clearly not the case.

But, I hear you say, that’s not fair. Perl and Java are really different languages. I’m glad you pointed that out as it’s a nice link to my second example.

In this example, I’m working for a dotcom company London. Like so many dotcom companies they have a Perl codebase that was thrown together five years ago in a couple of months by people who didn’t really know what they were doing. This company has the added problem that they are finding it hard to recruit people with Perl experience. So they start recruiting people with experience of languages like Python and Ruby in the belief that these languages are so similar that the programming skills are completely interchangeable.

And, of course, Perl, Ruby and Python are all a lot closer to each other than they are to languages like Java. But there are differences. Important differences that aren’t just syntactic. I can read Python and Ruby just fine. But if I got a job where I had to write a lot of either of those languages, I wouldn’t assume that I could just pick it up by osmosis, I’d get a book and read about the language. If I was going permanent at the company, I might even suggest that they send me on a training course.

Conversations with these non-Perl programmers often took a predictable course. They’d start complaining that the code was hard to read. This was hard to counter as a lot of the code was horrible. But if you pointed out some of the newer and better code, they wouldn’t see the improvement. They would insist that somehow Ruby or Python code was inherently easier to read than Perl code. I’d try to point out that Perl programmers find Perl code as easy to read as Python (or Ruby) programmers find Python (or Ruby).

So there seems to be this perception that Perl should be as easy to read as Random Programmer’s favourite language. And I don’t understand why that is. Just because I’ve been programming for almost thirty years, I don’t expect to be able to program in any language I happen to look at – well, certainly not well enough to be paid for doing it.

I’m not sure what we can do to counter this misconception. I think it probably stems from the late 90s when everyone was writing Perl. And if everyone is doing something, then it must be really easy.Of course, most people were writing really horrible Perl because Perl isn’t as easy as they thought it was.

Not sure it’s possible to sum this up in a simple marketing slogan. “Perl is Easy (but not as easy as you think)”.

Marketing Perl

Sometimes people ask me why Perl marketing is so important. This morning I came across an excellent example of the kind of thing that we’re trying to counter.

In the current issue of Linux Format, there’s an article about building a Twitter client in the bash shell. It’s written by Nick Veitch – who seems to dislike Perl a bit. In the article he wants to URL encode a string and can’t find an easy way to do it in bash. He writes:

However, the compromise I’ve found for this isn’t too bad (props to http://stakface.com/nuggets). It uses Perl and, like everything in that language, it looks like you ought to sacrifice a goat or something before you run it.

perl -p -e 's/([^A-Za-z0-9.-~])/sprintf("%%%02X", ord($1))/seg'

It’s not clear to me which part of the Perl make him want to start sacrificing goats. Is it the s/// syntax that Perl borrowed from sed? Perhaps it’s the regular expression syntax that Perl shares with pretty much any language with regex support. Or maybe it’s the sprintf function that Perl borrowed from C and that many other languages (including bash) support with a pretty similar syntax.

Of course I’m not saying that Perl doesn’t have some grungy corners in its syntax. But the three pieces of syntax used in this code fragment look to me like things that should be understood easily by just about anyone with experience of programming in the Unix environment.

And if this code is so hard to understand, why use it? I don’t know what Nick’s programming language of choice is, but couldn’t you do exactly the same thing in Python, Ruby or PHP? I can’t believe that Perl is the only language that is so powerful. And I’d be very surprised if the same code didn’t look very similar in many other languages.

So why the unnecessary little dig at Perl?

Of course, it’s clear that Perl isn’t a language that Nick is particularly familiar with (neither, indeed, is the person who he took the solution from). Anyone who knew Perl would realise that Perl’s standard distribution includes the CGI module which contains an escape function which does exactly what Nick wanted – without exposing the programmer to all of that scary syntax. I would write Nick’s code something like this:

perl -MCGI=escape -e'print escape "@ARGV"'

There are a lot of people out there with really strange ideas about Perl. People who don’t bother to find out the best ways to do things in Perl. And having widely-read Linux magazines printing snide comments about Perl does no-one any good at all.

This is why I think that Perl marketing is important. We need to reach the people outside of the echo chamber and tell them that Perl isn’t the outdated, hard-to-use language that they are being told that it is.

Update: I should have pointed out that I’ve sent an abbreviated version of this to Linux Format. Hopefully it’ll be published in the next issue. And I’m considering proposing a series of articles on Perl to them.

Perl Books

Those of you who have been following my work for some time might remember that many years ago I took some interest in Perl books. I don’t mean the kind of books that we all read (or, even write) with animals on the cover. I mean the kinds of terrible Perl books that at one stage seemed to take up over 90% of the space given over to Perl books in most bookshops. They had brightly coloured covers and made unlikely claims about how good you would be with Perl after an unfeasibly short period of time.

They all seemed to be written by people who didn’t actually know anything about Perl and they were full of the most atrocious Perl code that I’ve ever seen. Of course they were all not just about Perl but were about CGI programming with Perl (as that’s what everyone wanted to use Perl for ten years ago). It was easy to tell the quality of these books from the index. You just looked for mentions of “use strict”, “use warnings” or CGI.pm. Most books ignored them completely. At the time Schwern had a “litmus test” for the quality of Perl books. It was list of bullet points that you could use to easily calculate how bad a Perl book was. I seems to have dropped off the internet at some point in the last ten years.

Last weekend I was in the centre of London and I went into a couple of large book shops that I haven’t been to for some time. And it looks to me as though this problem has finally gone away. Looking at the Perl section in Foyles, for example, I saw a very few dodgy Perl books. Of course, there were far fewer Perl books of any quality than there would have been five or six years ago, but the ones that were left were pretty much all decent books.

My initial thought was that this was just another sign that Perl has lost the battle for the low-end web development market. People who want to hack up a web site no longer even consider using CGI programs written in Perl. These days those people would all use PHP. But it seemed to me that there weren’t many “Learn PHP in 24 Hours” books on the shelves either. So perhaps the low-end web development market doesn’t exist any more. Or, at least, perhaps it’s not big enough to make it profitable enough for publishers.

I’ll admit that my sample wasn’t particularly big. And Foyles isn’t exactly your average book shop. It caters for the higher end of the book-buying market. I wanted to test my hypothesis by looking at the computer books section in Borders over the road. But Borders has closed down. Another indication of the diminishing size of the book market.

I’m going to take this investigation further. I’ll check out the computer section in some lower-end book shops. But just to give myself some closure I’m going to declare my campaign against bad Perl books to be over. We won in the end. But it may be a slightly Pyrrhic victory.

Perl Twitter Feed

Last August, when I was writing my talk Proud to Use Perl for YAPC::Europe, I wanted to get a feel for what real people were actually saying about Perl. It’s all very well claiming that people say Perl is dead, but I wanted to get some real quotations to use in the talk. I came up with the idea of using Twitter. I set up a Twitter search feed for tweets containing the word “perl” and monitored that for a couple of days. I quickly got all of the quotations that I needed.

But I found the feed fascinating, so I continued to read it. Sometimes the Perl community can be a little insular, so it was interesting to read what other people were saying about Perl. I still read the feed today.

Over the year, the feed definitely feels like it’s getting bigger. I mean, there are more mentions of Perl. I don’t have any concreate figures because I read the feed at random times of the day and sometimes don’t touch it for a couple of days. It’s tempting to think that more talk about Perl is due to things like the Ironman initiative, but we shouldn’t jump to that conclusion. Firstly, more talk about Perl could just mean more people saying that Perl is dead (I don’t think this is the case) but secondly more talk about Perl could just be indicative of more talk on Twitter in general. Certainly the number of users on Twitter is still grwoing quickly, so that could probably explain the growth in Perl talk.

But over the last week or so, I’ve gradually realised that a lot of the increase in tweets mentioning Perl is due to the increase in spam (or, at least, spam-like) tweets mentioning Perl. I see a huge number of posts from accounts like @e_host which do nothing but advertise web hosting companies. I suppose we should take it as a positive sign that they think Perl is a feature worth mentioning in these adverts. There’s also been an increase it tweets that are reposts from hire-a-freelancer sites. For example, this morning I saw dozens of copies of this “Need Perl Expert” post.

I’m seriously considering dropping the Perl Twitter feed from Google Reader. It’s just becoming such a slog to go through it. I estimate that about a third of it it currently interesting – and that signal to noise ratio is only going to fall.

I do think, however, that it would be useful and interesting (and pretty easy) to set up an application which monitors the feed and records the data. If we just counted the number of posts, that would be interesting. We could even consider pushing the text through some kind of analysis to pull broad types of information from it (“is this a positive or negative mention of Perl?”). The sooner we start, the more data we’ll have to play with.

I think I’ll set something up tomorrow.