Patrick Michaud joined the Perl 6 project in 2004, after the team put out a call for a compiler pumpking. Since then, he’s ported Perl 6 rules to Parrot, written an operator precedence parser, and has a working Perl 6 compiler. In addition, Patrick is an active contributor to the design of Perl 6 and the implementation of Pugs. Recently, he agreed to answer Perl.com’s usual interview questions.

People of Perl: Patrick Michaud

How do you describe yourself to the Perl world?

Basically, I just say that I’m the Perl 6 compiler pumpking. If people want to know more about my background, I’m a Ph.D. in Computer Science and was a CS professor at Texas A&M University-Corpus Christi for fourteen years. In 1991 I discovered Perl as an alternative to writing programs in awk or C, and have basically used Perl and promoted its ever since.

My favorite Perl quote is the one about “What is the sound of Perl?” For me, Perl has often turned potential despair at solving a difficult problem into joy at how easily it was solved with Perl.

How did you decide to take on the Perl 6 pumpking role?

In 2003 I left my nice, steady, tenured Professor position so that I could go off and do “something else”. At the time of leaving I wasn’t at all sure what “something else” might be, but being an academic was getting a “been there, done that” feel to it and so it was time to move on. Thus when the search announcement for the Perl 6 compiler pumpking hit my mailbox, I figured it would be a really interesting project.

Also, Perl has saved me so much time and pain (and provided success) in so many of my other projects, I hope I can give something back to the Perl community that has benefitted me so much.

You wrote the first version of PGE in C. Why? What did you learn?

Well, I wrote it in C mostly because I was still in the process of becoming familiar with Parrot, whereas I could do initial exploration of the problem space more quickly in a language I was familiar with. I also felt at the time (and still do) that if we can create a rules engine in C then it would be possible to re-use and embed it in systems other than Parrot.

You wrote the current version of PGE in PIR. Why? What did you learn?

My initial reason for switching to PIR was Unicode. I didn’t want to deal with Unicode issues from C, especially when Parrot was supposed to be providing that support anyway. But as I started rewriting PGE into PIR, I really came to appreciate the ready availability of hashes, arrays, and garbage collection – things that we Perl folks have long taken for granted. I was also very glad to have coroutines; they greatly simplify the issue of restarting a regular expression from where it last left off (especially restarting a subrule expression from where it left off).

But beyond that, most of the Perl 6 things we’ll be doing in the compiler are going to will be at the PIR (or PASM) level anyway, so it’s nice to be able to express the regex engine in that same language. A benefit I didn’t anticipate at the outset was how easy PIR would make it to combine top-down, bottom-up, and customized parsing subroutines. It’s nice to know that the top-down and bottom-up parsing engines can easily call Parrot subs as subrules (which could come from any source language) whenever that’s more convenient for parsing.

I still think it’s likely that at least some of PGE’s existing PIR components will be re-implemented in Parrot at the C level to get some easy performance improvements. But while we’re still in the development stage, it’s nice to have it all in PIR.

What do you absolutely hate about working with Parrot? Contrarily, what do you really like? Did that surprise you? Why?

I absolutely hate segfaults. I’ll be working along at a good pace, and then suddenly a segfault will appear and it’s like hitting a brick wall until I can lock it down.

Fortunately, this is no longer nearly as much of an issue as it was for me at first. Parrot seems to have become a lot more stable over the past year, and Leo (the Parrot pumpking) has always been very responsive and helpful with the issues I’ve raised. So, things are progressing for me much more quickly now.

As far as what I like about Parrot, I really appreciate the thought and ambition that has gone into its design. As PGE and the other compiler tools are starting to take shape, I’m surprised (and pleased) by how easy I think it will be to create language compilers and tools that run in Parrot. And I’m very excited by the potential for cross-language interoperability.

What does your programming environment look like? Emacs? Vim and the Unix tools? Mac OS X?

I’ve been using Linux for a long time (since the early Slackware distributions), although the precise distribution I’m using changes over time. I’m a RHCE, so I’m quite familiar with the Red Hat and Fedora distributions, but lately I’ve been using SUSE 10.0 Professional on my desktop because it seems to have slightly better 64-bit support. (And occasionally developing in 64-bit flushes out a Parrot bug or two that doesn’t manifest on 32-bit Linux.) I also keep a VMware workstation license around so that I can easily try things under another distribution or OS whenever I feel like it.

I’m definitely a longtime vi (now vim) user — in fact, I continue to use mutt as my primary email client just because it’s easier for me to compose email messages in vi(m) than in anything else. :-)

If three people reading this interview suddenly said “Hey, I have couple of spare hours to help out! What can I do?”, what would you suggest?

Well, for a couple of spare hours, we can always use more tests, either for PGE or for the Perl 6 compiler (or any other system). It would also be useful to just have people look at what has been done and ask questions about it so that I can know what things to be made more clear. I tend to be able to write more effectively when things are posed to me as questions.

