Perl Usage

In my last blog post, I posted a graph showing that out of 135 companies at a recent Silicon MilkRoundabout recruitment event, only one said that they were using Perl. That has led to some interesting discussions that I’d like to address here.

I should make it clear that I wasn’t presenting my graph as evidence that Perl is dead. Of course you can’t leap to conclusions like that from what I learned at one recruitment event. I do, however, think that the situation is pretty grim.

But firstly, a few points that people made to me in response to my post.

We know that Perl isn’t used in start-ups
Yes. I think we do know that. But I don’t think we’re as worried about that as we should be. Imagine if that job fair was held fifteen years ago. Or twenty years ago. Perl used to be the language of choice for internet start-ups. What happened to change that? (I have some theories that I’ll cover in another blog post) Can this trend be reversed? (Honestly, I don’t think so – but I’m open to arguments to the contrary)

Every programmer I know uses Perl in some way
I think this might have been true fifteen years ago, but it hasn’t been the case for some time. If it’s really true that all programmers that you know still use Perl, then I think you only know a really bizarre cross-section of programmers.

All companies use Perl, but the HR department or management often don’t know
This is similar to the last point. And, again, I think it’s something that used to be true and hasn’t really been true this millennium. But there’s also the idea of Perl being the programmers “secret weapon” that the suits don’t know about. Even if it’s true (and I don’t think it is), then going underground like that is likely to be harmful to Perl’s popularity in the long term.

I think we should stop fooling ourselves here. Perl usage has been declining for over a decade. To a first level of of approximation, Perl is already a dead language.

Of course, The Perl community has spent a lot of the last few years actively denying that. I’ve been responsible for some of that drum-beating myself. But we need to accept that it’s true. For most people outside of the Perl bubble, Perl is a language that they last considered using back in the last millennium.

So, if Perl is dead, why has everyone spent the last five years demonstrating that this isn’t the case? Have they been lying to us? No, I don’t think they have. I just think that they have been looking at the wrong measures of success. Let’s look at some of the arguments I’ve seen.

CPAN is growing faster than ever
We have regular releases of Perl
Some great new features have been added to Perl
These all essentially boil down to the same argument – “Perl isn’t dead because some part of Perl (or its ecosystem) is improving”. I can’t argue with any of those facts, but do they really say anything useful about the long-term viability of the language. It’s great that Perl is constantly improving, but unless the people who are currently ignoring Perl can be persuaded to investigate these improvements, then they do little or nothing to stop Perl’s decline.

Moose might be the most powerful object system in the world. DBIx::Class might be the most flexible ORM available. Projects like these are great. But they don’t seem to be doing much to bring new people to Perl.

There are more YAPCs and Perl Workshops every year
Perl Mongers groups are starting all the time
We get dozens of people to our meetings every month
These arguments all boil down to “the Perl community is growing”. Again, I can’t argue with those facts (well, to be honest, I think the rate of Perl Monger group creation has slowed over the last ten years) but, again, I don’t think they prove what their proponents think they prove.

There is a difference between the Perl community and Perl programmers. Everywhere that I work, I find people who I already know from the community. But I always find far more people who I don’t know because they aren’t at all engaged with the Perl community. And I think it’s that large, untapped, number of non-community Perl programmers who make up the increased numbers of people attending meetings or conferences. This means that we are getting better at bringing our colleagues along to meetings. It doesn’t mean that more people are using Perl.

The number of Perl jobs is rising
Our company can never find enough Perl programmers
We just started a major new project using Perl
Most of the companies who use Perl continue to use Perl. That’s not really news. And some of those companies have grown really big and therefore need lots of Perl programmers to maintain and enhance their Perl programs. And that’s great. But it’s not really evidence of a grow in Perl usage.

Not all the companies who have historically used Perl continue to do so. Over the last five years I know of at least four big Perl-using companies in London who have started to move away from it for new development.

And one reason why people are always looking for Perl programmers is because many programmers have chosen to move away from Perl. I know plenty of people who were regulars at London Perl Mongers meetings ten to fifteen years ago but who haven’t written a line of Perl for over five years. This means, of course, that there is more work to go round those of us who are left. I could probably go through to my retirement maintaining existing Perl codebases. Those of you who are younger than me might not be so lucky.

 

So, to summarise, people who say that Perl is thriving point to three things – technical advances in Perl, the vibrant Perl community and the number of unfilled Perl jobs that always seem to be around. All of these things are great and are, of course, necessary for a living and growing language.

But they aren’t sufficient. You also need people outside of the community to take notice. And that’s not happening.

Ask yourself three questions.

  1. When did you last read a book on general programming techniques that contained examples written in Perl?
  2. When did you last read documentation for a web site’s API that included examples written in Perl?
  3. When did you last hear of a company using Perl that you didn’t previously know about?

This is why I published that graph a couple of weeks ago. Looking at that data, it really hit home to me just how badly we’re doing.

