Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

RE: RE: Perl: Survival of the Fittest

by Ovid (Cardinal)
on Jun 17, 2000 at 04:59 UTC ( #18597=note: print w/replies, xml ) Need Help??

in reply to RE: Perl: Survival of the Fittest
in thread Perl: Survival of the Fittest

JanneVee, with all due respect, I disagree. I have had to deal with extremely obfuscated COBOL. One company (that shall remain nameless) that supplied us with software had deliberately written the system so that copybooks contained copybooks that contained still further copybooks. Imagine trying to find a variable that was cryptically named WS-FLT-DATA (for example) that was buried several copybooks deep and then trying to figure out what it did. Hoo boy! One of their programmers privately admitted to us that this was done to guarantee that they had the support contract (though I will confess that their company gave great support).

And then there was the program where the programmer cleverly named all of his variable after types of alcohol and had statements like

I would have given anything to get my hands around that programmer's neck.

The point is not whether or not a language can be obfuscated (I think C is obfuscated simply by its existence), but the development time. COBOL is, generally, easy to maintain, but the development time is horrendous.

Let's take a vote: how many Monks who have experience with both COBOL and Perl feel that there is anything they can develop faster in COBOL?

Another point: Yes, Perl code can be obfuscated and has a steep learning curve (compared to COBOL). But consider the example that I pointed out in COBOL vs. Perl: 80 lines (after optimization, no less!) of COBOL code compared to 10 lines of Perl. Unless someone is deliberately obfuscating the Perl, 10 lines is one heck of a lot easier to debug and maintain than 80.

I went on longer, but it cut me off. The prosecution rests. :)

Replies are listed 'Best First'.
(jeffa) 3Re: Perl: Survival of the Fittest
by jeffa (Bishop) on Jun 21, 2000 at 01:13 UTC
    Let's take a vote: how many Monks who have experience with both COBOL and Perl feel that there is anything they can develop faster in COBOL?

    A headache?

Closing arguments.
by JanneVee (Friar) on Jun 17, 2000 at 13:35 UTC
    All your statements are true.

    I have a little expirience with COBOL and the conclusion I came to was. The long development times of COBOL is an effective Anti-Hack mechanism.

    The design thing(tm) in Perl is make it fast to develop. But after a hour of coding you end up with code that works and does everything that the COBOL program does(after say 4 hours of coding). Under that hour you're most likely to take the solution that first pops up. Compared to the knowledge you're going to waste alot of time if you pick the wrong one. With COBOL you plan your work different.

    And as for Buss sensetive code (if the programmer gets run over by a buss -> no one can figure out the program). You can write COBOL extremly Obfuscated. You can write Perl Obfuscated. (true statements?) . Cobol is hard to develop with!(true statement). Perl is easy to develop and deliberately obfuscate (to keep support or what ever.). All these staments lead to That if it is hard to develop it should be hard to "waste" time on deliberately obfuscate the code. The horror story of Perl, a really good Perl programmer writes code that he says it is the best code he ever written. It is about 200 lines of Perl. The guy quits and no one can figure out the script. A rewrite was nessecery and they ended up with code that was about 300 lines. He was indispensable but he didn't work much to get the code impossible to understand. It is a little more work to do the same thing in COBOL. It can be done and usually done for a reason. The perl-programmer did not intend to write the code hard to understand.

    The defense rests!

      JanneVee, I can see your point and actually gave you a ++ for it.

      In my last job, no code was permitted into production (in theory) unless a senior PA analyzed the code and declared that it fit standards -- including documentation. Now, I admit that Perl is not the easiest language to learn and can be difficult to understand if the programmer is haphazard. That's where shop standards come in. Before any code gets moved from test to production, it should be reviewed. If a particular programmer has a habit of writing obfuscated, undocumented code, that programmer gets the boot.

      That's the perfect world. The reality is, many of the newer organizations that I see shoot from the hip and standards are a nebulous dream. Documentation? What's that?

      As compared to COBOL, I will definitely concede that Perl is sometimes more difficult to maintain on a line by line basis. But, Perl programs are usually so much more compact and efficient that trying to sort through 10 lines of normal code, however dense, is much easier than following the logic of 80 lines of clear code (IMHO).

      Now that I stop to think about it, I can't think of a single significant COBOL program that I've worked on that wouldn't be at least 50% shorter in Perl, usually considerably more. I would estimate that most COBOL programs could be shrunk by 3/4 if written in Perl. That makes the logic more compact, and thus easier to control. (This is due, in part, to COBOL's poor capabilities. I've actually worked in quite a variety of languages and I cannot think of one that is as feature-poor as COBOL. If you can name any significant ones, be my guest)

      That ad hoc 3/4 smaller estimate does not count the JCL that must be added to make the COBOL work.

        Perl is efficient that is why i'm a member of Perlmonks. ;)

        I have nothing against replacing COBOL with Perl. But to replace all lines of COBOL would be far to expensive. And not to mention mixing enviroments(that is really "buss-sensetive").

        As for Shop Standards. Must be always there independent of programing language.

        Feature poor as COBOL? Assembler pops into mind!

        The most valid point *we* had through this discussion. The world isn't perfect. Companies have a reason to exist. That is to turn a profit. Not to make it easy for anyone but them selves!

        End this thread please!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://18597]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (9)
As of 2017-04-26 13:55 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (480 votes). Check out past polls.