fuzzy notepad

Tagged: perl

[blog] Perls of Wisdom

Ha, ha! A hilarious and original pun.

I’ve had several conversations now about Perl 5’s level of deadness and Perl 6’s level of disastrousness. So here is a followup, which surely won’t get as much attention because it’s not as potentially inflammatory.

[blog] Perl 5 is dead, Perl 6 is a disaster

ADDENDUM Jul 3: I don’t know how, but this got a bit of attention. chromatic has compared me to Barbie, szabgab wondered if I’m a troll, and several people suggested that I’m trying to justify leaving Perl for Python.

Remember, I’m a long-time Perl developer. I’m the ideal target audience: someone who already uses your product. In recent years I’ve become disillusioned with Perl, having watched several similar languages eclipse it. I’m surely not unique in feeling this way.

So why is the reaction to downplay what I said, rather than to tell me why I should want to use Perl, or to make Perl something I’d want to use again? chromatic suggests I just haven’t done my research. But if I don’t know why I should use your product, that’s your problem.

I did have an interesting discussion in #perl6 about this, which led to an insight. Perl 6 is unusual, possibly even unique, in having a large spec written before an implementation. I think some of its communication issues stem from this: outsiders see a spec and take it to mean an implementation isn’t “1.0” until it reasonably matches the spec. Implementors, on the other hand, regard the spec as merely a direction to move in. So outsiders are waiting for a blessed 1.0 release, and think the insiders sound slow and stuffy for not giving them one. Insiders are working on an organic thing, and think outsiders are obnoxious and impatient for wanting something absurd.

Explaining the discrepancy to people who want to use Perl 6 is technically correct, but not practically helpful. It may be better to carve up the Perl 6 spec into discrete and useful milestones, with some big ol’ colored chart detailing what’s supported by which implementations. (I actually can’t tell right now what Rakudo supports and doesn’t. rakudo.org is just a blog.)

I feel the need to respond to this series of blog posts about Perl 6, whether it should be renamed, and what the implications are for Perl 5.

I’m a Perl person. I’ve been using Perl since I was eleven. I got paid to write Perl for the past four-and-a-bit years. Let’s pretend I’m qualified to say anything here.

A confession: I wince when I call myself a “Perl person”. I think it makes me sound crusty and obsolete. Because Perl 5 is crusty and obsolete.

Who is using Perl for new software? Besides a couple grumpy nerds I know personally, I haven’t the slightest clue—and I sort of pay attention to Perl. I have zero interest in Java or .NET, but I’m still dimly aware that things are built with them. I can’t tell you what Perl is actually being used for besides all the cool new modules on CPAN designed to make Perl suck less.

What has happened with Perl since 5.8? 5.10 brought us the smart-match operator, the defined-or operator, and given/when. 5.12 brought us… well, nothing. 5.14 allows push $arrayref. And that’s all! There are a lot of bullet points in the changelogs, yes, but almost all of them are arcane things like “the … operator” or “$, flexibility”. These are improvements, technically, but they’re not anything that’s going to make me jump for Perl 5 for my next project; they’re just going to make existing Perl 5 work hurt less. (And even that isn’t automatically true; my previous job is at least a year into an effort to move from Perl 5.8 to Perl 5.10. Note that Perl 5.10 is now so old it’s unsupported.)

The ecosystem is moving, sure, but if you buy into that then you’re still stuck with the language. Worse, if you use any other Perl software, you probably have to work with an object system you don’t use, an exception model you don’t use, some kind of bundling thing you don’t use, and on it goes.

I don’t see anyone talk about Perl except people who are really into Perl already. It doesn’t attract new blood; I certainly wouldn’t point anyone towards it. If it were a human language, we’d certainly call it dead, or at least moribund.

[blog] Perl Worst Practices

I hate to rank my own skill at anything, but if you forced me to, I’d say I’m pretty good at Perl. I get paid for it, at the very least. I’ve been around it a long time, and I know it well enough to tell you in intricate detail why I now use Python, instead.

But this is not that post. This post is about a particular wart of Perl: that it has a lot of warts. Large chunks of Perl are antequated, bug-prone, or outright obsolete. The trouble is that there are no warnings in the interpreter or documentation for many of these things, so a newcomer—or even an old-timer—won’t know to avoid such pitfalls until told by someone else.

Such secret knowledge has been documented in bits and pieces in many places, but none of them are complete, and some of them are similarly antequated. So, here’s my list.