http://qs321.pair.com?node_id=18562

I received so much positive feedback on COBOL vs. Perl that I figured Monks who have never worked on legacy systems may appreciate a discussion of why languages like Perl are superior to dinosaurs like COBOL.

Why is it a problem that legacy COBOL code still exists? Because in the 60s, CPU cycles and storage were tremendously more expensive than the programmer, relative to today. Thus, development was geared towards putting the burden of the work on the programmer. The computer was asked to do as little as possible, thereby ensuring that the bulk of the tedious work was handled by the relatively inexpensive programmer.

For example, COBOL (at least on IBM mainframes) can't create a new file. Instead, you have a FILE SECTION that would describe the new file. It might look like this: 

FD  O-NEWFILE
    RECORDING MODE IS F
    BLOCK CONTAINS 0 RECORDS
    RECORD CONTAINS 80 CHARACTERS
    LABEL RECORDS ARE STANDARD
    DATA RECORD IS O-NEWFILE-REC.
01  O-NEWFILE-REC                       PIC X(80).

[download]
That doesn't create the file. Job Control Language, or JCL, opens the file (think of JCL as a primitive scripting language). In another portion of the program, O-NEWFILE is linked to the JCL filename (well, sort of) and the JCL then attempts to create the file. The JCL that actually opens the file might be something like: 
//NEWFILE  DD DSN=B7707O.DDA50010.APDATA,
//            DISP=(NEW,CATLG,DELETE),
//            UNIT=DASD,
//            SPACE=(CYL,(150,150),RLSE),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=6400)

[download]
Note the lack of spaces. JCL is so intolerant that errant white space will cause the job to fail. Try to debug that.

After you've compiled and linked the program, you execute the JCL which will execute the COBOL program and then try to open the file. Without going through a COBOL or JCL tutorial, suffice it to say that with modern languages, such as Perl, many of the things that you had to tell a mainframe to do are handled behind the scenes. If you find the aforementioned example mind-boggling, just consider that I have greatly simplified them.

Compare that to Perl: 

open (MYFILE, "> $file") || die "Couldn't open $file: $!\n";

[download]
In the modern world, where we need to get things done, Perl reigns. Perl's not always the best language for the job (try writing the setiathome screensaver in Perl), but when you need to get things done and done fast, Perl can't be beat. The dinosaurs are going to be around for a long time, but they have to die.

Replies are listed 'Best First'.
RE: Perl: Survival of the Fittest
by Anonymous Monk on Jun 17, 2000 at 10:15 UTC
    Hi there. I enjoyed reading the Perl vs. COBOL tutorial, but I have to confess that it made me sad. I've worked in the same company with COBOL programmers before, and they were themselves dinosaurs. The company kept them around to wrangle the old mainframes used for the financial management system. They seemed to lead this joyless existence of concentration on minutiae, to such an extent that it actually warped their personalities (or maybe only already-warped people could stay in such a job so long). They were nitpicky, bureaucratic-minded, authoritarian, and devoid of creativity, just like the language itself. Aside from that tragedy, I am always saddened to see a programmer who has stopped learning. Creatively, such a person might as well be dead. As Larry Wall said, "Death is bad. I reject death. I will stay way from trucks today."
[reply]
RE: Why Perl Rules!
by Russ (Deacon) on Jun 17, 2000 at 01:55 UTC
    Thanks, Ovid. We appreciate your willingness to share your knowledge and experience.

    I know it is easy for me to simply forget "the hard way" of doing things, because I have so little experience with older languages.

    (COBOL and JCL code on Perl Monks...What a great place this is!)

    Russ

    P.S. BTW, great title!

[reply]
RE: Perl: Survival of the Fittest
by JanneVee (Friar) on Jun 17, 2000 at 03:57 UTC
    Actually COBOL has a place in programming. You don't hack COBOL. You hack Perl.

    I see it as a Design thing(tm). I can write Perl code that almost no one can understand. As for COBOL there is almost no Obfuscated COBOL.

[reply]
      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 

      COMPUTE MARTINI = GIN + VODKA.

      [download]
      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. :)

[reply]
[d/l]
        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?

[reply]
        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!

[reply]
RE: Perl: Survival of the Fittest
by Odud (Pilgrim) on Jun 17, 2000 at 17:00 UTC
    Also this kind of cumbersome language discourages experimentation. If I see some interesting Perl on this site or others it is the work of a moment to copy the code and run it. To do the same in COBOL (and many other traditional languages) you need to edit, compile, perhaps link, create the JCL, run the JCL etc.

    It slows things down tremendously, although on the positive side perhaps it makes you think more before you act. The death of COBOL is announced every year but I suspect there are still more lines of COBOL in use than all other languages combined.
[reply]
      "It slows things down tremendously, although on the positive side perhaps it makes you think more before you act. The death of COBOL is announced every year but I suspect there are still more lines of COBOL in use than all other languages combined."

      Of course there are more lines of COBOL than all others combined. You need to write so much code to do the smallest things. The example on Perl vs. COBOL for 80 lines COBOL to 10 lines of Perl. ;)

[reply]
RE: Perl: Survival of the Fittest
by Anonymous Monk on Jun 23, 2000 at 15:04 UTC
    Hey! COBOL is a paradise for programmer compared to RPG/400 (IBM's AS/400)! Imagine same problems as in COBOL plus many stupidiest language design decisions.
[reply]
      Lanugage design. Is there an exact definition of the term "language design"?
      Mr. Lee
[reply]

Back to Meditations