I’ve been browsing Damien Conway’s excellent book, Perl Best Practices. His description of “best practices” in Chapter 1 is quite good, bestowing meaning upon an otherwise empty buzzword for marketing departments:
Rules, conventions, standards, and practices help programmers communicate and coordinate with one another. They provide a uniform and predictable framework for thinking about problems, and a common language for expressing solutions. This is especially critical in Perl, where the language itself is deliberately designed to offer many ways to accomplish the same task, and consequently supports many incompatible dialects in which to express any solution.
Simply put, best practices are the recognizably tried-and-true. The key word is recognizable: others should be able to identify the problem being solved as well as the specific type of solution. In a way, it’s redundant to speak of best practices when talking about the programming: unless no one will ever see your code, the foremost consideration of the programmer should be, Can other people understand what I’ve done easily and quickly, and also make changes and improvements easily and quickly?
That question is really at the heart of coding as a craft of logical elegance, I feel. Giving it due care and consideration is what distinguishes artisans from those who just “get it done” (they always seem to run into perpetual headaches down the line).
I find the philosophy of perl to be highly antithetical to the sort of shared understanding and communication described above. The motto of “there’s more than one way to do it” is self-serving and individualistic, to the detriment of maintainability. Perl seems to foster stubbornness and isolation: I’ll do things MY preferred way, and you do it YOURS. The codebase quickly devolves into baffling inconsistency. Of course, skilled perl programmers pride themselves on being able to know all the different ways of doing something, but at that point, the strength of the language isn’t the issue anymore; the ego of the coder is.
Anyway, back to Conway’s book. What’s interesting, but perhaps not surprising, is the number of “don’t do X” recommendations it makes. Leaving off parentheses on subroutine calls? Convenient, but ugly and confusing when a bunch are these are combined, so don’t do it. Tricks with dereferencing syntax? Save everyone headaches and stick to arrows. Pseudohashes? Stay away from them. Indirect object syntax? Potentially conflicts with subroutine names, so don’t use it.
Take away all the crazy tricks that perl devotees love, and what’s left? The only truly great thing about perl is its regular expression integration and text processing. It’s amazing stuff. But otherwise, perl doesn’t particularly excel at much else.
Which is not to say large complex projects in perl are impossible. The University of Washington’s Catalyst tools use a custom web framework written in perl, which they’ve open sourced. I only cite that particular example because I’ve used some of the tools and I know they’re nicely done. So sure, it’s possible, but it takes a lot of deliberate restraint and discipline, more so than with other languages and tools that are oriented towards helping you get your job done.
Seems to me that if you must willfully refrain from using what a language offers, and constantly fight the temptation to write mangled code that costs time, money, and frustration for others to decipher, perl isn’t a particularly strong choice. In the case of perl, best practices aren’t a way to get the most out of the language; they’re a stopgap measure to stave off its natural tendency towards chaos.
No, Perl’s malleability lets you and your organization choose the most expressive, most maintainable, most performant, most interesting, most effective, and/or most (your adjective here) code for your own purposes.
If you can’t do that, you need to improve your understanding of the language.
If your fellow programmers can’t do that, your problem is not language choice.
I thought that was pretty funny, until I glimpsed your webpage and realized you probably weren’t joking.
My post was based on specific observations about Conway’s book. Your response just seems dogmatic, without any details to back it up. So I’m afraid I don’t really have anything to say to that.
Hey, I’ve been on plenty of projects which have had little trouble writing maintainable Perl. I take that to mean that writing maintainable Perl is possible. Now we used coding standards, extensive testing, code reviews, good source code management, and all of the other tools we would have used with any other language, and things worked out fine for us.
If you have specific observations about specific projects you’ve worked on where your team performed all of those essential practices and still failed to write maintainable Perl, I’m interested to hear them. You used the word “seem” an awful lot in this post, however.
I completely believe that if you have an awesome bunch of perl gurus who are disciplined enough to do the things you mentioned, maintainability is not a problem. My point wasn’t that maintainability is impossible–I never said that. I was pointing out that you have to restrain yourself, more so than with other languages, in order to get maintainability. That’s the dark underside of “there’s more than one way to do it.”
When I compare perl with python or Java (other languages I know fairly well), the lack of syntactic tricks and shortcuts is actually a blessing. (To be sure, those languages have their weaknesses too; I’m not saying they’re better than perl as a whole.)
I don’t have specific observations just yet: the one perl project I’m working on is beginning to get big enough that I looked into Damien Conway’s book for tips. It’s been tremendously helpful. It doesn’t help that the other coder I work with is a perl nut who takes great joy in writing convoluted code which he often can’t debug or decipher himself, leading to some pretty strange stuff in order to get things to work, and which I have to clean up later. He’s no perl guru, but then very few of us mere mortals are. That’s my beef with perl maintainability.