My blog has been getting absolutely flooded with spam recently (c. 4,000+ in the last few days), and I’ve accidentally sent some legit comments to the great spam filter in the sky. The various spam plugins I have caught the vast majority, but that still left a few dozen a day for me to review.

My general policy is to approve all comments, even the obnoxious trolling stuff that follows any mention of a code of conduct. So if you submitted a comment and it didn’t show up, I’m sorry about that.

Just now, I found three legit comments on my last post I’d accidentally spam-bucketed. I’ve now published them, but anything on older posts is long gone.

You’ll notice I’ve added a captcha form to the comments. It’s annoying, but it should slow down the spam, I hope.

If I dropped a comment of yours, feel free to re-submit it, and I will approve it soon.

Also, note that if you log in with an OpenID login (or some other authentication method), your comment is automatically approved.

Recently on the perl5-porters list, there have been several discussions about backwards compatibility and the future of Perl 5.

Jesse’s plan is interesting, and in theory sounds like a good idea. Unfortunately, it brings up some incredibly thorny issues and may not be technically possible. Even if it is possible, it’s likely that lexically preserving backwards compatibility will not work for every proposed feature.

This is an old discussion. The p5p list has been debating backwards compatibility versus evolution for years.

One thing that keeps coming up is that backwards compatibility is important for people who are using their system-installed Perl. If they upgrade from RHEL 5 to 6, they’ll move from Perl 5.8.8 to 5.10.1, and they can’t really avoid that. People who are stuck in this situation are very concerned about backwards compatibility.

I’m not very sympathetic to this view. You have an uncontrolled dependency in your system, and you expect the maintainers of said dependency to essentially keep your code working for free. But my sympathy is irrelevant, because I’m not in charge. I don’t think p5p as w whole (or Jesse as a one) will ever tell these users to just deal with breakage.

All of this leads up to the title of this entry. Why do people use the system Perl? Well, answer number one is that it’s really convenient. Perl is already there, so why not use it?

If we can make it easier to not use the system Perl, maybe we’ll feel a little freer to (very slowly) break backwards compatibility. We already have perlbrew, which is a great tool for development, especially when you need to test code with more than one version of Perl.

I’ve seen some people suggest that somehow perlbrew can replace the system Perl for an application, but I don’t follow that logic. If I’m running an app across thirty servers, do you seriously expect me to run “perlbrew install perl-5.14.2″ on each one? That’s nuts. Package systems were invented for a reason.

Wouldn’t it be cool if we (as a community) provided a set of “official perl.org” packages of Perl. After all, we’re programmers, and this is a task that’s ripe for automation. These packages would install under some location like “/opt/perl-5.14.2″. For each version, we might provide both threaded and non-threaded versions.

Being able to keep a consistent Perl version across system upgrades will prevent the “I upgraded my OS and all my Perl code broke” problem. As a bonus, this might also make it easier for people to upgrade Perl more quickly if they want to. Not being tied to the system Perl is good for people who want stability and people who want to upgrade faster.

Putting this on perl.org and calling it official is an important part of this plan, since many sysadmins are rightly suspicious of random packages found on some random dude’s website.

What do people think?