Skip to main content.

Interview with Allison Randal

The Perl Review: You've done almost everything there is to do in the Perl community. You're the author of Perl6 and Parrot Essentials, a main Parrot developer, a frequent conference presenter, a book editor for O'Reilly Media, and the former president of The Perl Foundation. Are you the hardest working person in Perl? When do you sleep? What's still on your list of things to be or do?

Allison Randal:I'm sure I'm not the hardest working person, but I do like to keep busy. Life is just more fun this way. :)

I don't have big plans after we release Perl 6/Parrot, but some interesting new challenge will come along. It always does.

TPR: As project manager for Perl 6, an O'Reilly editor, and (former) president of The Perl Foundation, you were perfectly poised to take over Perl. What would have stopped that?

Allison: LOL :) The fact that I'm not even the tiniest bit interested in the idea?

TPR: How did you find time to respond to this interview? Is this going to push back Perl 6's release date? Or did you staff out this interview to an intern?

Allison: I'm not actually one person, I'm a horde of Jodie Foster clones.

TPR: You were the president of The Perl Foundation for 3 years, but recently stepped down to spend more time hacking on Parrot.

Allison: Yes, I'm now working half time on Parrot. Mainly on the design documents and compiler tools.

TPR: What is Parrot, really, and what does it do? Which Perl 5 internals problems does it solve?

Allison: Parrot is a virtual machine, much like the JVM or .NET, except that Parrot targets dynamic languages like Perl, Python, Ruby, PHP, etc.

Two big Perl 5 problems that inspired the start of Parrot are unicode and threading. Those features were bolted on late in the life of Perl 5, so they've never been well integrated. This is a specific case of a more general problem with the Perl 5 internals: they've grown organically over the years and are difficult to maintain or extend.

We can actually target Parrot for several languages now (although not all of them may be useful).

In varying stages of completion, Parrot currently hosts implementations of Amber, APL, Basic, bc, Cola, Lua, Perl 1, PHP, Python, Ruby, Scheme, Tcl.

TPR: What's the biggest technical challenge Parrot has right now? What's the biggest social challenge?

Allison: Parrot is at a point where every part of the system is at least prototyped. The challenge now is filling in the gaps: making sure each part is fully specified and fully implemented. I'm currently working on draft design documents for events, exceptions, and threads. Dan Kogai and Audrey Tang are working a draft design document for Unicode.

The social challenge is that developing a virtual machine isn't always easy and fun. It's no problem finding volunteers for the easy and fun parts, but for the difficult or boring parts it's more of a challenge. Still, there are always a few of us who find the more difficult or obscure parts fun.

TPR: What's the best way for the novice Parrot hacker to get started?

Allison: Subscribe to the mailing list and follow along there. Download Parrot and compile it. Skim through the bug database to see if there's anything there you might be able to pick off.

As we get closer to the final release, we're also more concerned with code kwalitee (not to be confused with the vague and undefinable "code quality"), and we've been very glad to have Andy Lester start applying his skills there. Any beginner can help fill in the gaps in the documentation, and it only takes a little more skill than that to add tests.

TPR: Pugs, implemented in Haskell, has been a great boon for Perl 6. Will Parrot be able to take over soon?

Allison: Pugs has been a wonderful boost to Perl 6. And we're glad to have it.

Patrick Michaud is currently working on a version of the Perl 6 compiler using Parrot's parser and tree transformation engines (PGE and TGE). He has been working with Audrey Tang on his design plans, so I wouldn't call it so much "taking over" as the next logical step of evolution for Perl 6.

TPR: You rose up in the community pretty quickly. Was that just being in the right place at the right time?

Allison: I don't know. I was working as a Perl programmer for years before anyone ever heard of me. I even taught a Perl class.

If I had to mark a defining moment, though, I'd say January 2002 on the Perl Whirl cruise/conference. These cruises usually have arranged seating for dinner, and I was assigned the table with Larry and Gloria Wall, Damian Conway, and Mark Jason Dominus all week (I have no idea how it happened, I may have Neil Bauman or Randal Schwartz to thank for it). We had a great deal of fun talking about Perl, linguistics, science fiction, and just about every other subject under the sun. During the week Larry and Damian encouraged me to get involved with Perl 6 design, so I subscribed to the list and started contributing ideas. Damian also encouraged me to submit talks to YAPC::NA and OSCON that year, and they turned out well. That was pretty much that.

TPR: You have a background in linguistics, specifically a branch called tagmemics. How does that affect your view of Perl?

Allison: It increases my appreciation of Perl. So many languages are designed in a hodge-podge fashion, features thrown together without any consideration for how they fit together as a whole language. I used plenty of languages before Perl, but Perl was a joyful revelation.

TPR: For the layman, what is tagmemics and how does it provide insight into Perl?

Allison: Some aspects of tagmemics are the idea that you can't separate language from context, that different views of an element of language can yield significant results (something like the particle/wave discussion in physics), and that most things in language and in life involve overlapping hierarchies.

But, probably the most interesting thing about tagmemics for most Perl programmers is the fact that it's Larry's favorite theory of linguistics. Looking back through his talks and emails over the years, you'll see him refer to it over and over again, and if you look deeper, you can see how it influenced the shape of Perl.

TPR: What where you doing when you starting using Perl? Do you remember the first version you used?

Allison: I was working on minority languages in eastern Africa, using regular expressions to clean up language data. I think the version was 5.003_05.

TPR: I have this vision of an Indiana Jones outfit, and maybe some lions running around you. Was the work as exciting as I imagine? What was a typical workday like?

Allison: Not exactly Indiana Jones, but I did develop a fondness for safari hats. Er... no, not pith helmets, more like the twill bush hats favored in Australia. I'm not sure I ever had a typical work day. It ranged from drinking tea at the house of my language assistant for hours on end (a great way to collect language data), to driving across miles and miles of grass plains hoping not to get stuck in a river bed, to hiking through the hills so see the spot where so-and- so killed a lion or buffalo.

TPR: What advice do you have for other people who want to follow your path to become one of the movers and shakers in the Perl community?

Allison: Just do stuff. Write good code and encourage others to write good code. Write an article on how you use Perl for your local magazine or newspaper. Give a talk at a Perl Mongers meeting.

TPR: You live in Portland, Oregon, and there's quite an army of Perl developers there with more moving there every year. Did I miss the memo? Besides the temperate climate, Powell's Books, and 14 bridges, what's the attraction?

Allison: The rain. We're all amphibians. ;)

Portland is awesome. It has the technical focus of Seattle, WA, but the relaxed feel of Eugene, OR. People are friendly here. They actually smile and greet you in the grocery store. Downtown is big enough to be interesting, but small enough that you can comfortably walk from one end to the other. We get great musicians traveling through all the time, and fantastic local indie bands every weekend. It's green and beautiful, and has the country's largest city park (it's huge). It has free wireless in pretty much every coffee shop downtown.

Oh, but don't move here, because it's already overcrowded with Californians and the traffic is terrible because of the "no growth" policy. Really, I mean it, don't move here... Drat, there's another one.

TPR: How did you get into the development of Perl 6?

Allison: The first I heard about Perl 6 was at YAPC::NA 2001. Larry and Damian gave a session where they walked through some of the new ideas. Damian had just released Exegesis 2 a couple months before. I was excited; the changes felt so Perlish. I suddenly had a deeper insight into Perl 5, because I knew what it was evolving towards.

That session and Damian's "Life, the Universe, and Everything" opened my eyes to a world I didn't know existed. There was so much fun to be had, I couldn't stay away.

TPR: What were you doing before you got into Perl 6?

Allison: Working at a dot-com called Books-a-Million. Teaching an introductory Perl class. Hanging out with the local Linux user group (NLUG).

TPR: You co-authored the first book on Perl 6 (Perl6 and Parrot Essentials), which came out in 2003. Considering how much development has happened since then, can we expect another edition?

Allison: At this point it's a toss-up whether we do another edition of the Essentials book or just publish the Perl 6 edition of the Camel [Programming Perl].

TPR: The Perl Foundation owns the rights to Perl 6. Are the users going to see any difference from before, when Larry owned the rights?

Allison: They won't see any difference. The Perl Foundation stewards the Perl 5 code base as well, so the name on the copyright is really just a formality (one that offers Larry more legal protection, which is a big part of why we're making the change).