I have a couple of theories about why most of the world started ignoring Perl. I’ll get to those in my next blog posts. But, annoyingly, I don’t have any good ideas about how we might reverse the situation.

To be honest, currently my best advice (and the course I’ll be taking) is “brush up your Javascript”.

 

Programming Language Usage

Back in May, I spent an afternoon at Silicon MilkRoundabout. Silicon MilkRoundabout is a recruitment fair for techies. It’s specifically aimed at people who want to work for start-ups around the Old Street area (although they aren’t particularly stringent about sticking to that – for example, the BBC were there).

We were given a booklet containing details of all of the companies who were recruiting. Those details usually included information about the tech stack that the companies used.

Over the weekend, I went through that booklet and listed the programming languages mentioned by the companies. The results speak for themselves.

There were 135 companies at the event. About twenty of them unhelpfully listed their tech stack as “ask us for details”.

Here’s the graph:Usage of Programming Languages by Companies at Silicon MilkRoundabout

Usage of Programming Languages by Companies at Silicon MilkRoundabout

I’ll obviously have some more to say about this over the next few days. But I wanted to get the raw data out there as soon as possible.

Data Munging with Perl

Data Munging with PerlMany years ago, I wrote a book called Data Munging with Perl. People were kind enough to say nice things about it. A few people bought copies. I made a bit of money.

Recently I re-read it. I thought that some of it was still pretty good. There were some bits, particularly in the early chapters, that talked about general principles that are still as relevant as they were when the book was published.

There were other bits that haven’t aged quite as well. The bits where I talk about particular CPAN modules are all a bit embarrassing as Perl fashions change and newer, better modules are released. Although it was still available from Amazon, I really didn’t want people paying for it as a lot of it was really out of date.

But today I got an interesting letter from the publishers, telling me that they have taken the book out of print. And that all  the rights in the book have reverted to me. Which means that I can now distribute it in any way that I like. And people don’t have to pay a lot of money for a rather out of date book.

So, you can download a PDF of the book from http://perlhacks.com/dmp.pdf. Or I’ve embedded the book below.

I might even have the original documents somewhere. So if I get some spare time I might be able to produce a more reasonable ebook version (but don’t hold your breath!)

Let me know if you find it useful.

Dots and Perl

I was running a training course this week, and a conversation I had with the class reminded me that I have been planning to write this article for many months.

There are a number of operators in Perl that are made up of nothing but dots. How many of them can you name?

There are actually five dot operators in Perl. If the people on my training courses are any guide, most Perl programmers can only name two or three of them. Here’s a list. It’s in approximate order of how well-known I think the operators are (which is, coincidentally, also the order of increasing length).

One Dot

Everyone knows the one dot operator, right? It’s the concatenation operator. It converts its two operands to strings and concatenates them.

It’s also sometimes useful to use it to force scalar context onto an expression. Consider the difference between these two statements.

The difference between the two statements is tiny, but the output is very different.

There’s not much more to say about the single dot.

Two Dots

Things start to get a little more interesting when we look at two dots. The two dot operator is actually two different operators depending on how it is used. Most people know that it can be used to generate a range of values.

You can also use it in something like a for loop. This is an easy way to execute an operation a number of times.

In older versions of Perl, this could potentially eat up a lot of memory as a temporary array was created to contain the range and therefore something like

could be a problem. But in all modern versions of Perl, that temporary array is not created and the expression causes no problems.

Two dots acts as a range operator when it is used in list context. In scalar context, its behaviour is different. It becomes a different operator – the flip-flop operator.

The flip-flop operator is so-called because it flip-flops between two states. It starts as returning false and continues to do so until something “flips” it into its true state. It then continues to return true until something else “flops” it back into a false state. The cycle then repeats.

So what causes it to flip-flop between its two states? It’s the evaluation of its left and right operands. Imagine you are processing a file that contains text that you are interested in and other text that you can ignore. The start of a block that you want to process is marked with a line containing “START” and the end of the block is marked with “END”. Between and “END” marker and the next “START”, there can be lots of text that you want to ignore.

A naive way to process this would involve some kind of “process this” flag.

I’ve often seen code that looks like this. The author of that code didn’t know about the flip-flop operator. The flip-flop operator encapsulates all of that logic for you. Using the flip-flop operator, the previous code becomes this:

The flip-flop operator returns false until its left operand (/START/) evaluates as true. It then returns true until its right operand (/END/) evaluates as true. And then the cycle repeats.

The flip-flop operator has one more trick up its sleeve. One common requirement is to only process certain line numbers in a file (perhaps we just want to process lines 20 to 40). If one of the operands is a constant number, then it is compared the the current record number (in $.) and the operand is fired if the line number matches. So processing lines 20 to 40 of a file is a simple as:

Three Dots

It was the three dot operator that triggered the conversation which reminded me to write this article. A three dot operator was added in Perl 5.12. It’s called the “yada-yada” operator. It is used to stand for unimplemented code.

