Month: May 2008

Colons invalidate BEGIN and END blocks

May 8, 2008 Perl 5 4 comments

Take a look at this block of code and see if you can guess what it does.

END: {
print "Exiting...n";
}
print "s = $sn";
BEGIN: {
$s = 'Hello from the BEGIN phase';
}

You’d expect that the BEGIN block sets $s at compile time, so then that gets printed in the print statement, and then the END block executes at the end of the program. Yes, it would, except that those aren’t BEGIN & END blocks. They’re normal blocks that just happen to be named BEGIN and END.

Credit Randy Lauen for bringing this to my attention. Today at my day job he found a horrifying code construct, one that I’d been using (incorrectly) for quite some time now. You see, these two blocks are not the same:

BEGIN {
# Here's some code that gets executed at compile time
}
BEGIN: {
# This code gets executed at run time, because the colon
# after BEGIN means it's just a plain old label
}

Randy had been tracking down a bug for over an hour and couldn’t figure out why his variables weren’t getting set at compile time. Turns out the BEGIN block he was modifying was actually a not-special-at-all BEGIN: block. And he found 40+ instances of the spurious colon in the codebase. Of course, INIT, CHECK, UNITCHECK and END are also rendered non-special by a colon as well.

Most of the time, this is invisible. People tend to put their BEGIN blocks at the top of the program, so the difference between a real BEGIN block and a block that happens to be named BEGIN are not noticed. Still, it’s a a bug waiting to happen.
Sounds like an ideal check for Perl::Critic policy, no? Mike O’Regan jumped to it, and submitted a patch to Perl::Critic, so those of you using Perl::Critic (and if you’re not, you should be) can get warned of using colons on those specially-named blocks once a new version is released, shortly I hope.

I’m not the only one to have been doing this. Google Code Search turns up
over 100 instances, including some in the core Perl tests (heck, maybe from me!), as well as mailman and POE.

Check your codebases. If you’re using ack, it’s just:

$ ack --perl '^(BEGIN|END|INIT|CHECK|UNITCHECK):s*{'

Have you fallen prey to this? Let me know.

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 perl.org. 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 lists.perl.org 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 groups.google.com is
trivial, for example.

Is rt.cpan.org 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
there.

Is use.perl.org the
best place to host your blog? Maybe you should post
somewhere else. Certainly that was the case with me. I found that use.perl.org 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 use.perl.org, 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 use.perl.org?”

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
source
, and it’s additive, not subtractive.
Template Toolkit need not take away
from Mason. Perlbuzz need not take away from
use.perl.org. 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
which
mentioned
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:

  • perl.org, which is a good base.
  • perl.com, O’Reilly’s Perl page, also a good base.
  • The wikipedia entry for Perl, which certainly isn’t much help for a beginner
  • www.cpan.org, 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 perl.org 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 use.perl.org 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 lists.perl.org
    is no model of organization, either. Besides, the only people
    who know to look at lists.perl.org are the people that already know
    there are lists at lists.perl.org. They’re not who we’re after.
  • Start an alternative to perlmonks.org.
    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.”

Acknowledgements

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.

Big improvements in mini-CPAN tools

May 5, 2008 CPAN No comments

The minicpan tool in CPAN::Mini lets you keep a copy of the most recent revisions of each module on the CPAN. Having a mini-CPAN is a great tool for anyone with a laptop, or who wants to look at the CPAN as a whole, or who wants to create a mini-mirror of CPAN to support a large installation without having to hit the net for each module install. An entire mini-CPAN only takes up about a gigabyte of drive space.

Ricardo Signes, CPAN::Mini’s author, wrote to tell me:

CPAN::Mini 0.569 includes an obvious optimization: instead of
reconnecting to your remote mirror for every file that might need updating,
`minicpan` will now keep one HTTP connection open for the entire update. While
I can’t give numbers that reflect the most common cases of usage, a run that
checks every file and finds no updates goes, on my laptop, from about two
minutes to about twenty seconds — about 1/6 the time! It also puts less load on the remote server, making it a friendlier way to keep a local mirror.

Also, Adam Kennedy has just posted about a major upgrade to CPAN::Mini::Extract, a tool to make it easy to get individual files from tarballs, that speeds up extraction:

By shifting expansion to a one-shot extraction to a temp file, and then opening tarballs once from the temp file, I managed to get a two to three times speed up for file extraction. Combined with CPAN::Mini pipelining, this makes CPAN::Mini::Extract massively faster (a 200%-300% overall speed up).

Post-Its from BarCampPortland

May 4, 2008 Uncategorized 3 comments

Selena Deckelmann has come back from BarCampPortland with copies of every Post-It on the topic selection board. The topic selection board at an unconference like a BarCamp is where people write on a Post-It a topic they’d like to see presented, and put it on a board for all to see. Whichever topics people vote for are the topics that are presented.

Scanning through the photoset on Flickr is fascinating, as these often are. Topics range from Pirates Paying Artists to WordPress as CMS to How to lie with statistics to Should we replace Congress with a wiki?

Also fascinating to see how widespread Twitter has become, with half the Post-Its leaving @usernames as contact information.

Makes me want to start up a Bar Camp Chicago. And move to Portland.

How fresh is the CPAN?

May 3, 2008 CPAN No comments

According to statistics by LaPerla, the freshest 25% of CPAN is newer than how old?

  1. 3.8 weeks
  2. 38 days
  3. 3.8 months
  4. 38 months
  5. 3.8 years

TPF wants your input on Q2 grant proposals

May 2, 2008 Perl Foundation 1 comment

In a new move for TPF, the grans committee is soliciting community input on the proposals for this quarter. Alberto Simões writes…

To this post follows a set of posts with proposals received by the
Perl Foundation grants committee during the second call for grant
proposals for 2008. Although not usual, the rules of the TPF GC are
changing and we hope to make this a rule. Proposals are accepted
during one month and after that period, they are posted for public
discussion on the Internet. This is important to make GC more aware
of the community interest on the project, and to help opening the
grants attribution process.

During the month of April we received the following grant
proposals:

Please take some time on reading the proposals carefully and give
some feedback on the relevance of the proposals.


The article doesn’t say where or how to give feedback, or by when. I’d start at the original posting on the TPF blog.