This is part 4 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at code legibility.
Last week I talked about why Moose is important to my journey as a Perl programmer, and where I feel that it could be even better. I concluded that it all comes back to code legibility.
Now, there’s a simple answer as to why I want so desperately for my code to be legible. I already referenced a blog post by one of those two bloggers I love to hate, Joel Spolsky.1 In that post, Joel notes (in big, bold letters): “It’s harder to read code than to write it.” And this is one of those places where Spolsky is dead on. It is harder to read code than to write it ... but the reason for that is that computer languages are designed to be written, not to be read.2 Computer languages are instructional—they consist of a series of instructions to the computer—and everyone knows that it’s easier to give instructions than to follow them. Well, easier for humans to give instructions; computers seem to have an easier time following them.3 When we read code, we’re not even trying to interpret someone else’s instructions so that we can follow them. We’re trying to interpret someone else’s instructions so that we can figure out what a third someone—the computer, in this case—did when it followed them, so that we can figure out if it was done properly or not. If you think about it, that’s quite a difficult task.
So anything I can do to make that task easier, I do. Even if I have to go to some trouble to do it.
This is part 3 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at the joys—and the frustrations—of Moose.
Last week I talked about why I believe that at least having the choice to program object-orientedly (without it being a huge pain in the ass) is vital to me as a programmer. In the comments I also touched briefly on why I think OOP in Perl, pre-Moose, is a huge pain in the ass, but honestly I didn’t put much effort into making that point. In my experience with other programmers (both in real life and online), the majority of them—perhaps 75%, at a rough guess—already agree with that and don’t need any convincing from me. And the rest are most likely not going to be convinced no matter what I say. Besides, this isn’t really a persuasive essay. I’m not trying to change anyone’s mind. It’s the story of my relationship with Perl. And I, like most other coders I know, have placed some value in OOP, at least in some circumstances. Also, I, like most other coders I know, felt that doing OOP in Perl was a bit of a chore.
Then we got Moose.
This is part 2 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week continues the topic of why a former C++ programmer might retain some nostalgia after moving to Perl: objects.
Last week I talked about my discovery of object-oriented programming and how it led me to become a C++ programmer. As I described, it really was an epiphany: we would say back then that I suffered a paradigm shift, although that’s become somewhat cliché these days.1 From this you might gather that I’m an object zealot, but I’m not.
Here’s my thinking on OOP.
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.