Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^3: The Null Mull (or, when OO needs more O)

by dragonchild (Archbishop)
on Nov 30, 2004 at 14:01 UTC ( #411186=note: print w/ replies, xml ) Need Help??


in reply to Re^2: The Null Mull (or, when OO needs more O)
in thread The Null Mull (or, when OO needs more O)

It's not a maintenance nightmare at all. You simply document how to check a return value. The scripter doesn't have to know anything about it. They just use the interface. They get a result, and test that result for true or false (or however the rest of the system does things). The mechanics are homologous to testing a result code through a method like a lot of modules already have in their interface. If the coders aren't checking return values, the program still breaks at the same point.

brian, brian, brian. *sighs* If only 90% of people who type Perl code into an editor1 actually followed a tenth of what you say. But, alas, that is not the case. In fact, it is so often not the case that ... let's just say they already have enough rope to hang themselves with.

You simply document how to check a return value. The scripter doesn't have to know anything about it. They just use the interface. They get a result, and test that result for true or false (or however the rest of the system does things).

In 7 jobs located in 5 states over the last 4 years where I've used Perl, documentation was done in exactly two places. In one, a multi-billion dollar consortium that handles 40% of all credit card transactions, the documentation was done so we could have something to review code from. It was never actually kept up to date, nor was it any form of developer doc. In the other, a 100-million dollar insurance firm, since I wrote the system from scratch, I documented exactly enough for my protegee to keep the system running.

What happened in the other 5 jobs? Bupkus! That's what happened. Motorola, BankOne, a tiny startup ... none of these firms documented their Perl code, processes, APIs ... nothing! You cannot assume anyone will document code, let alone Perl code. Remember - Perl isn't a programming language, so it's got to be really easy to figure out.

If the coders aren't checking return values, the program still breaks at the same point.

Actually, it won't. See, 90% of all Perl code currently running on some production system somewhere doesn't

  • use strict, warnings, or -w
  • check return values from system calls
  • check return values from DBI calls
  • use taint (I'm guilty of this one)
  • use hashes in any reasonable way

As a consultant, that's the code that I have to support. And, because the people who wrote this pus-dripping, camel-vomiting dreck either have CS or MIS degrees, they obviously know everything there is to know about Perl. So, when someone comes up and says "Here, let's go ahead and make Perl feel more like VB", they're going to go "Ooooh!" and jump all over it.

Except, they'll screw it up. But, since these flea-bitten, dog-kissing, motherless goats wouldn't recognize a development process if it painted itself pink and purple and danced naked on a bar wearing a fruit basket on its head, they DIP2 like it's 1959. Once it's in production, getting it out is like giving medicine to a toddler. Even though the child is only 30 inches talls and 25 pounds, it still takes 2 adults to hold the squirmy bastard long enough to squirt 4ml of pink goop into its mouth3.

While this is partly tongue-in-cheek (could you tell?) ... I'm also being deadly serious. This proposal requires a lot of API documentation. I can definitely see a CPAN module using it, especially one like Mail::Sendmail for the example you gave above. Advocating development shops use it when the language doesn't have explicit support built in can be ... well ... disheartening for those of us who will have to maintain said code. I mean, can't you see how this is hurting the children?!? Think of the children, brian! The children!!!

  1. Please note that I did not say Perl coder / hacker / programmer / etc. I certainly did not want to imply that 90% of people who type Perl actually know what they're doing.
  2. DIP = Develop In Production. Only slighly better is TIP (Test in Production). And, yes, 90% of all Perl code in the world is either DIPed or TIPed. Believe it, or not.
  3. I'm not kidding. You'll want 3 adults if you don't want pink goop all over your shirt.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.


Comment on Re^3: The Null Mull (or, when OO needs more O)
Re^4: The Null Mull (or, when OO needs more O)
by brian_d_foy (Abbot) on Nov 30, 2004 at 19:22 UTC

    If you're dealing with undocumented code, then it doesn't matter what the code actually is: it's a maintenance nightmare even without very simple technique. Let's blame the right thing, and not transfer your rage onto the innocent. :)

    Other people may suck, but that doesn't mean I need to.

    --
    brian d foy <bdfoy@cpan.org>
      My theory is that 95% of everyone is below-average.

Log In?
Username:
Password:

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

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

    Is guessing a good strategy for surviving in the IT business?





    Results (90 votes), past polls