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.

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).

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.

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 Perl.com 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.