Programmers have been leaving “TODO” comments in their code for decades. And they’ve been using ellipsis (a.k.a. three dots) to signify unimplemented code for just as long. But now you can actually put three dots in your source code and it will compile and run. So what’s the benefit of this over just leaving a TODO comment? Well, what happens if you call a function that just contains a comment? The function executes and does nothing. You might not realise that you haven’t implemented that function yet. With the yada-yada operator standing in for the unimplemented code, Perl throws an “unimplemented” error and you are reminded that you need to write that code before calling it.

But the yada-yada operator wasn’t the first three dot operator in Perl. There has been another one in the language for a very long time (you might say since the year dot!) And I bet very few of you know what it is.

The original three dot operator is another flip-flop operator. And the difference between it and the two dot version is subtle. It’s all to do with how many tests can be run against the same line. With the two dot version, when the operator flips to true it also checks the right-hand operand in the same iteration – meaning that it can flip from false to true and back to false again as part of the same iteration. If you use the three dot version, then once the operator flips to true, then it won’t check the right-hand operand until the next iteration – meaning that the operator can only flip once per iteration.

When does this matter? Well if our text file sometimes contains empty records that contain START and END on the same line, the difference between the two and three dot flip-flops will determine exactly which lines are processed.

If the two dot version encounters one of these empty records, it flips to true (because it matches /START/) and then flops back to false (because it matches (/END/). However, the flop to false doesn’t happen until after the expression returns a value (which is true). The net effect, therefore is that the line is printed, but the flip-flop is left in the false state and the following lines won’t be printed until one contains a START.

If the three dot version encounters one of these empty records, it also flips to true (because it matches /START/) but then doesn’t check the right-hand operand. So the line gets printed and the flip-flop remains in its true state so the following lines will continue to be printed until one contains an end.

Which is correct? Well, of course, it depends on your requirements. In this case, I expect that the two dot version gives the results that most people would expect. But the three dot version is also provided for the cases when its behaviour is required. As always, Perl gives you the flexibility to do exactly what you want.

But I suspect that the relatively small number of people who seem to know about the three dot flip-flip would indicate that its behaviour isn’t needed very often.

So, there you have them. Perl’s five dot operators – concatenation, range, flip-flop, yada-yada and another flip-flop. I hope that helps you impress people in your next Perl job interview.

Update: dakkar points out that yada-yada isn’t actually an operator. He’s absolutely right, of course, it stands in place of a statement and has no operands. But being slightly loose with our terminology here makes for a more succinct article.

Perl APIs

For a lot of programmers out there, Perl has become largely invisible. They just never come across it. That might seem strange to you as you sit inside the Perl community echo chamber reading the Perl Ironman or p5p, but try this simple experiment.

Think of a web site that you use and that supplies an API. Now go to that API’s documentation and look at the example code. What languages are the examples written in? PHP? Almost certainly. Ruby? Probably. Python? Probably. C#? Quite possibly. Perl? Almost certainly not[1].

Perl has fallen so far off the radar of most people that when web sites write example code for these APIs, they very rarely consider Perl as a language worth including. And because they don’t bother including Perl then any random programmer coming to that API will assume that the API doesn’t support Perl, or (at the very least) that the lack of examples will make using Perl harder than it would be with plenty of examples to copy from.

This then becomes a self-fulfilling prophecy as Github fills with more and more projects using other languages to talk to these APIs. And the chance of anyone who isn’t already a Perl user ever trying to interact with these APIs using Perl falls and falls.

Of course, this is all completely wrong. These APIs are just going to be a series of HTTP requests using REST or XML-RPC (or, if you’re really unlucky, SOAP). Perl has good support for all of that. You might need to use something like OAuth to get access to the API – well Perl does that too.

Of course, in some cases good Perl support exists already – Net::Twitter is a good example. And to be fair to Twitter, their API documentation doesn’t seem to give any examples in specific languages – so Perl isn’t excluded here. But in many other cases, the Perl version languishes unnoticed on CPAN while other languages get mentioned on the API page.

I think that we can try to address this in 2014. And I’d like to ask you to help me. I’ve set up a mailing list called perl-api-squad where we can discuss this. In a nutshell, I think that the plan should be something like this:

  1. Identify useful APIs where there is either no Perl API or no Perl examples
  2. Write CPAN API wrappers where they are missing
  3. Approve API owners and offer them Perl examples to add to their web site

That doesn’t sound too complicated to me. And I think (or, perhaps, hope) that most API owners will be grateful to add more examples of API usage to their site – particularly if it involves next to no effort on their part.

I also expect that the Perl API Squad will produce a web site that lists Perl API support. We might even move towards producing a framework that makes it easy to write a basic Perl wrapper around any new API.

What do you think? Is this a worthwhile project? Who’s interested in joining in?

[1] Yes, I know there are exceptions. But they are just that – exceptions.