Never matching: everybody is doing it wrong

Well, not actually wrong, just slow. But the exaggeration makes a punchier headline, you’ll admit.

This comes up when an interface takes a pattern to match things against. Sometimes you have some reason to want this match to always fail, so you want to pass a pattern which will never match. The customary way of doing this is to pass qr/(?!)/. There is a problem with that, though.

I’m not talking here about the fact that if possible, you really don’t want to pass an actual qr object. We’ve already covered that. It was a surprising enough discovery that I’ll take this opportunity to signal-boost that while we’re here, but this article is not about that.

Dodging the Go loop trap

Ted Unangst:

And now we’re trapped. There’s only one friend variable, constantly changing as we go through the loop, with the most likely result one of our friends will get half a dozen messages, while the other five receive nothing, to the annoyance of both groups.

Funny that Perl got this one right when not only many before didn’t but many since also haven’t.

In Go, as Ted says, they may even change the language to fix it; in Javascript, they already have.

“Let Maintainers Be Maintainers”

Graydon Hoare:

[…] Corporate-employed FOSS maintainers working at a firm with these [very common] “growth and novelty” incentives [… are] in a position where their job performance is very likely to be evaluated in terms of visible growth and novelty (it might be dressed up in more abstract terms like “real-world impact” or “visibility” but it still means the same thing) even though that is exactly the wrong thing for the health of the project they’re maintaining.

I’m excerpting the gist of his article here but actually I suggest reading all of it. It’s not very long but gives flesh to this skeleton argument.

It doesn’t help that what he is talking about isn’t limited to employed maintainers; profit is not the only growth incentive structure that can lead to this novelty mindset, so this can exist entirely outside commercial context.

Template Toolkit’s DEFAULT is not too useful

Quoth the fine manual for Template Toolkit:

The DEFAULT directive is similar to SET but only updates variables that are currently undefined or have no "true" value (in the Perl sense).

Nice. Basically, where SET is like the = operator in Perl, DEFAULT is like the ||= operator. Quite useful! If it were, that is. Because the analogy is only superficially true.

How to prevent an infinite loop

This loop (assuming you have an /etc/passwd and may read it) runs forever:

while () {
  open my $fh, '<:unix', '/etc/passwd' or die $!;
}

This loop terminates:

while () {
  open my $fh, '<', '/etc/passwd' or die $!;
  binmode $fh, ':unix';
}

Note that you will have to live with some extraneous output:
Too many open files at t.pl line 2.

Btw, you can make it loop forever again this way:

require POSIX;
while () {
  open my $fh, '<', '/etc/passwd' or die $!;
  binmode $fh, ':unix';
  POSIX::close fileno $fh;
}