I’m the first to admit that much of the code and design needs more support documentation. But I really hope it’s not too much of a hurdle to overcome — I suspect that within a couple of hours someone could get PGE to pass a few more of the Perl 5 regular expression tests. And I’m really working to make the Perl 6 grammar and compiler tools somewhat understandable to others, so that we really will end up with a system where customizing grammars and building custom language tools is a reality for many.

If time, money, and resources were no object, would you use your coding powers for good or awesome? What would you do?

I’d work on Perl 6. In reality, for me this question isn’t as hypothetical as it might be for others; one of the things I did before leaving Texas A&M University-Corpus Christi was to save up some money and resources to have some freedom from traditional work for a while. My family is also extremely supportive in allowing me to spend time on Perl 6 even though there’s no immediate monetary return. (And yes, I do still have paying contracts and jobs from time to time, but not so much that I’m left without resources to work on Perl.)

Overall, I like doing things that empower others to achieve their goals more easily. I’m thinking that Perl 6 will do that.

What’s the most valuable lesson you’ve learned while programming and how painful was it to learn?

One lesson I’ve learned is that it really pays to build a repertoire of many approaches to solving programming problems (or problems in general, for that matter). TMTOWTDI certainly comes to mind here. So often the key to solving a problem is knowing how to frame or ask the right question(s), and moving “outside the box” to see the problem in a fresh light or from different angles and perspectives.

The pain, of course, comes from building the repertoire itself. (”Good judgement comes from experience, and experience comes from bad judgement.”) It’s difficult to learn when it’s okay to accept a compromise solution, and when it’s better to refuse a compromise and search for a better one. It takes time and energy to learn, but it’s a valuable lesson.

What non-Parrot, non-Perl 6 projects are you watching with wise and considered eyes? Why?

I’m a big fan of wikis and social-networking systems. I’ve been developing and working on bulletin-board systems and collaboration environments since I was in high school; my Ph.D. dissertation was on evaluation strategies for hypertext environments. That was in 1990, today we just call it “the web”. So, I keep up-to-date with things happening in that space.

Undoubtedly upon reading this many readers will rush to the web to look at PmWiki and recoil in total horror to discover that PmWiki has been written in PHP instead of Perl, and wonder “What sort of Perl 6 compiler pumpking do we have?” However, I will say that I would’ve strongly preferred to use Perl over PHP, but I wanted to make it easier for “non-programmers” to be able to customize and work with the system, and at the time PHP offered a somewhat gentler learning curve for that audience. I’m looking forward to the day when I can convert it to Perl 6. OTOH, it’s been paying my bills so that I can have time to work on Perl 6.

Beyond that, I’m peripherally watching what is happening in the universe of programming languages. Recently I attended PyCon 2006 (it just happened to be held about 8 miles from where I live), and from that I had the impression that the Python teams are also working on the same sorts of things the Perl 6 community has been considering, such as ways to incorporate abstract tree representations and VM improvements. So, it’s interesting to watch the parallels and look for opportunities for cross-fertilization between languages.

Ultimately my interest is in finding ways to use technology to enrich people’s lives, or in builing the tools that help others enrich lives.

What’s one question you wish I asked and what is your answer?

I know what question many readers will wish you have asked, and that is “When will the production Perl 6 compiler be released?”

Officially, I still fall back on the standard “It’s ready when it’s ready” answer. I know that many are eager to see Perl 6 released, or worry that Perl is losing market share to languages such as Python or Ruby, or feel that it’s taking too long to develop to be any good. But Perl 6 and Parrot have some extremely ambitious goals, and it’s my belief that the value and impact of our hard work and patience is going to play out for a very long time — that is, over at least many decades. So I think it’s worthwhile to continue to keep a good portion of emphasis on the “done right” portion of “Second System Syndrome Done Right!”

On the other hand, I think the answer is now “sooner” more than “later”, and that we can point to real progress that is being made on this every day. First, we’ve achieved several important milestones — we have usable implementations of PGE and TGE as tools for building compilers, and we’re quickly reaping the benefit from having invested effort into developing those tools first. Several of the previously underspecified features of Parrot (notably, parameter passing conventions) now have working implementations.

Second, at the time I started as pumpking, I had the impression that many felt that Perl 6 was too ambitious, perhaps even to the point of being impossible to implement. There were certainly some features that I looked at and said “Wow, I wonder how that can be done?” But there are some really smart people who have worked on the design, and I think that Pugs has demonstrated that it _is_ possible to implement a Perl 6 compiler. So, a lot of progress has been made. Furthermore, Pugs deserves a whole lot of credit and recognition for moving many things from the “here’s how we think XYZ might work” stage to “here’s how XYZ works.” (Pugs has also developed an incredible test suite for Perl 6.)

So, in my mind, the momentum behind a Perl 6 compiler is now really starting to build. The low-level tools (which aren’t as easy or fun to work with) are now in place, the devilish details of many aspects of the language specification are being worked out in light of real implementations, and the opportunities and places where others can participate are growing rapidly. I’m looking forward to see where it all leads.