Interview with Jesse Vincent
Besides being the owner and president of Best Practical, the people who bring you RT, Hiveminder, Jifty, and svk, Jesse Vincent is the current project manager for the Perl 6 effort. He took over those duties from Allison Randal in 2005. He's also a co-author of RT Essentials and the author of many CPAN modules. The Perl Review intereviewed him about the current state of Perl 6.
The Perl Review: You're the project manager for Perl 6. What does that really mean in terms of day-to-day work for you?
Jesse Vincent: Mostly it means that I try to keep tabs on the various designers and implementors. I spend a lot of time asking "How are you doing?" "Are you having fun?" "Are you being productive?" "What's getting in your way?" and "Is there anything that could help you get more done?" The number one request is definitely "a 10 day week." Number two is a time machine. I'm told that Damian has something up his sleeve, but he's not letting anything slip just yet.
TPR: Let's get this out of the way. When is Perl 6 going to be ready for use by regular people? (Extra-question note: I'm just asking because people want to know. Weasel out of a hard date however you like). Do you have any control over that?
Jesse: Parts of Perl 6 are ready now. The super-hackers have been using little bits of Perl 6 for a couple years already, whether they're deploying Pugs in production or using Perl 6 features which have been backported to Perl 5, but more on that later.
Seriously though, Perl 6 will be done when it's done. It's no secret that there's another Camel book on the way. The language design has been converging and simplifying over the past year or so. At this point, we have at least three ongoing implementations of Perl 6: Pugs in Haskell, kp6 in a simplified Perl 6 on top of Perl 5 and Onion on Parrot. On top of that, Larry's written a standard grammar (p6-STD) for Perl 6 in Perl 6. At this point, there's ongoing work for each of the implementations to be able to use the new standard grammar.
One of my primary responsibilities as the Project Manager is to watch out for anyone demanding a deadline or ship date and jump in front of the bullet and let the implementation team work unhindered.
TPR: What's the scope of the Perl 6 project, in terms of your managerial involvement? Does it include Pugs? Parrot? kp6?
Jesse: I certainly talk to folks involved with all three projects on a regular basis. I spent a while helping out as Parrot's project manager, but decided to step back and concentrate on Perl 6. Will Coleda has recently taken over that role and is doing a fantastic job.
TPR: You inherited the Perl 6 Manager role from Allison Randal. How has the position evolved since then?
Jesse: Well, when Allison was the Perl 6 PM, she was also president of The Perl Foundation and a member of the design team. So, she was doing an awful lot more than I'm capable of ;)
TPR: Who gets to decide when it's time to stop changing Perl 6, considering that work tends to expand to fit the available time?
Jesse: Larry has said publicly that Perl 6 will never stop changing. That's one of the pillars of the design philosophy. It should be possible for Perl 6's syntax and semantics to continue to evolve over time without breaking existing code. But I think what you're trying to ask is "Who gets to decide when we get a blessed 6.0?"—My money is on whomever is editing Programming Perl 6. That's the best line in the sand we're going to get.
TPR: Several features in Perl 6, such as smart matching, have made it into Perl 5.9, and will be in that next stable release, Perl 5.10. How much is the Perl 6 effort driving new Perl 5 development?
Jesse: There's actually been quite a lot of ongoing work in the Perl 5 community to backport Perl 6 semantics (and in some cases even the syntax). We have everything from Moose (Perl 6's metamodel) to Perl6::Subs (Perl 6 subroutine definitions, currently a source filter but that's changable). And yes, smart matching is now a core Perl 5.10 feature. Pluggable regular expression engines in 5.10 should even make it possible to lexically use a Perl 6 compatible engine in place on Perl 5's regex engine. Other Perl 6 features keep popping up on CPAN. Have a look at Data::Bind.
TPR: One of the earliest fears about a Perl 6 project was that the core developers would abandon Perl 5. How has that actually worked out?
Jesse: Early on, Perl 6 drew a lot of the debate around the future of Perl 5 off into the RFC process. Perl 6 development actually really kickstarted a LOT of new work in Perl 5. New threading support, good unicode support, massive regex engine improvements and a hugely expanded test suite are only the tip of the iceberg.
What's happening now is that the Perl 6 implementations are starting to place new demands on the Perl 5 interpreter, whether it's Flavio Glock's 6-in-5 work (to help us compile Perl 6 source code to native Perl 5 code) or Larry's MAD PROPS abstract syntax tree emitter (to help us programatically transform Perl 5 code into Perl 6 code).
TPR: How well are the Perl core developers coping with effectively three branches of development: stable Perl 5.8, experimental Perl 5.9, and Perl 6?
Jesse: As I mentioned earlier, Perl 6 is being implemented by three different teams working on three somewhat different implementation tracks. It's actually fairly separate from the Perl 5 Porters who work on Perl 5. For all intents and purposes, they're two separate projects (though they share ideas and expertise all the time...and we've got a couple amazing switch hitters who work on just about everything.)
TPR: How might Perl 6 handle this when it has both a stable and experimental branch? Or will Perl 6 support use the Perl 5 model at all?
Jesse: I don't think we really know yet. One of the most important differences between Perl 5 and Perl 6 is that Perl 5 is defined by the implementation. Perl 6 is defined by the synopses and the test suite (currently maintained by the Pugs team). Any implementation that passes the test suite is genuine Perl 6. So, we may well end up with a number of different implementations, each with a different maintenance strategy.
TPR: Every week the Perl 6 team has a conference call (with summaries posted on use.perl by chromatic)? How important has that been? Does email just not cut it?
Jesse: It's the _design_ team, rather than the "Perl 6" team. It's good to get folks on the phone. It makes it a little easier to harass them. When I managed Parrot, we actually did a similar thing with a weekly IRC meeting. That works just about as well. But on IRC, you can't hear folks try to imitate Damian's lovely Australian accent.
A lot of perl6 development now takes place on IRC. #perl6 on irc.freenode.net and #parrot on irc.perl.org both see near-constant activity, with many of the developers around all day and all night. At this point, I'd say that IRC is actually probably more important than phone.
TPR: What's the key to keeping a project like Perl 6 moving?
Jesse: I think Audrey Tang said it best. "-Ofun". Perl 6 is a volunteer project, not some mindless corporate deathmarch. If it's not fun, it will never get done.
TPR: Is part of the Project Manager's job to prod and nag? How does that work when your prodding and nagging the Perl 6 designers, Larry Wall and Damian Conway?
Jesse: Prodding and nagging Larry and Damian works just like prodding and nagging any volunteer. Be friendly and direct, but at the end of the day, remember that EVERYONE involved is here because they want to be here and isn't obligated to do anything, no matter how much you want it to get done.
TPR: How is the Perl 6 effort, which is mostly volunteer work done by people with day jobs, different from running a full-time commercial project?
Jesse: Without the commercial pressure to "get it done now" we can actually "do it right." And really, at this point, more than 6 years in, there is no reason that shaving a month or a day off an estimate really matters. Perl 6's public image has certainly suffered because it's taken so long, but I wouldn't have it any other way. If we'd been on a commercial schedule, you would have had Perl 6 in 2003, it would look a lot like Perl 5.8, but probably wouldn't work as well and nobody would be using it any more. The long development cycle has ensured that Perl 6 won't be the Next Big Thing. But it's going to be the Big Thing After That. And it's going to be amazing.
TPR: How do you handle the tension between what developers are actually doing and what potential Perl 6 users want yesterday?
Jesse: Mostly, I ask the users if they can sponsor some development or work on the test suite. We get an awful lot of folks helping out writing tests—it's wonderful!
TPR: What's the biggest need, in your opinion, of the Perl 6 project? Is it a problem of resources, number of volunteers, or something else?
Jesse: We could definitely using more folks helping out with hacking and testing right now.
TPR: What does the Perl 6 project have too much of? If there was less of this thing, would Perl 6 work go faster? You don't get to choose "day jobs" as your answer.
Jesse: PR. Perl 6 got hailed as "just around the corner" for far too long. We burned a heck of a lot of social capital. Way too many folks have already written it off before it even got started.
TPR: What can the average Perl programmer do to help the Perl 6 project? What's the easiest way to contribute something right away?
Jesse: Tests! Pick up the Pugs test suite and start looking at sections of the synopses that don't have quite enough coverage yet. Larry's best guess is that we need to double the test suite before we've got proper coverage.
TPR: What's the best way for a new Perl 6 developer to start participating in the work?
Jesse: Haul down Pugs, kp6, or Parrot and Onion and write
say 'Hello World';
TPR: What can the casual programmer do to help? Are there things besides heavy virtual machine hacking and deep voodoo?
Jesse: Tests, tests, tests! Definitely the right way to get started.
TPR: Best Practical recently committed $5,000 to supporting Perl 6 development. You're giving these out in ten $500 microgrants, which is a new tactic for the Perl community. What prompted the new approach?
Jesse: It seemed like a good way to bring in a set of fresh new faces and give them a bit of a boost.
TPR: You gave Phil Crow a grant to translate Java classes to Perl 6 stubs. Why is this important?
Jesse: That's something you want to ask Tim Bunce about. Tim's using Phil's work to start to use JDBC as the backend and model for DBI 2.0.
TPR: Your company, Best Practical, has some of the bigger public Perl projects out there. Why did you use Perl for RT, your issue tracking application?
Jesse: At the time, Perl was the language I knew best, I worked for a company that built websites in Perl and I had a copy of the Camel within arm's reach.
TPR: Are corporate users of RT surprised that it's Perl? Do they think more highly of Perl after using RT?
Jesse: Generally, folks either already know RT is in Perl (and pick it because of that) or don't really want to look under the hood. It's generally fairly neutral.
TPR: Will there be a Perl 6 version of RT? How would Perl 6's features make that a much easier task?
Jesse: I'm particularly excited about being able to use multiple different versions of CPAN modules at the same time in the same codebase. We're finally getting solid API versioning for CPAN.
I can't yet speak to when we'll rewrite RT in Perl 6. First I'm concentrating on getting Perl 6 out and getting the next version of RT—built on Perl 5 and Jifty. But that's a topic for another day.