Here’s a quick checklist to help those of you writing Perl to determine if you’re capable of writing Perl well:

Do you do this?

Do you do that?

…

Do you use Moose or another abstraction mechanism from the CPAN?

…

Okay you got me. I’m quoting out of context. Here’s chromatic again:

You don’t have to answer all of those questions in the correct way to write good and maintainable Perl, but if you answer most of those questions in the wrong way, of course you’ll write bad code.

I don’t know what these 18 items actually indicate, how well integrated you are with the perlective perhaps or how much you code like chromatic, but for sure only 6 or 7 at best are decent indicators of ability to write Perl well. I answered 9 of them in the wrong way and I’m certainly not rushing to correct the deficiency.

1. Having said that, I have used Moose before, and for the right project, I would use it again.

Advertisements

Share this:

Like this:

Related

11 Responses

I think chromatic is generally just trying to provoke people to think about how they go about their Perl. Doesn’t read like a list of commandants to me as things to think about from the perspective of writing maintainable code.

You say he puts forward using Moose (or another abstraction mechanism .. ) as a measure of *ability*. As I read it he’s saying something more like “using Moose (or blah) can help make your code easier to maintain”. And it can! Doesn’t mean it’s the right solution for any problem, but that’s not what the post seems to be saying [to me].

I’ve only been programming perl for sixteen years and writing perl “in the large” for ten or so. I thoroughly enjoy the power and efficiency that it has given me and my teams to complete the projects undertaken.

That said, I feel that we’re moving too far away from the roots of perl. Back in the day, perl was lean mixture of C, sh, and the set of Unix command line utilities mixed together with a rich set of data structures and hassle-free memory management. It was easy to build rich applications, services, and tools in a very clean manner. To quote, it kept easy things easy, and made hard things possible.

With the introduction of Catalyst, DBIx, Moose, abstract SQL, we’ve entered a new era of meta-programming. Instead of writing in perl idioms, we now write “in Catalyst” or “in Moose”.

While making the written code more compact and expressive, it drags along a huge amount of bloat and side-effects. It’s not uncommon to see simple servers based on Catalyst ballooning into the hundreds of megabytes, or FSM forbid, gigs of memory.

As bad as the memory issues are, what more distasteful is the intrusion of action at a distance. For newer perl programmers, they may incur huge performance hits with seemingly innocuous code. For instance, what looks similar to a hash reference is really a database query and fetch. As another example, Moose is rife with before / after / around method invocations for roles or with triggered actions. Sure… one can always dig through all of the source to find all of this out, but with the new era of meta-programming without such digging it isn’t obvious what the true costs of seemingly simple statements are.

I enjoy using all of the above packages, but I have to say that I’m getting tired of cleaning up code written by others who didn’t understand exactly what they were doing and what costs they were paying.

… but if you’re not testing your code, if you’re not taking advantage of the CPAN, if you’re not using source control, if you’re not documenting your code, if you don’t know how to use perldoc, and if you’re not at least peripherally familiar with the Perl community, there’s a very good chance you’re not writing good Perl.

None of those are guarantees you’re writing good Perl, but they’re strong indicators based on my experiences working with poorly written Perl.

Ignoring the particular modules chromatic links to, if you’re not regularly doing half of the things on that list in some way, then I wouldn’t say that your Perl sucks, but I sure wouldn’t want to maintain it.

Sure — you don’t have to use “Perl community” standards for style or layout, but I’d hope that you have some consistent standards of your own that you follow, and so on. Maybe you don’t use Moose, but I hope you’re not hand-rolling an object system for every piece of code.

(Though I really don’t care if you know about a local Perl Mongers group or not. If you’re on Iron Man, that’s a good sign that you’re not working in a vacuum.)

There are always exceptions to guidelines — but there should be good reasons. For example, I do a lot of core toolchain maintenance. I can’t use Moose. I can’t rely on Modern Perl features. I can’t use non-core modules. It’s not fun to write Perl that way. And I’d worry if someone chose to write their code that way all the time.

@draxil – I re-read chromatic’s post. To me the phrase “if you answer most of those questions in the wrong way, of course you’ll write bad code.” clearly states that if you’re not getting 9 or more of those things right, it is guaranteed your code will be bad. He seems to have softened that stance below.

Okay, I picked on Moose specifically here (and it is something I think I should make more use of), but I could have taken a lot of the other items to make my point.

@Mark – Wow, 16 years. That is longer than me!

I know exactly where you’re coming from. A lot of these big frameworks make it harder to see exactly what is going on. But I’m sure people have used the same argument to resist going from assembler to C, or C to Perl (or Perl to Moose). Higher levels of abstraction is the future, whether we like it or not.

@chromatic – I agree with you, most of the things you list in this comment are fair indicators, but if you’re not doing any of them, your code might still be good which is what you say here, but not in your original post.

@dagolden – great comment. I need to expand on this futher, but I think you’ve clarified for me better what I was thinking when I wrote this post in the first place.

Is it really possible to make statements about maintainablity without empirical evidence? How do you know your code is maintainable unless is has been through many modifications at the hands of many different developers at many different stages of experience and understanding?

Compact syntax cannot guarantee maintainability. Look at something like ‘J’ or APL. As concise as could be but you still have to understand the data model and divine the authors intent to be able to maintain the code.

OO cannot guarantee maintainability. Proof – refactoring.

Adopt whichever philosophical position you like but if you believe it is the one true way you are using the wrong language.

Not a bad checklist, chromatic. I especially liked the “hateful melange of barely-working confusion” turn of phrase 🙂 (that’s sort of how I write Lisp!) (although I’m getting better)

I think Moose is fantastic, awesome, intuitive, helpful — except for one thing: its awful, unforgivable speed penalty. When writing GUI or CGI programs, I simply cannot wait eight to twelve seconds for a program to start. Ergo, none of my local library modules use Moose.

It’s like if adding airbags and GPS to passenger vehicles caused them to lose acceleration and gas mileage, so that your family sedan now does 0-60 in 25 seconds.

You’d think maybe I could use Moose for daemons, database updaters, and other non-UI programs. And maybe I will. But that would mean that any library modules I write for such programs wouldn’t be reusable in user-facing code.

I will continue to write modern, encapsulated, reusable, testable Perl programs and libraries, but I will not trade my sport utility vehicle for a golf cart. I hope that Moose’s compile-time speed penalty will be overcome someday; for now, I’m sticking to inside-out objects. They’re tedious, but they work.