← Интервью /

Interview with David Golden (July 2015)

How and when did you learn to program?

I think I was nine years old when my elementary school class got a TRS-80 and I started doing some BASIC. Soon after, I had a TI-99/4A of my own at home and continued programming in BASIC. I'm sure it seemed quite serious at the time, but now I can't imagine what I was doing with it.

By high-school, I was programming in Pascal and starting with some C. In college I worked a lot with C, and then started with a little C++ and Java around graduation time.

What editor do you use?

In college, I learned emacs because most of the people around me used it, but it was never more than an editor; I never did any customization or programming.

When I started playing with Linux in the late 90's, I wound up needing vi for configuration. I got tired of re-learning it every time, so decided to make vim my primary editor on Linux. Eventually, I bit the bullet and installed gvim on my Windows laptop and never looked back.

Vim has been particularly good for me, as I struggle with RSI occasionally and can keep my hands the home row; I've disabled the arrow keys entirely in vim, and do CTRL-[ at least as often as I whack the escape key.

When and how have you been introduced to Perl?

I got into Perl in the late 90's when I was running a micro-ISP for friends and family on a Linux box on one the first DSL lines in the US. I was trying to decipher the "logwatch" program and got sucked in from there.

I spent a lot of time on Perlmonks in the early days. Reading and later answering questions there is probably how I got past my novice stage.

Using Perl on Windows led me to get involved in the CPAN Testers project (to more easily report the many broken modules on Windows). From there, I got further into the world of the Perl toolchain and eventually the core.

What are other programming languages you enjoy working with?

Most of my programming work is in Perl, C and shell. I have a love-hate relationship with C. It's often painful, but the ability it gives to be really specific about how data is represented and handled is really refreshing sometimes.

I'm currently infatuated with Go, though I've only had chance to dabble. It fits my brain in much the same way Perl does, and the speed (relative to Perl), concurrency model, and static compilation address several of the most glaring weaknesses that annoy me about Perl.

What do you think is the strongest Perl advantage?

I think Perl's whipuptitude is still its dominant feature. It scales immensely well between one-liners, small programs, and small systems, which means you get to take advantage of the same expertise for tasks big and small.

In some ways (but not all) I think Perl's TIMTOWDI philosophy is an under-appreciated strength that leads to constant evolution in ideas.

For example, I've started to explain to people outside the Perl community that Perl does OO with frameworks the way most languages do web programming. Need a full featured OO framework? Choose Moose. Want something lighter? Choose Moo? Do you have specialized needs? Fine, there are dozens of OO frameworks to choose from.

Ten years ago, no one knew much about traits or roles. Now, it's clearly a dominant feature of Perl's leading OO frameworks. You don't get that in a "batteries-included" language. You get it through lots of people trying to reinvent wheels that the language doesn't provide.

I should add that I don't think CPAN is one of Perl's strongest advantages anymore, at least not on a relative basis. It's still immensely useful, but many other languages have libraries just as deep. Startups are shipping APIs for "popular" languages before they ship them for Perl (if at all), so if anything Perl is usually late in providing libraries for suddenly popular services.

What do you think is the most important feature of the languages of the future?

It might be an over-used term, but I think "scalability" is the most important thing, but across numerous dimensions.

I think people focus on single-system scalability a lot, particularly single-system concurrency to take advantage of multi-core, multi-CPU systems.

But I think multi-node scalability will be equally important. The "cloud" already has people taking about servers as "cattle, not pets" and the popularity of containers will only push the elastic, utility computing trend forward faster.

I think that favors languages with a well-developed, message-passing model over ones that rely on shared-memory. While they are theoretically equivalent, in practice, I think programmers will have an easier time applying experience with the message-passing model to multi-node systems development.

I think it also favors languages with deployments that fit the "cattle" model. Static builds or easily-repeatable deployments will be crucial.

Another interesting scalability dimension is people. Some languages have a reputation (true or not) of being good (or not) for large teams. The best languages should be as good for a single developer as for a large team.

What are your thoughts on Perl 6?

My opinion hasn't really changed from my Feb. 2015 blog post:

It's still not clear to me what the "killer feature" is. If Perl 6 can be a much faster Perl 5 (by absolute performance or better concurrency), then I think it will be familiar enough that we'll see adoption by Perl 5 developers willing to trade the learning-curve for higher performance.

But I don't see anything that would drive adoption by other communities or new developers. The sheer size and complexity will be daunting. By contrast, Go – a small, highly-opinionated language – has become wildly popular in certain niches. It solves several serious developer pain points that appeal to both static and dynamic language enthusiasts.

I think the Perl 6 team needs to find a few key examples of features of the language that really shine compared to other languages. Not "clever features" – features that get back to the mantra of making hard things possible in areas that programmers encounter every day.

You maintain so many modules. How does it work?

First, I write a lot of modules! I've developed the habit of writing things I need as re-usable, independent libraries. That has pushed me to streamline every aspect of the module development process.

