Comments on: The oxymoron of perl best practices http://codefork.com/blog/index.php/2008/05/18/the-oxymoron-of-perl-best-practices/ branching out Fri, 03 Feb 2012 16:26:59 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: jeff http://codefork.com/blog/index.php/2008/05/18/the-oxymoron-of-perl-best-practices/comment-page-1/#comment-1201 jeff Tue, 20 May 2008 23:29:54 +0000 http://codefork.com/blog/?p=66#comment-1201 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. 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.

]]> By: chromatic http://codefork.com/blog/index.php/2008/05/18/the-oxymoron-of-perl-best-practices/comment-page-1/#comment-1190 chromatic Tue, 20 May 2008 01:07:22 +0000 http://codefork.com/blog/?p=66#comment-1190 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. 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.

]]> By: jeff http://codefork.com/blog/index.php/2008/05/18/the-oxymoron-of-perl-best-practices/comment-page-1/#comment-1189 jeff Mon, 19 May 2008 23:05:04 +0000 http://codefork.com/blog/?p=66#comment-1189 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. 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.

]]> By: chromatic http://codefork.com/blog/index.php/2008/05/18/the-oxymoron-of-perl-best-practices/comment-page-1/#comment-1187 chromatic Mon, 19 May 2008 20:23:36 +0000 http://codefork.com/blog/?p=66#comment-1187 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. 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.

]]>