Celebrating women in Perl on Ada Lovelace Day

March 24, 2009 Advocacy, Community 4 comments

There have been a number of posts today for Ada Lovelace Day, honoring women in computing.
* Tim O’Reilly posts about [the women at O’Reilly]( who make things happen. If it weren’t for Edie Freeman, we wouldn’t think of the camel and Perl.
* Nat Torkington highlights three women, including Perl’s own Allison Randal, in [Ada Lovelace Day ABC]( Brenda Wallace gets a shout-out as well. Brenda’s not known for public Perl contributions, but she’s well-known as a driver of the Perl community in New Zealand.
* Casey West honors Audrey Tang, who should need no introduction. [Casey’s blog post]( gives the briefest of summaries of some of Audrey’s amazing achievements.
* Hundreds more at [](
I’d like to call out a few more Perl people while we’re at it:
* Skud (Kirrily Robert) who helped me start Perlbuzz, is at the top of the list. If you’ve ever used [WWW::Mechanize]( instead of dealing with the inner workings of LWP, thank Skud.
* Jacinta Richardson is half of [Perl Training Australia]( Together with Paul Fenwick, they are a huge force in the Perl community in that corner of the world. My understanding is that their marvelous [Perl Tips newsletter]( comes from her.
* Elaine Ashton was instrumental in getting the CPAN going, and keeping it going today.
* Ricardo Signes rattled off names to me: [Jess Robinson](, Karen Cravens, [Liz Cortell](, [Beth Skwarecki]( and “[Elizabeth Mattijsen]( who is TOTALLY badass.” Perhaps he’ll comment to fill in the details.
I’d like to also steal a bit from Tim O’Reilly’s article as well. He said:

My first hat tip has to go to my wife, Christina O’Reilly. She’s a playwright and choreographer, not a techie. But if you’ve been influenced by me, you’ve also been influenced by her…. [S]he’s been part of everything I’ve ever done, in the same way that Elizabeth Barrett Browning said of her husband, Robert Browning: “What I do and what I dream include thee, / As the wine must taste of its own grapes”

In the same way, let’s remember our spouses, partners, and other special women in our lives, starting with Larry Wall’s wife Gloria, who you’ve probably seen at Perl conferences keeping things together for the clan.
Whenever you see the work of someone like Josh McAdams, Ricardo Signes, or Casey West, you’ve got a Heather McAdams, Gloria Signes and Chastity West, and the rest of their families, supporting them. That’s community support to remember.
Please add your praise of the women of Perl I’ve forgotten or don’t know in the comments below.

How to write an announcement for your software project

March 22, 2009 Advocacy, Opinion 1 comment

In my job as editor of Perlbuzz, I get email all the time asking me to run announcements about all sorts of Perl-related things. They’re usually announcements of a new release of some module, or something about an upcoming conference. And usually I don’t run them, because they violate the first rule of announcing something:
An announcement that says “PerlWhacker v1.5.3 has been released” **is not interesting** to anyone but a small handful of people. The most important part of being interesting is that your announcement has to have an angle.
## Without an angle, there is no reason for the reader to read past the headline
The angle is the part of the story that says “This is why this is interesting to you, the reader.” There has to be a reason that a story is interesting, not simply a recitation of facts. There has to be a hook, a reason for the potential reader to see a headline, or maybe the first paragraph, and say “Huh, I’d like to read that.”
Here are some examples.
* **Bad**: “Devel::NYTProf version 2.04 got released, here’s the change log.” **No angle**, very boring, unlikely the reader will pay any attention to the story, if she even clicks it in her feed reader.
* **OK**: “Devel::NYTProf v2.04 got released, and it now uses 90% less disk space by using the Zlib compression library.” **Sort of interesting**, because the reader can say “Huh, that sounds like a cool hack. Still, what’s the effect on the reader?
* **Good**: “Devel::NYTProf v2.04 got released, and it uses 90% less disk space, because Nicholas Clark was trying to run NYTProf on the entire Perl test suite and ran out of disk space, and he worked with Tim Bunce on a patch.” **That’s an angle** because it tells a story that the reader can relate to.
* **Great**: “Devel::NYTProf v2.04, and it uses less space, because Nicholas Clark was running the Perl test suite against it, and here’s a link to the findings from that research.” **Bingo**!
## Assume that the reader knows nothing about what you’re announcing.
Finally, you must assume that the reader doesn’t know what you’re talking about. Most of the announcements I see are announcing to a small group of people who are aware of what is being announced, simply notifying that group that something has happened, excluding the readers not yet in the know.
I’m going to pick on the announcements for Summer of Code, both because they’re excellent examples of how to exclude readers, and because I want the GSoC to succeed wildly. That’s why I took the time to [revamp the announcement]( when I ran it last night.
The original announcement that Eric Wilhelm ran is this:

The Perl Foundation has been officially accepted into the Google Summer
of Code 2009 program as a mentor organization!

Hopefully some of you have identified some potential students already.
Now we need your help getting them to submit their proposals.

The student application period begins Monday, March 23rd and runs
through April 3rd. (Students note: you can edit your proposal
throughout that 11-day period — getting it started early and talking
to potential mentors greatly increases your chances vs throwing it over
the wall at the deadline.) See this page for details:

Interested students and potential mentors, please read the GSoC info on
the Perl wiki:

If you’re interested in mentoring or have a good project suggestion, now
is the time to get your info up on the wiki so students will know about
your code and where to find you.

Eric has done a ton of work for GSoC this year and last, and it’s safe to say that the Perl involvement GSoC wouldn’t be as great, in fact might not even exist, without Eric’s work, so this is no knock on Eric. But this announcement has some huge failings, and it leaves questions in the mind of the reader who doesn’t know what GSoC is.
* What is Google Summer of Code?
* Why is it interesting that TPF is a mentor organization?
* Why do I care about it?
* What’s in it for me, the reader?
* What is a student?
* Why would a student want to join GSoC?
* What is a mentor?
* Why would someone want to be a mentor?
In short, Eric wrote the announcement for the people who already know what GSoC is, and excluded the other 90% who don’t. [Jonathan Leto’s announcement]( has the same failings.
It makes sense why Eric and Jonathan wrote they way they did. They’ve been busting their asses for weeks (months?) working to set things up. They’ve been working inside the echo chamber of other people that are involved in the project. The parts of the project in the forefront of their minds are the details like how to sign up and how to write a proposal. However, to someone unfamiliar, it’s noise until he knows the overview.
## Get people to read your words
Whether it’s an announcement of your software, or a resume, or a posting in your blog, you have to give the reader a reason to read what you’ve written. When writing, we tend to focus on the details of the text, expecting that the reader will consume our every word. Problem is, people aren’t like that. We skim. We read titles. If it’s not interesting we move on.
In [my book on job hunting](, I hammer home the idea that without a compelling summary at the top of your resume, the reader is not going to spend much time digging the good stuff out of your bullet points at the bottom. It’s the same rule with announcements about your software project.
Next time you’re going to announce something, show the announcement to someone who is not involved with the project, maybe a co-worker or your spouse. Ask him or her to explain what you’re announcing. Try to understand how your article sounds to someone unfamiliar with it. Your project’s success may rely on it.

Updating the Perlbuzz look

March 11, 2009 Advocacy, Perl 5, Perl 6 3 comments

Thanks to Perlbuzz reader [James Robson]( for updating the Perlbuzz logo. It’s a little more polished, and it’s smaller so not quite so imposing on the front page. Now if only I understood all the CSS magic in the templates that I need to override. I love Firebug but I still don’t get what I need to adjust to tighten up the yellow bar.

Perlbuzz news roundup for 2009-03-03

March 4, 2009 Advocacy, Code craft, Conferences, CPAN, Perl 5, Perl 6, Perl Foundation, Rakudo No comments

Perl gratitude, 2008

November 27, 2008 Advocacy 1 comment

This year, I’m only listing a few Perl things I’m thankful for (still have to make corn souffle for dinner!), and I leave it to you, the Perlbuzz readers, to tell me yours. [Here’s last year’s list](
## Devel::NYTProf
I know, I talk about Devel::NYTProf a lot, but it’s such a huge leap forward in technology for us. I love love love it.
## Web414 & Bucketworks
I’m about as far from Milwaukee as I am from Chicago, and [Web414]( is a great community of people. It’s not all Perl, and not all programmers for that matter, but I’m glad they’re there. I’m especially glad for [Bucketworks]( and the amazing space they have there. If Pete Krawczyk (see below) and I organize another hackathon, it’ll be at Bucketworks.
## Ricardo Signes
Is there anything Ricardo doesn’t work on? He’s [Mr. Email](, he’s got an [assload of modules on CPAN](, and now he’s trying to [replace Module::Starter for module maintenance]( Someone out in Pennsylvania needs to buy him a beer for me.
## Pete Krawczyk
Besides being a relatively unsung guy who makes a lot of things happen, like being instrumental in organizing two YAPCs and a hackathon, Pete happens to be physically close by most of the time, usually in a cube kitty-corner from me, and I can bounce all my crazy-ass ideas off of him. He’s one of those people who doesn’t get the spotlight, but makes things happen behind the scenes.
## The Parrot team
I’m very excited about the progress that Parrot is making, [hurtling to version 1.0]( It’s the basis of Rakudo Perl, but it also will help bring Perl culture out into the open again.
## You
I’m thankful for you, the Perlbuzz reader, because you’re going to let everyone else know, either here or in your own blog, what you’re thankful for in the world of Perl this year.
Happy Thanksgiving to all, and I can’t wait for my post-turkey nap.

Is learning Perl the hard way the easy way?

October 5, 2008 Advocacy 2 comments

Bruce Momjian, guru of PostgreSQL, has discovered the joys of Perl.

I have converted two of my most complex shell scripts to Perl; as shell scripts, they were slow and hard to maintain. The rewritten Perl scripts are 200-400 lines long (about the same length the original shell scripts) and 15-25 times faster because of the improved algorithms possible in Perl and reduced subprocess creation.

What was surprising to me was how he’d learned, via a book I’d never heard of before, Learning Perl The Hard Way. Has anyone in the Perl Buzz readership read it? Comments?

Richard Dice trumpets Perl to the press

August 29, 2008 Advocacy, Perl Foundation 3 comments

Go, Richard, go!

Richard Dice, president of the Perl Foundation, is part of an article on the “state of scripting languages” in CIO magazine.

Of all the scripting languages, Perl offers the biggest installed base of applications, of code, of integrated systems, of skilled programmers. It has the lowest defect rate of any open-source software product. It is ported to essentially every hardware architecture and operating systems, from embedded control systems to mainframes. It is optimized for speed, for memory footprint, for programmer productivity. It has readily-accessible libraries for all types of programming tasks: Web application development, systems and network integration and management, end-user application development, middleware programming, REST and service-oriented architecture programming. Perl is ideal for the organization that takes charge of its own IT future.

Why do designers fail to adopt Perl?

August 8, 2008 Advocacy, Opinion 12 comments

A Perlbuzz guest editorial, by Dave Everitt

As the “the glue/duct tape/chainsaw that holds the web together”,
Perl is all but invisible to most web users. It is still one of the
languages of choice,
yet remains behind the scenes and out of the limelight. This “brand
invisibility,” coupled with the factors outlined below, has contributed
to the erroneous perception that Perl is outdated or unfashionable
in the glaring light of other more energetically-promoted solutions.
Despite the continuing dominance of LAMP, what do most web designers
think the “P” stands for? Not Perl.

Cultural perception and perceived popularity don’t help anyone to
make a logical evaluation; this is an attempt to put the record

“Design? That’s for designers!”

Many Perl monks (and other alpha-geek programmers) hold design in
some kind of contempt. Here are some comments by Perl coders:

  • Don’t trust designers with code:
    “…now you can pass “helloworld.tmpl.html” to your web designer
    to modify it in her/his favorite HTML editor. (Just tell her/him
    not to touch the HTML tags starting with “<TMPL_”)”
    HTML::Template Tutorial
  • Design is trivial:
    “If you find yourself lacking as a web designer or generally couldn’t
    care less, you can give your templates to a web designer who can
    spice them up. As long as they do not mangle the special tags or
    change form variable names, your code will still work.”
    HTML::Template Tutorial

This kind of wilful separation from design is a big put-off factor
to newbie web programmers, and is endemic throughout the Perl
community: “designers can’t come in here until they’re willing to
learn serious code”. In other words: “the aspirant must show
humility”. Understandable perhaps; and, once you start trying, the
community is as helpful and friendly as can be. Just not overly
welcoming to “designers”; in fact, some Perl websites appear almost
deliberately or even proudly ugly. Perl templating solutions like
Template Toolkit get ignored
by most web designers in favour of comfy, close-to-hand solutions
like PHP, ASP.NET, whatever Dreamweaver offers,
or younger and prettier models like Ruby on Rails or Python’s Django.

Here’s a more rational approach to the “design vs. code” separation:

“…the best Perl programmers are rarely the best HTML designers,
and the best HTML designers are rarely the best Perl programmers.
It is for this reason that the separation of these two elements is
arguably the most beneficial design decision you can make when
devising an application architecture.” —
Jesse Erlbaum, Using CGI::Application

This remains true, except that increasing numbers of people and
teams are becoming good enough at coding and design to handle both
passably well, They’re choosing to invest the time necessary to
learn both, as the Ruby on Rails explosion demonstrated.
The Perl community needs to respond with a makeover and, maybe,
some key “we’re cool”
websites like Catalyst’s website to help
rescue Perl’s dated image, even if many Perl programmers don’t care about it.

Most designers want to be included in the “our site is cool, therefore
we’re cool crowd,” not shoved in next to an ancient HTML website
in ANSI colours.

Where are my web pages? How do I know what does what?”

Programmers know that effective templating separates logic from
content from style. However, designers familiar with web pages and
visual appeal are often used to working with actual files, unlike
programmers who can hold everything in their heads, and in lines
of code that don’t look at all like what they’re going to produce.

Instead of these cosy actual files (the static web pages), most
templating means that a site’s links call a script that generates
the pages. In other words, your website becomes a web application
program, with all the power and flexibility. The literal, clunky
file-for-every-page website disappears in the process, and this is
just where many designers get a bit lost in starting the journey.

Both the original DHTML and current Ajax are effectively still
attempts to turn web pages into dynamic web applications. What isn’t
obvious to the designer is that these technologies have been around
for ages. They don’t see that secure and reliable interaction with
the server, solid yet flexible programming in Perl can drive a zippy
Web 2.0 site as easily as Ruby on Rails.

Designers who want to start programming sometimes fail to make the
conceptual leap from web pages as static files, to web applications
consisting of components and screens. Failing to make this leap
means they fall instead between logic and content by defaulting to
PHP, Dreamweaver templates, Cold Fusion, etc. Perhaps this failure
to make the complete leap happens because designers feel uncomfortable
without seeing the actual “pages” they’re working with, or because
the dominant web design software makes it easy to adopt its own
default solutions.

Where are the “Perl tools” for Dreamweaver? All the publiclity and
books read “Dreamweaver CS3 with ASP, ColdFusion, and PHP.” If Eric
Meyer can improve CSS support in Dreamweaver, could the Perl community
do the same towards integrating Perl tools? A million design houses
across the world might then at least see a menu item containing the
word “Perl” in their favourite software.

“Perl is impossible to read!”

Perl itself can be no harder to learn or read than the PHP to
which many designers default.
Learning Perl is far from dead, now in its 5th edition,
and is regarded as one of
the best books for anyone learning programming in general.

However, Perl programmers often delight in the potential economy
of the language, and their concise code can appear obscure and
impenetrable. I’ve even heard good programmers, fluent in other
languages, say “Perl is horrible” or “unreadable”. Yet to a beginner,
Java (to take one example) is far more “horrible”, verbose and
complicated — just compare “hello world” in both languages.

Actually, beyond that initial step, how easy code is to understand
depends on who does the coding. Precisely because there’s more than
one way to do it, Perl can be written as readably as any other
language. Most times this isn’t obvious to a beginner because
Perl coders don’t
need to keep it obvious when they can use powerful shortcuts or
write one-liners. With this in mind, my Perl monk friend replied
to a draft of this article with a “line noise” of caution:

I wouldn’t recommend it as a first language. It’s a second or third
language. That’s when it becomes powerful. I wouldn’t want to put
people off programming by making them look at

“Perl/CGI is slow (and gets slower with increasing server load)”

This isn’t true with FastCGI FastCGI or
But try
telling a designer who may only just be discovering the unforgiving
nature of the command-line that these are an easy install. Or
persuading a popular shared hosting provider (where many designers
are hosting) to supply them on their list of default options.

To complicate the issue, there’s also a groundswell of opinion
against the complexity of
frameworks in general,
with sites prototyped in Rails being redeveloped with other tools.
Then there’s the
shared hosting

Isn’t there a gap opening up here for tried-and-tested but nicely
packaged Perl solutions for web development? Can’t we fit between
a designer’s static pages and a full-blown framework? But just try
finding a good-looking Perl templating tutorial that shows off the
kind of tidy, well-crafted and semantic XHTML and cutting-edge CSS
that the best designers produce, or a one-click Perl template install
with a good-looking promotional website.

Rails has demonstrated that speed isn’t initially the issue. Ease,
buzz, style and ubiquitous market presence are. Perl doesn’t have
to remain the dowdy elder sister — given the same kind of push,
it can go to the ball too.

“So what’s a poor designer to do?”

If you want to develop your skills, ask “will I be using a programming
language at least 2-3 times a week to actually do something; that
is, as much as you currently use (X)HTML/CSS?”
If not, you’ll almost certainly forget what programming
you learn and might be better off leaving it to “real programmers”.

However, if you do want to develop those skills, a good route is
to experiment with a templating system that encourages the separation
of logic and presentation, like HTML::Template or Template Toolkit.
Work through the tutorial websites and just get something working.
All you need to know for starters is that HTML::Template fills HTML
templates dynamically with data according to the logic in your Perl,
or that Template Toolkit generates static pages from your Perl.

What you, the designer, must learn first

You do run Apache locally on your machine, don’t you? Okay. Now get
CPAN and use it to install Perl modules
for your platform. Be mindful of
case-folding if you’re on Mac OS X
Yes, I know there should be a guide to all this, but like all
learning curves in big territories, there’s no authoritative manual.
To make it easier, perhaps there could be.

To make an intelligent comparison, you might want to try Ruby on
Rails. The latest OS X already has RoR bundled.
If you’ve done all this and are still committed to PHP, keep the logic
apart from the design or tears of despair will follow.
Steer clear of the
convolutions that PHP allows, and note the following

PHP has full support for classes, attributes and methods, and
supports object-orientation, but the key problem is that no one
seems to use it! There is a vast body of sample PHP code on the
web, but nearly all of it is absolutely dreadful.
HUGE long procedures,
no structure, little code refactoring, and intermixed code and HTML
that is impossible to read and must be impossible to maintain.
— Tim Roberts, Python Wiki

Anyone who has been there will echo “yes, it is impossible to
maintain,” but that’s not the language’s fault.
It might not all be squeaky-clean, but there isn’t a vast body of
“absolutely dreadful” Perl on the web. As a designer looking to
settle on a language, that’s a very valuable pointer. If you’ve
ever had to plough through lines of “impossible to read” and
“impossible to maintain” PHP, you’ll understand that
although PHP can be written as well as any other language, it often

If ways can’t be found to improve the overall quality of PHP
authorship, well-styled bridges just need to be built for designers
serious about programming to visit the Perl community. When they
get there, they’ll need to feel at home.

Dave Everitt is a
print-turned-web designer/developer who internalised HTML and CSS
in the last century and steadily developing Perl skills in this
one. His work includes the roles of web designer, educator and new
media academic.

Acknowledging “An argument for PHP”

May 12, 2008 Advocacy 13 comments

Adam Scheinberg makes an argument for PHP, which is fine in itself, but misses a key point about those of us who are horrified by PHP as a language.

I argue than everyone posting about how PHP is a bad language as a whole is an idiot. Every single one. Each is a foolish, arrogant, nerd sheep who can’t think for themselves.

Scheinberg acknowledges some of the problems with PHP, but then says that PHP is good because you can run it all over the place, and many big sites serve lots of traffic with it, and boy isn’t mod_perl a pain in the ass to install? And sometimes PHP is just a great tool for the job at hand:

[t]hose who would forsake “the right tool for the job at hand” shouldn’t be trusted even to water your plants, because they are obviously nitwits. If you can’t concede that PHP can be the right tool some of the time for some situations, you shouldn’t be trusted to code or make adult decisions.

Can’t disagree with that at all, Adam. It’s all a matter of using the right tool for the job. Sometimes that right tool for the job just happens to be a crappy language.

So, as a foolish, arrogant, idiot, nerd sheep, we can agree that:

  • Sometimes people’s decision process brings them to the conclusion that PHP is the best tool for the job, and I don’t doubt that they’re right.
  • I don’t mind using PHP packages because I don’t have to write in it.

Nonetheless, PHP is still an awful language, and in my decision making process, the pain & anguish I go through to use it means it rarely winds up as the right tool for the job.

Perl must decentralize, diversify and colonize

May 6, 2008 Advocacy, Community, Opinion 23 comments

Perl’s big problem is one of perception. The other day, a job
candidate asked me “You’re moving your web apps from PHP to Perl?
Shouldn’t it be the other way around?” Why did he think that? The
candidate knew no Perl, and only a bit of PHP, so had no technical
reason to believe that PHP was better than Perl. So why did he think
Perl was subservient to PHP in the web arena?

What I suspect is that Perl is just less visible, and
not just in the sense of
crap like the TIOBE index
where it equates hits for
“Foo programming” popularity of the Foo language.
 I’m talking about in the real way people see the
world of programming.

I’m certain that PHP has become a de facto
choice for basic web apps because it’s just How You Do
It these days. You see enough PHP in the context of the web, it starts to sink in.

Why is Ruby on Rails so popular? Is it better than Perl on Catalyst?
Or is it just that people hear about Rails more? I suspect the
latter, because perception is reality. When people perceive
Perl as being dead, or not as powerful as other tools, it might as
well be.

There are three goals I’d like to address:

  • Perl needs diversity, needs new blood, both in
    users and community as well as tools.
  • Perl needs more active mindshare in the programming world.
  • Perl 5 must continue to be seen as a viable language.

The three actions to take: Decentralize, diversify and colonize.

Perl must decentralize

Perl has a great infrastructure. We have the CPAN. We
have the various sites of We have Perl
Mongers and perlmonks, and so on. Unfortunately, we’ve
grown complacent. It’s time to start looking elsewhere
for infrastructure and community.

Standardization on tools makes sense if the tools are
the best possible tools available. In many cases, the
infrastructure already in place in the Perl community
may not be the best there is.

Is the Mailman installation running on the best
mailing list solution for you when you need to start a
mailing list? If not, then consider other options.
Starting a list at is
trivial, for example.

Is the
best bug tracking solution for your modules or
projects? If not, then look at other options. Many of
my modules, such as ack and WWW::Mechanize are hosted
at Google Code, where I use the bug tracking system

Is the
best place to host your blog? Maybe you should post
somewhere else. Certainly that was the case with me. I found that wasn’t the news site I
wanted it to be, so I started Perlbuzz as an alternative, literally
doubling the number of news sites devoted to Perl.

Note that “alternative” does not me “replacement”. It’s possible to have
two similar but diferent projects, websites or whatever that both fill a need.
If, say, Perlbuzz replaced, we’d still only have one news site, which
is no better a situation than we started with.

Some of the alternatives might not be community-based. Google Code,
is not run by altruistic volunteers.
Commercial interests will usually have more time and money to spend
on providing useful infrastructure.
That’s no
knock on the volunteers, but merely taking advantage of what the commercial
interest has to offer.

(I know at some point someone will say “At some point decentralization
is harmful.” I agree, but we’re nowhere near that point. Such a problem to have!)

Perl must diversify

The mantra “There’s more than one way to do it” is at the core of Perl
the language, but this is not always the case in the Perl community. We must always remember the guiding
principle of TMTOWTDI.

The first place to diversify is with people. I suspect, but cannot prove, that the Perl community’s size
is a net loss as time goes by. We must constantly be trying to bring new people into the fold, to take advantage
of their innovations, and to make what we do more fun.

Second, we must be willing to launch new projects, even if they’re similar to existing projects. It could be a module,
or a website, or an entire application.
The knee-jerk resistance to diversity often sounds like this:

  • “Why do we need Getopt::Whatever, we already have Getopt::Long”
  • “Why do we need another templating system?”
  • “Why do we need Jifty/Catalyst/whatever? We already have Maypole.”
  • “Why do we need Perlbuzz, we already have”

I’ve never understood this fear. It sounds like the resistance is based on the premise of “I wouldn’t want
to do that project, so you shouldn’t either.” It’s the refrain of someone with a closed mind, unable or unwilling
to imagine what could be.
In the case of similar modules, the refrain usually goes “It’s too hard to find the module you want anyway,” but that’s
not a problem of the module, but of the way things are found in CPAN itself.
(And if you’d like to address that little bit of decentralization, please take a look at my
Rethinking CPAN mailing list.)

Ultimately, fear of the new is counter to the principle of TMTOWTDI.
Indeed, plurality is at the very heart of open
, and it’s additive, not subtractive.
Template Toolkit need not take away
from Mason. Perlbuzz need not take away from Perl didn’t take away from awk and shell.
In any of these cases, if the new solution does take
away from another, then the other solution was an
inferior one to begin with.

Decentralizing and diversifying do two things. First, it opens our
minds to alternatives that we may not have considered.
It makes us more likely to find solutions that are
better than what we started with. Second, it helps
with colonization, the ultimate goal.

Perl must colonize

The other day, Tim O’Reilly posted on his Twitter feed
a link to a
cool article about life in the universe
Von Neumann probes
, theoretical space craft that
can replicate themselves using materials found in their
travels. A single probe could travel some distance,
replicate a thousand cloned probes, which would then
launch in a thousand different directions, repeating
the cycle.

That’s what we need to do: Colonize the mindshare of the world
to let them know that Perl is still viable, and a hell of a lot of fun.
These new Perl lovers will spread the love as well, and the cycle will continue.
In terms of action, it means simply “helping make more people aware of Perl as a
cool & useful language.” Fortunately, it’s a case where we can think globally and act locally, even passively.

The biggest effect I see you, the reader, as being able to have is by spreading out Perl’s web footprint.
I want more places for people to find out about Perl,
rather than a few big ones.

This colonization approach goes hand-in-hand with
decentralization. Take my ack project, for example. ack has
a number of footprints out there:

That’s three times places for people to stumble across Perl, to see it mentioned. A separate home page also
makes it more likely to get linked from somewhere else, as when
Daring Fireball
linked to ack and thousands of people came to see about ack. That’s thousands of people who went and saw “Huh, here’s a tool
in Perl.”

Of course, a few thousand visitors isn’t going to change any mindshare. That’s
why it’s not just me that needs to work on this. Fortunately, decentralizing
and diversifying makes colonization easy.

Our Google footprint is pretty bad, anyway. When I search for “perl” in Google, the top five hits are:

  •, which is a good base.
  •, O’Reilly’s Perl page, also a good base.
  • The wikipedia entry for Perl, which certainly isn’t much help for a beginner
  •, with its front page that expects that you know what you want.
  • An old perl 4 man page from Carnegie-Mellon University

Is this the best impression that we have to give the world?

Adam Kennedy gets it

Adam Kennedy’s Strawberry Perl
is a marvel of the principles I’ve talked about. Strawberry
decentralizes, as it uses none of the core infrastructure, and
it diversifies and colonizes by giving Windows users an alternative
to ActivePerl, which for many users is not robust enough.
When people talk about Strawberry Perl, it helps with mindshare as well.

Adam is a great example of someone who has set out to make improvements to a part of Perl,
and implemented it without worrying about permission or duplication, helping Perl as a whole along the way.
I thank him for it. I suspect his Perl On a Stick project will have similar results.

How you can help?

The strategy of decentralize/diversify/colonize takes actions at all different
levels. You don’t have to go create your own Perl distribution, or even write any code.
Here are some other ideas to get you started.

  • Post a Perl-related web page to Digg,
    reddit or any of the
    other social bookmarking websites.
  • Bring someone new to a Perl Mongers meeting, even if
    Perl isn’t his/her primary language. Especially
    if it isn’t his/her primary language.
  • Go to a user group meeting for another language. See
    what they’re talking about. Share the Perl perspective.
  • Start a blog outside of the hierarchy. If you already
    have a u.p.o journal, keep it, and post to both places.
  • Start a mailing list related to a project of yours. Host it
    somewhere like Google Groups. Don’t worry that “people won’t be able to find
    it,” because the
    list of groups at
    is no model of organization, either. Besides, the only people
    who know to look at are the people that already know
    there are lists at They’re not who we’re after.
  • Start an alternative to
    Perlmonks is a fine site, but it’s long in the tooth, daunting to newbies, and
    frustrating to search. Surely there’s a different way to have an online Perl forum that is better
    in many cases.
  • Work on a project that helps cross-pollinate Perl to the rest of the world. The
    Test Anything Protocol is a good
    example of this.
  • Review a book about Perl. Get it posted to Slashdot or another big tech site.
  • Write about Perl in your blog. Even if you think it’s not interesting to Perl people, that’s fine.
    Someone will want to read it, and you’ll spread that mindshare.
  • When you talk about Perl, don’t be afraid to use the F-word and the L-word: “fun” and “love”.

What do you think?

I’d like to hear your ideas. How can we expand Perl’s
reach? What have you done to help decentralize, diversify
and colonize? How can we keep Perl fun and exciting?

Two comments I don’t need to hear: “This will never work” and “This is a waste of time.”
If that’s what you have to contribute, trust that I’ve taken
your insight into account already, and save yourself some
typing. Alternative courses of action, however, are more
than welcome. Also unnecessary: “None of this would be a problem if not for Perl 6.”


Thanks to a number of people who have helped discuss these ideas with me as I put them together. These include
Pete Krawczyk, Jeffrey Thalhammer, Ricard Signes, Liz Cortell, David Hand, Jesse Vincent and Elliot Shank. I’m sure
I’ve forgotten some, so I apologize if I left you off the list.