NeilB

Ricardo (Rik) Signes is a member of the Perl community who has helped the programming language move forward as far as features, stability, and popularity. Previously, he was Perl’s Pumpking (manager of the core Perl 5 language), during which time he oversaw 5 major releases. Currently, he is a board member at the Perl Foundation and CTO at Fastmail, leading a development team working in Perl every day.

This blog post is brought to you by Fastmail, a gold sponsor for PTS. More information about Fastmail is provided at the end of this article.

As a seasoned participant at the Perl Toolchain Summit, we wanted to ask Rik a few questions related to Perl and the summit, including why the event is valuable to companies like Fastmail. For this interview, Rik is being asked questions by Lacey Althouse, one of his colleagues at Fastmail (FM).

FM: How did you get started using Perl?

RS: When I was going into high school (for non-Americans, roughly aged 16), I hadn’t been programming for a while. I had done some BASIC and C, and just a little Pascal and Hypercard, but I hadn’t touched much of it in years. A friend of mine convinced me I should install Linux, promising that it would give me much better control over what I was doing with my computer, and I listened. At the time, this meant running Slackware Linux, which shipped with Perl. I think my attention got drawn to it because around that time, Perl 5 was pretty new, and the installer would ask, “Do you want good old fashioned Perl 4, or new experimental Perl 5 with lots of weird new features?” I picked Perl 4 and used it for all kinds of simple one-off tasks. For me, it was a glorified awk, which was useful but not very interesting. I probably would’ve forgotten all about Perl if it wasn’t for almost ten years later, when I found myself writing PHP (4!) to build in-house applications at my first job after college. I kept thinking, “There must be a way to break these programs up better than I can right now!” and that led me back to Perl 5, which made it much easier to componentize my software, test it, and re-use it. I stuck with it and kept diving deeper into the toolchain of libraries that made all that possible.

FM: Tell me more about why Fastmail uses Perl. How is Fastmail participating generally in open source communities?

RS: Perl is flexible and reliable. It has a few strong opinions, but for the most part it’s eager to give you the freedom to write your bugs in whatever idiom you’d like. This means that it can be easy to get started on solving problems without first internalizing a weird, foreign conception of reality. Some terrific languages only work when you submit to their model of reality, which can pay off, but can also be limiting, especially when your view of the world changes over time. With Perl, we can build a system the way that makes sense to us, but still integrate with the software written by the rest of Perl world. (Another one of Perl’s strength’s is the huge amount of software out there to reuse!) Despite all this flexibility — which means internal complexity — Perl has been very good about remaining stable over the years. Backward compatibility is a big priority for the ongoing development of Perl and its supporting infrastructure, which means that upgrading to newer versions rarely includes much cost. The cost gets mostly swallowed by the Perl system maintainers, instead.

FM: What’s the best part of working at Fastmail?

RS: I’m terrible at picking favorites, so here are a few. The people are great, and we’ve done a good job at keeping individual teams connected. They’re all very good at different things, and it’s good to know that there’s almost always somebody who’ll be able to answer any question correctly and also — and this is key — clearly. The product is great. I feel like we’re building something used by real humans to address their real human problems, and we actually talk to our customers to figure out how we can most effectively make their lives easier. Our values are great, but only because we’re really invested in them. We spend time, effort, and money on trying to keep the internet open and trying to keep your data easy to manage not just in the browser, but all through the stack. I also very much like being able to visit the National Gallery Victoria (Fastmail’s HQ is in Melbourne, Australia) a few times a year on the company’s dime!

FM: How long have you been participating in the Perl Toolchain Summit and what are some of the main benefits of attending?

RS: To my great surprise, I was invited to the first PTS in 2008, in Oslo. Back then, though, we called it the Perl QA Hackathon. We renamed it because we’d sometimes be told “well, a hackathon is more a bunch of people working a bunch of twenty-hour days to produce a half-baked proof of concept.” What we were doing was something else. We worked normal hours and tried to come up with plans and solutions that would last for years to come, even with only the limited time we had to work on them.

I think there are two big benefits, for me. Firstly, I’m able to feel like I’m putting my money where my mouth is. I put in real effort to help fix problems in the CPAN toolchain and to make it as resilient as possible, rather than just hoping for the best. This also means I can try to make the toolchain an ecosystem that works at least somewhat how I’d like, so I feel comfortable working on it continuously over time.

Secondly, and more personally, I always find my time at PTS to be reinvigorating. It’s several days where I’m disconnected from other work and put into a room with a few dozen really motivated, talented people who all share the same goals as me, at least in the broad strokes. When I head home, I often feel like I can accomplish anything.

FM: What’s the best part of the summit?

RS: Well, I’d be lying if I didn’t say it was reconnecting with all the people who I love working with but only see once a year. On a more work-oriented topic, though, it's the debates we have about weighing progress against stability. Perl has a well-earned reputation for not breaking things during upgrades, and the toolchain is where we’re at our most conservative. The debates about what we can change, how, and over what time frame are interesting both technically and on another level that speaks to how different people view the cost and benefit of technical change.

FM: What’s next for your work with Perl and/or at Fastmail?

RS: These days, I’m mostly an observer in the big changes in Perl, but I’ll continue to work with the toolchain gang to keep the CPAN going strong. I half-threatened to start a complete rewrite of PAUSE, the CPAN upload server, this spring. So far, though, I haven’t followed through, which might be the best thing for everybody involved!

We (Fastmail) have quite a few cool things planned for the near (and less near) future, from user-facing features (like better undo) to protocol-level enhancements (like JSCalendar) to internal updates (like new hardware platforms). Right now, I’m most excited when I see more and more of our internal tools move from legacy protocols to JMAP. I’m also working hard to continue to improve our ability to function effectively as a two-site company, in part by adding staff (for example, hiring to build a client and UI team in Philadelphia) and in part by improving our tooling for communication and documentation.

Also, there’s some discussion about installing a disco ball in the office, which would be another pretty good development!

About Fastmail

Fastmail is email, calendars, and contacts that give customers privacy and control. While other companies ask users to give up their privacy in exchange for email, at Fastmail, customers are treated like people, not products. Since 1999, Fastmail has provided a human-centered email alternative by putting customers first and offering reliable service, customer privacy and support, and thoughtfully designed experiences. Fastmail works to make email better for everyone through their work on open standards projects like IMAP and JMAP. JMAP is a new email standard that has been recently introduced through RFC8260 and RFC 8261 at the Internet Engineering Task Force (IETF).

Fastmail has developers in Philadelphia, USA and Melbourne, Australia, who work in Perl on a regular basis, and is often hiring. Job opportunities can be found at: fastmail.com/about/jobs

Ricardo Signes led the core Perl 5 programing language team for five years. During that time, he established the Standards of Conduct for the development community. He’s a prolific CPAN author, part of the "Toolchain Gang" that maintains the PAUSE and CPAN infrastructure, and is a noted speaker at Perl and open source conferences around the world. Currently he is a member of the Perl Foundation’s Board of Directors and CTO at Fastmail.

If you want to read more about Rik’s time as Pumpking, you could read this interview, from 2016.