Lately, I’ve been pondering my relationship with Perl. Every programmer has a different relationship with their language-of-choice, and it impacts how they approach many different aspects of coding, what features they like and which ones they hate, what they clamor for and what they disparage. And these choices are always going to be challenged by our friends, our coworkers, and our open-source collaborators. Which is a good thing, for the most part: being challenged is what keeps us honest, keeps us fresh. Without constant challenge, we can lapse into dogma and cargo cult coding. But we can’t properly defend our positions—can’t explain why we feel the way we do about certain things—unless we take the time to understand our relationship with our language.
So this is part 1 of an X-part series (we’ll just have to see how long it takes me to work through it all). Primarily I want to explore this for my own self-awareness, but I hope it will be interesting to others as well. And perhaps it will make some of my other blog posts make sense.
I begin at the beginning: how I came to Perl.
So, I finally got around to reading the introduction that dams put together for p5-mop. (If you don’t know what that is, it’s the effort to get a MOP, or “Meta-Object Protocol,” into the Perl 5 core. This would not be adding Moose to Perl 5, but it would be adding something that would make Moose—or any competitors—a lot more feasible, efficient, and user-friendly.) I’ve been following Stevan’s blog posts about the ongoing work, but a lot of times those are more about certain implementation details. They’re very useful, and very interesting, and I hope he continues to do them, but sometimes they can be a bit forest-for-the-trees, if you see what I mean. I think it was great of dams to give us a 6,000 foot view, as it were.
Now, I haven’t had the opportunity to try out p5-mop myself yet, although I certainly hope to sometime soon. So, as you read my thoughts about the MOP features that dams describes for us, remember that this is a more of a first-impression reaction and less of a practical response after use. Still, I’ve been thinking about these sorts of things for many years now, so these are not off-the-cuff comments either. It’s definitely a section-by-section reply to dams’ post, though, so make sure you’ve read that first.
Ready? Excellent. Here’s my impressions of the P5 MOP so far.
As you may know, Perl 5.14 (and up) will allow you to use references for container functions (by which they mean functions such as
keys that operate directly on arrays or hashes). I’d never thought much about this feature, except to think that it was, in general, a nice way to save three keystrokes on constructs such as (to steal an example from perldelta):
Now, saving three keystrokes doesn’t mean much if it makes your code harder to read. But, in this case
is actually easier
to read, so I call that a win-win.
This feature came up at work recently, and a couple of people whose opinions I greatly respect disparaged its use. Curious, I asked why. They pointed me at three blog posts that came out at the time the feature was first announced: two from chromatic, and one from brian d foy (again, people whose opinions I greatly respect). I hadn’t noticed these (or, if I had, I’d forgotten them), so I took some time to read through the articles and their comments.
However, at the end of it all, despite strong agreement amongst at least 5 fellow programmers whose opinions, as I say, I give strong weight to, I’m still going to disagree with them here. I don’t see anything wrong with the auto-dereferencing, or at least not enough wrong to warrant a policy of full-stop banning it from my code.
Some months ago, I read an article by someone who teaches Perl to Java programmers. In it, the author wonders a bit about some of Perl’s features which seem counterintuitive to those coming from a Java background. As you might expect, one of those features is its typing. He says:
For example: stern, protective type safety is not only missing from Perl but actually not even considered particularly desirable. Perl is relaxed. The reaction from students is, naturally: “Isn’t this a huge obstacle to getting anything done?” Obviously the answer is “No”, but even after all the Perl I’ve written I sometimes wonder why not. Is it really just the fact that it takes less time to type method signatures and variable declarations?
At the time I read this, I thought to myself, “Hey, I know the answer to that!” But I just jotted it down as a potential blog topic and let it percolate for a bit. Many folks reading this will also know the answer, but it’s an interesting topic, and I’m sure someone will get something out of it.