Re: My Perl code can be understood by...

I posted "an experienced perl programmer", but I know there are cases where a lot of experienced perl programmers would probably do a double take. I try to code mainly for clarity, but that does not mean I stay away from "complex" techniques just because someone reading it might not know the ins and outs.

I definitely don't hesitate to use closures generating closures that get combined into another closure (for instance) if that's the "best" way to solve the problem. I would hate to solve that kind of problem using only "easy to understand" primitives.

What I mean to say is: some times, problems can only be easily solved (and understood) using relatively "obscure" techniques. If understanding the resulting code relies on the viewer knowing the technique, then that's probably still better than using "simple" techniques in a convoluted way which no-one will be able to understand.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re: My Perl code can be understood by...

Replies are listed 'Best First'.
Re^2: My Perl code can be understood by... by TimButterfield (Monk) on Feb 21, 2008 at 21:31 UTC
I guess a factor in determining intended complexity may be the intended audience. For me, that audience is the non-Perl programmers who will inherit the code when my contract is over. Even though most of what I write is only for my use (that's how I sell it), I leave the code behind when I leave the contract, but with the hopes that someone else will look at it and try to use it. I want to make that use as easy as possible for them. If I were writing a module for CPAN with the intended audience being other Perl developers, the intended complexity level could safely jump way up.	[reply]
Re^3: My Perl code can be understood by... by Joost (Canon) on Feb 21, 2008 at 21:49 UTC
I guess a factor in determining intended complexity may be the intended audience. True. I write most of my perl code these days for a client that wants me get the hard things done, and has the expertise to make sense of the code - at least, once I explain some things :) Most of my CPAN code is probably more straight-forward, just because the problems solved there are easier. On the other hand, if I had to do the kind of stuff I'm getting paid for right now, and also had to cater to not very experienced perl programmers, I would estimate the most efficient use of our time would be for someone (or even me) to give them a really intensive course in advanced perl programming for a month or two. IOW: it's not just the target audience, the problem domain is also important. Some things just can't be solved correctly or "maintainably" with only minimal skills. In those cases, it's better to try to raise the skill level (in whatever way suits the business). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^2: My Perl code can be understood by... by rogueFalcon (Beadle) on Feb 26, 2008 at 04:05 UTC
I think it is ok to use complex perl if you leave a simple comment over it that explains it. Or you could do something I saw in production code for a Fortune 500 company. # DO NOT EDIT THE NEXT LINE... IT WORKS AND THAT IS ALL YOU NEED TO KNOW -- rogueFalcon Why do you people insist on doing things sdrawkcab?	[reply]
Re^3: My Perl code can be understood by... by soapbox (Initiate) on Mar 06, 2008 at 03:54 UTC
Exactly. If I have a really efficient/ugly/erudite line or two of code, I comment above it that `## This is where the magic happens ##` So that (a) I can find it later, and (b) J. Random Neophyte (see gloryhack's post, below) might not screw with that line after turning off the `strict` pragma.	[reply] [d/l]
Re^2: My Perl code can be understood by... by hardburn (Abbot) on Feb 25, 2008 at 19:35 UTC
Agreed. Adding my take to the "intended audience discussion", I expect that my co-workers have a solid grasp of Perl, so I don't shy away from using somewhat more complex Perl idioms. Published papers in mathematics don't explain the summation symbol every time it comes up. If you have a degree in mathematics, you're just expected to understand it already. Likewise, there's no reason to limit yourself to a pidgin dialect of Perl (or any other language) if you're hiring good people. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]