Paul Cory has contributed what I hope is the first of many guest editorials on Perlbuzz. — Andy
Recently, Andy Lester wrote about the zombie question that haunts
is Perl 6? One of the questions he posed was:
“And to everyone else, who is willing to help in this task, to help keep the fires of anticipation burning in the public?”
My advice would be to not keep the fires of anticipation burning in the public. For the good of the language, Perl 6 needs to be deemphasized in public, and, in addition, renamed.
How Keeping Perl 6 Front-of-Mind Hurts
1) It emphasizes the “inadequacies” of Perl 5.
2) It makes the development community look unorganized, at best. People comparing at the development pace of Python, Ruby and PHP to Perl 6 are likely to come to harsher conclusions about the community’s focus, viability and competence, based on Perl 6’s seven-year, and counting, gestation period.
3) It creates uncertainty: what happens to Perl 5 when Perl 6 finally drops? How much new stuff will I have to learn? How will my existing code work, or not, if I upgrade? Why should I invest time in Perl 5 if Perl 6 is just around the corner, and will be far superior?
4) It creates frustration inside the community. Perl 6 has been “coming soon” for 7.5 years now. It’s hard to remain excited about something that long with no payoff.
5) The story is confusing: Pugs? Haskell? Parrot? Two development tracks? I thought this was about Perl? Yes, I have an idea of what those things are, but most folks outside the community (and a fair few inside, I’d wager) don’t know, don’t care, and shouldn’t have to.
Basically, the more we push Perl 6, the more we Osborne ourselves.
How Keeping Perl 6 Front of Mind Helps
I got nothing. Honestly, I can’t think of a single positive for trying to keep public anticipation burning.
How Deemphasizing Perl 6/Changing its Name Helps
1) Allows us to focus on the strengths and successes of Perl 5.
2) Allows us to tell the development and improvement success story of Perl 5, which is as good as that of any other scripting language.
3) Removes uncertainty that can be used against Perl when companies and developers make decisions about which language to use.
4) Finally, by changing Perl 6’s name, to something like PerlNG or PerlFG, we can get away from the “It’s just a 1 point upgrade,” problem and have a basis for which to talk about it as a “research project.” That allows us to both avoid talking about delivery dates, and allows to talk about how cool stuff from PerlNG is finding its way back into Perl 5.
5) Gets us away from all the negatives listed above.
How Deemphasizing Perl 6/Changing its Name Hurts
1) It might be harder to get folks to work on PerlNG if it’s not “just around the corner.” I happen to think that can be overcome with inside-the-community marketing.
For the record, I greatly appreciate all the work that folks have put into Perl 5 and Perl 6. Nothing here should be taken as a criticism of how the actual development gets done, nor of the talent or the commitment of the developers.
I don’t question the desirability of Perl 6 either. I can see how, when it’s finally finished, it will be an improvement over any language available.
However, from a Communications standpoint, it’s obvious that there are significant problems in communicating about perl to the world at large.
Perl 6 has been a Public Relations disaster, one that has made it harder to attract developers, other contributors, users and companies.
Again, from a Communications/PR standpoint, our goal should be to stop shooting ourselves. And that means taking the public focus off Perl 6 as much as possible.
Paul Cory is the Webmaster for the Wake County Public School System in
Raleigh, North Carolina. He started using Perl nine years ago to
automate some particularly tedious Website updates, and has progressed
to the point where Perl glues the entire system website together.