Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
Think about Loose Coupling
 
PerlMonks  

Re: "Baby" Perl versus "Bad" Perl

by Anonymous Monk
on Dec 05, 2005 at 19:31 UTC ( #514212=note: print w/ replies, xml ) Need Help??


in reply to "Baby" Perl versus "Bad" Perl

Well, "Baby" Perl is perl that's written with simple (excessively simple) constructs. It's flaws are created largely out of ignorance.

"Bad" Perl is perl that is flawed in other ways; such as using fundamentally flawed algorithms; advanced coding techniques used for obfuscation purposes in production code; parsers and lexers built into the code to handle a configuration file that holds only constants; and so forth.

In other words, truely bad Perl is perl that would remain bad even if refactored, or translated into a completely different language.

"Baby Perl" is just inexperience with Perl idioms; which isn't always a bad thing. I often try to avoid using complicated features of perl when simple features will do the job; the less I have to *think* about the code to make sure that my clever tricks really work; the easier the code is to maintain. I'd rather have three lines I can read than one I can't; but obviously excessively verbose code imposes it's own inherent complexity, so there's a balance to be struck. I try to code to the level of the person who I anticipate will maintain the code. In some respect, my Perl resembles "Baby Perl" by design. I only use features that a novice might misunderstand when it would make the code awkward not to do so, and whenever I do something "clever", I know I'll pay for it later. Six months from now, I'll probably have to explain what I did to a confused maintainer, and while comments help, I'll still have a mini-training excercise on my hands. I do like teaching, but my company is losing money when I give out free training like that, because my time and my co-worker's time could be spent elsewhere more profitably.

So, to recap: "Baby Perl" arises out of ignorance, and is solveable. "Bad Perl" arises out of incompetance or malice, and is not. Having dealt with too much bad Perl lately (6,000 line loops with eight levels of indentation, formatted inconsistantly with typically only 2 column indentation is... bad practice. Exporting local package variables into every single namespace instead of using a global variable in the first place is ... bad design. Making your fundamental data structures tied hashes with a rat's nest of internal function calls, with wierd side effects is... bad design. Localizing various sections of a data structure to modify the impact of key function calls is bad design. Putting your date/time handling code into a custom Perl-XS module that's (a) buggy, and (b) incompatible with the perl version in production is bad practice, given the tonnes of date handling routines on CPAN.

Failing to "use strict" because you don't know it's there in a ten line perl script is not so bad. Failing to use strict because you're too lazy to use it in a 10,000 line perl project is bad.

Just my $0.02

--
Ytrew Q. Uiop

P.S.: On martial arts: I disagree with your premise that Martial artists would claim that the arts are about learning that you don't need to fight. Martial arts teach awareness of how you need to fight; including what degree of force is required or appropriate to a given situation. If a little child attacks an adult, we don't try to kill it; we just stop the attack, and scold the child.

If an adult attacks a martial arts master with a credible threat, the adult will find that the master will defend him/herself using such violence as is appropriate to the situation. The only difference between "ordinary people" and "enlightened" martial arts masters is that a martial arts master has less risk of being hurt by a given attack due to superior skill; and can risk being more lenient while remaining safe.

If the martial arts master was a true pacificfist, (s)he wouldn't have needed to learn how to kill and maim in the first place, before advocating "peace". Remember that the word "martial" means "warlike", and that "martial arts" were the killing tactics used on the battlefields in Asia. Traditions on how to kill with a sword, spear, staff, or with one's bare hands are very insightful, but they were never peaceful in origin or intent. It's easy to romanticize a violent tradition (like "knights in shining armour"), but a history of violence remains violent.


Comment on Re: "Baby" Perl versus "Bad" Perl
Re^2: "Baby" Perl versus "Bad" Perl
by tilly (Archbishop) on Dec 06, 2005 at 05:06 UTC
    I really like everything you have to say with one major exception.

    It is both possible and common for bad Perl to arise out of fixable incompetence. In which case you fix the cause of the incompetence, and you stop seeing so much bad Perl. For instance the person programming may not have a programming background, and so has never learned the value of good variable names, when to use functions, and so on. Or the person has just been exposed to a whole lot of neat things and wants to use them all at once. A little more experience and this enthusiasm likely will get tempered to more manageable levels. And so on.

    I am not saying that every producer of bad code is educable. But enough are that it is worth at least making the attempt.

      It is both possible and common for bad Perl to arise out of fixable incompetence. In which case you fix the cause of the incompetence, and you stop seeing so much bad Perl.

      Hmm... how does "fixable incompetence" differ from simple ignorance? Incomptentence, to me, implies an inability or outright refusal to learn competent behaviour.

      For instance the person programming may not have a programming background, and so has never learned the value of good variable names, when to use functions, and so on.

      In which case, the incompetence lies as much with HR as with the so called "progammer". Only hire people who can do the job you require of them; if you need to train them on the job, budget the time and resources for it!

      Or the person has just been exposed to a whole lot of neat things and wants to use them all at once. A little more experience and this enthusiasm likely will get tempered to more manageable levels.

      A professional does what is good for his client, not just what's fun for himself. This lesson should be learned long before reaching the workplace, IMHO. Refusing to learn it does smack of incompetence, to me.

      --
      Ytrew

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://514212]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2014-04-19 23:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls