Interview - Perl’s Pumpking Ricardo Signes

Perl’s pumpking is the person who manages the core Perl 5 language. Having worn that mantle for almost five years, Ricardo Signes (rjbs) has set the next major release to mark the end of his reign. Over this period Perl has moved forward in leaps and bounds in terms of features, stability and popularity. I’ve taken Signes’ reflective mood as an opportunity to understand the person and processes behind Perl’s golden age.

http://mianwaheed.blogspot.co.uk/2012/10/halloween-jack-olanterns-carved-out-of.html

Before we jump into the interview, you’re probably wondering what the pumpking actually does. This is a role which has evolved with the language but there are two main tasks. The first is to enforce a regular release cycle (introduced by the former pumpking Jesse Vincent) and the second is to determine what goes in and what stays out.

http://www.dagolden.com/index.php/2499/visualizing-perl-5-release-history-2015-edition/

me: How did you come to be the pumpking?

rjbs: Jesse Vincent and I were lodging together at YAPC::Asia in 2011.  One morning, we went out and got breakfast, and he said, "Do you think that someday in the future, if I retire, you'd be willing to take over?"

I was definitely interested in the work.  It was partly technical, partly management, partly community relations, partly language design... lots of things that I was interested in, and I thought I'd do a decent job.  Also, that "someday in the future" seemed pretty far off, so I'd have time to prepare, or to weasel my way out of it if needed.

Then Jesse handed me the pumpkin about two weeks later.  Oops!

me: The period of your reign has been a golden age for Perl. It had been through a difficult period where the the community was drowning in dot-com code debt, and Perl was lagging behind other languages in stable features to address it. Over the last few years, both Perl and CPAN packages have advanced in leaps and bounds. What structure is in place to keep Perl on the same upward trajectory?

rjbs: A big help for this is perlpolicy. It demands that we keep backward compatibility as much as possible.  This is a huge deal for Perl 5, for a lot of reasons.

For one, it means that we don't knowingly break things unless we believe there's a good reason — and we've been trying to tighten up "good reason" a bit over time.  This means that it's almost always safe to upgrade your perl without unpleasant surprises.  The "incompatible changes" section of the changelog file should be short and fairly exhaustive.

For another thing, it means that we try very hard to get features right the first time.  We don't want to deliver a half-baked feature that we later regret... only to feel unable to fix it due to backward compatibility restrictions.

This is what led to creating the current "experimental feature" rules for adding features that might change, but then get stabilized.  In theory, the idea of experimental features was around, but it wasn't well-defined or enforced.  Weak references, for example, were considered experimental if you followed the documentation, but not if you asked any actual Perl programmers.

So, largely, we try to make sure that Perl doesn't alienate existing users by breaking their existing code; and that it doesn't frustrate future users by making them wish its features had been better thought out.

me: So in summary, the responsibility of the pumpking is to enforce Perl policy. In practical terms, what do you actually do?

rjbs: It's a job that will fill as much time as you let it, so I try to keep it under control.  Sometimes I have to forcibly change my habits, in both directions.  That is: sometimes I know I should be spending more time on the work, and other times I know I should step away from the keyboard for a day or two.

The most interesting - and difficult - aspect of the work is making decisions. And this can't be delegated. For example, I know that it's important to me to read every email to perl5-porters.  It helps me know who is doing what, it helps me see unexpected work getting committed, and it helps me better understand the code. Nobody else can read all this for me, I have to read it myself.  Then, the product of that work isn't actually a product for anybody else.  It's just a better understanding of what's going on that I can use in the rest of my work.  This can be frustrating, but it's also part of what makes any given success so rewarding.  I have the satisfaction of knowing that it's been made possible by careful attention to the project.

me: Now we’ve had a glimpse of you as the pumpking - how did you come to be a Perl developer in the first place?

rjbs: I started using Linux (and AIX, a little) when I was in high school, so I ended up with some little problems to solve, like stitching together parts of uuencoded files, or reformatting data files.  Everybody seemed to say that Perl was the tool for this, so I learned a little Perl.

Now, at the time, this meant Perl 4.  Perl 5 was actually out, but the Perl that I mostly read about was 4.  Also, my Linux of choice was Slackware, which stuck with Perl 4 forever.  As I recall, you could install Perl 5, but it came with a big warning about how it was new and experimental, and for people who needed really advanced features like "object-oriented programming."  I had seen C++, and I knew I didn't need that, so I ignored Perl 5 entirely.

I didn't get back to it for ages.  After college I was looking for work in systems administration, but ended up doing software development for a manufacturer.  I wrote the first batch of programs in PHP, but I didn't enjoy the language very much beyond the thrill of rapid results.  A few years earlier I'd come into possession of the camel book, but I hadn't yet read it.  I decided to read it and try rewriting everything in Perl 5.  It was a big success, and since then I've been pretty happy using Perl 5 for the majority of my work.

me: Who employs you as the Pumpking? Google tells me you lead the technical team at Pobox - is pumpking part of that role?

rjbs: Working on Perl 5 is not really part of my day job.  I'm sure there have been times that I skimped on an hour or two of work in order to get some Perl 5 work done.  Pobox is very supportive of my work, but this isn't a "20% project" or anything like that.

It's true that I'm the leader of the technical team at Pobox.  It's probably more forthright, though, to say that I am the technical team at Pobox.  For a few years now, I've been the sole full-time programmer.  (We're hiring now, though!)  Pobox produces a lot of Perl, and quite a lot of it is available on GitHub or the CPAN. They send me to conferences where I work on Perl 5, and they never say, "I think you've spent enough work time away from the office now, Signes."  It's definitely a good arrangement for me.

I've been working at Pobox for about 11 years now - about half of its time in operation.  In November, Pobox was bought by FastMail, an Australian company with a pretty similar mindset to us.  We're working closely now to benefit from each other's work, and so far that's been quite rewarding.  It also lead me to spend a few weeks in Melbourne in February. In other words: leaving my Pennsylvanian winter for their Victorian summer.  This was a good trade, and made better by the fact that it was great working with everyone at the Melbourne office.

me: What will you do when you retire?

rjbs: I will start deleting a lot more unread mail!

Even when I've passed the pumpkin on to someone new, I'll still have an interest in Perl.  I've got a lot of code that runs in it, after all, and I'll probably keep writing more.  So, I'll stick around and try to help.  I hope I'll make more time to work on my existing CPAN code, which has languished a bit for the last few years.  I'm also keen to write some more Rust, which I think is sure to still be around in the future.

I will probably also buy myself a really nice bottle of rye to celebrate.

If you want to work for rjbs at Pobox - or be the next pumpking - drop him a line. If you just want to make him happy, buy him rye. Rittenhouse 23.