TPR: Last summer, you edited several new Perl books, after a long drought of new material in the Perl book market.

Allison: Yup, Advanced Perl Programming (2nd Edition), Perl Best Practices, Learning Perl (4th ed), and Perl Testing: A Developer's Notebook.

TPR: In the 1990s, it seems everyone wanted to publish massive tomes that claimed to be the definitive book on Perl (or Java or whatever), but recent books seem to be much thinner. Are specialized books more marketable now?

Allison: There's definitely a market for specialized books, but it's tricky to tap it. The books that sell the best are the ones with general market appeal. So all the titles O'Reilly published this summer are things that can be useful to any Perl programmer.

More specialized books sell fewer copies. "Fewer copies" doesn't sound bad, but the problem is that it's really expensive to print and distribute a book as a traditional publisher. You'd be horrified to hear how expensive it is, and how many copies the big publishers have to sell to break even.

TPR: Specialized books should also be easier to write and get to market, I would think, since the author doesn't have to write as much. Does the work of an editor scale down like that too?

Allison: The editor's time is generally a minor investment in publishing a book. So, yeah, from the editorial perspective it's fine to do a light editorial job on a large number of more focused books. The Pragmatic Bookshelf is doing a great job at this for Ruby and agile development books.

TPR: Besides the author and editor, who else is involved with actually getting a book published?

Allison: Reviewers from the community help make sure the book is technically accurate and relevant. Copyeditors check for grammar and spelling, while the editor focuses more on style and content. Artists produce illustrations and cover art. Tools people convert the manuscript from Pod, XML, or Word to the internal format. Production people check the format, fix it up, enter final changes from the copyeditor, editor, or authors, check cross-references, etc. Marketing people prepare promotional material and events. You need staff to maintain relationships with the various retailers, and to maintain the website where books are displayed. There are also people who maintain websites like to promote the language (and the books).

The author may only talk to the editor, but there's a huge team behind the editor working to make their book a success.

TPR: Once someone proposes a book idea, how does that idea get from the proposal to the contracts?

Allison: Often authors will approach me with a paragraph or two on their book idea, sometimes they'll start with a full proposal. The editor and author go back and forth a few times, shaping the proposal and the outline for the book. When they're both happy with it, the proposal goes on to a book approval group that decides whether the book looks good and whether O'Reilly will be able to sell it. If they approve, then we'll contract the book and the authors start writing.

TPR: As a editor, you have to deal with several different topics. How do you handle that? Do you learn it all yourself? Get outside reviewers? Just hope the author gets it right?

Allison: I'm happiest working on Perl books where I can immediately tell when the author is on target. For other subjects, I focus on making sure the writing is good, and rely more heavily on technical reviewers to catch inaccuracies. Good technical reviewers are absolutely critical to publishing good books.

TPR: I hear that you might be incubating a few books as a separate, print-on-demand publisher, Onyx Neon Press. What's the first books that we might see?

Allison: I'm currently editing a mod_perl 2 book, which is an expanded and cleaned up version of the online documentation. José "cog" Castro has an obfuscation book in the works. We're also looking at doing a book on SVK. These kinds of subjects are difficult for a big publisher to handle, because they hit a more specialized market. But, print-on- demand technology significantly reduces the investment needed to publish a book, so they're perfect for ONP.