For example, I have a single shell function that creates a new distribution skeleton with Dist::Zilla and creates public and private repositories for it. That lets me go from an idea to coding a module in just a few seconds.

Second, I try to automate everything I can, both to minimize the amount of time I spend with routine stuff and to prevent repeating mistakes. Using Dist::Zilla for this has radically transformed how I ship code. The only thing I need to do before I ship is make sure the Changes files is up to date. Everything is on autopilot, including version numbering, pre-release tests, boilerplate Pod generation, git tagging, etc.

I also use Ingy's git-hub tool, which lets me manage Github comments and pull requests entirely from the command line. I can fetch a pull request, rebase it, test it, close the pull-request with a comment and ship it with Dist::Zilla in a matter of minutes without ever leaving the terminal.

Who wrote the first version of HTTP::Tiny, why was it needed?

Back in 2010, several people on p5p were discussing how Perl 5 couldn't bootstrap CPAN over HTTP without relying on command line tools like curl or wget. We considered putting HTTP::Lite in core, but it had a number of deficiencies and seemed under-maintained.

In response, Christian Hansen whipped up the first draft of HTTP::Tiny as a proof of concept. The goal was to have an HTTP client that was just enough to get to CPAN.pm working via HTTP and download LWP.

After the first draft came out, I started collaborating on the public API and refactoring the back-end code. Most of the networking code is still Christian's, even if git blame credits me because of the refactoring.

We've had a really good partnership. We try to talk through any major changes before implementing them and I think that's kept a good balance between features and minimalism. I've been really surprised (but pleased) that it has become a useful alternative to LWP for some people.

Do you think more ::Tiny modules should go into core?

Not just because they are ::Tiny. The original idea of ::Tiny modules was that they would do 90% of the job with 10% of the size/memory of some more popular module, while depending only on the Perl core. They are intended to be trivial to install or bundle, so they don't really need to be in the core itself.

Why are QA hackathons important?

A lot of the challenges in the Perl QA/toolchain world are hard to address in the scattered bits of time people have for them in their day-to-day lives. Either they need concentrated hacking time or they depend on getting the owners of different parts of the toolchain to all agree on how things should get done. The QA hackathons give QA/toolchain developers both the time and face-to-face contact to move things forward.

I elaborate a lot more about how and why the QA hackathons work in my annual writeups.

(If you want to support next year's QA Hackathon, you can donate to the 2015 hackathon and the funds will carry over to next year.)

As a p5p member, what do you think about stableperl?

Speaking only for myself, not p5p, I'm disappointed that the concerns that prompted it couldn't have been addressed in the normal development cycle.

That said, I think it's a wonderful experiment. Just like rperl, any experimentation around Perl 5 indicates some sort of demand in the user community for something they aren't getting from Perl 5 itself. If forks gain traction, that's a strong signal about what users find valuable.

Where do you work right now, how much time do you spend writing Perl code?

I work for MongoDB, where I lead development of the MongoDB Perl driver. That means that almost 100% of my coding time is spent on Perl (or XS).

Over the last year, I've been working on the "next generation" Perl driver, which is an almost total re-write of the original driver to improve consistency, compatibility, portability and robustness. According to git blame, I'm now responsible for over 90% of the code base!

I'll be shipping a release candidate in the next few weeks, so if you use MongoDB, keep your eyes open for it.

Should we encourage young people to learn Perl nowadays?

I think we should encourage young people to learn to program and the language is not as important as whether the experience is engaging.

When I was learning to program, green text on a black screen was pretty cool, so terminal-oriented programming was plenty engaging. These days, though, I think young kids' expectations are set higher and they'll want a more graphical experience for a first-language.

For older kids, I have mixed feelings about whether a dynamic language of any sort is the right thing to study as it obscures some fundamentals that are important to learn. But that might just be my own bias from having starting with Pascal and C.

Do you still have to work with Perl on Windows?

When I worked as a consultant, I had a work-issued Windows laptop and used it as my everyday Perl platform. Those struggles led me, ultimately, into CPAN Testers and helping Adam Kennedy create Strawberry Perl.

But once I could get free VM software, I shifted to a Linux VM for my day-to-day Perl programming. Much of my software was still "Windows-conscious", but I stopped wrestling the Perl rock up the Windows hill anymore.

Now that I'm at MongoDB, I have to care about Windows portability, so I'm starting to do more work on Windows again. I've been particularly happy with David Farrell's berrybrew, as it has made testing on various Perl versions much easier.

What kind of games do you play?

I mostly play board and card games these days (i.e. offline games). I recently got to try Seven Wonders and enjoyed it a lot. At home, my game playing is a bit biased towards things the kids can play, too. Ticket to Ride is in heavy rotation and my kids are pretty fond of Uno, as well.

Interviewed by Viacheslav Tykhanovskyi (vti)