Tag Archives: perl

Perl Search Engine

Often on sites like StackOverflow you’ll see questions that people could have answered for themselves if they had just searched the right web sites (usually perldoc or CPAN). But instead, they just went straight for Google and ended up with some dodgy, out of date information that just left them confused.

In order to get round that, I’ve created a Google Custom Search Engine which searches known Perl web sites. You can try it out here.

If you want to use this search engine on your site, the code is below.

<div id="cse" style="width: 100%;">Loading</div>
 <script src="//www.google.co.uk/jsapi" type="text/javascript"></script>
 <script type="text/javascript">
 google.load('search', '1', {language : 'en'});
 google.setOnLoadCallback(function() {
 var customSearchControl = new google.search.CustomSearchControl('008350714774536055976:a2zesuxuecs');
 customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET);
 customSearchControl.draw('cse');
 }, true);
 </script>
 <link rel="stylesheet" href="//www.google.com/cse/style/look/default.css" type="text/css" />

YAPC::Europe Preview

Earlier this year I met Josette Garcia at OpenTech and she told me about her new blog Josetteorama. She asked me if I’d like to contribute a few articles about Perl to the site. I agreed and then promptly forgot about it for a couple of months.

But I remembered my promise a week or so ago and realised that this would be a great opportunity to promote YAPC::Europe outside of the Perl community.

So I wrote an article called YAPC::Europe Preview. And she published it today. Hope you find it interesting.

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.