Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!tektronix!reed!psu-cs!warren
From: warren@psu-cs.UUCP (Warren Harrison)
Newsgroups: comp.software-eng
Subject: Re: Re: Theory vs. Practice
Message-ID: <619@psu-cs.UUCP>
Date: 15 Apr 88 06:15:44 GMT
References: <38797UH2@PSUVM> <3415@bunker.UUCP> <3326@zeus.TEK.COM> <461@vsi.UUCP> <5775@bunny.UUCP> <2218@ttidc <65@qucis.UUCP> <4921@pucc.Princeton.EDU>
Organization: Dept. of Computer Science, Portland State University; Portland OR
Lines: 56

> In article <38797UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes:
>  
> >Often, an employer doesn't want someone who can think, apply principles
> >in novel ways, and be creative, as in "We have these 200 COBOL programs,
> >and they all use the depreciation tables in the IRS rulebook, and the
> >IRS just changed the rules.  Get in there and change the programs to
> >match the new rules..."
>  
> The really sad thing is that you CAN be creative in Cobol.  You can
> write a Cobol program, a TSO CLIST, or VM exec to change the code
> exactly (and even put in an exact comment as to date, time, and
> whodunit of change).  But this sort of thing will get you in trouble
> in the average Cobol installation.  See Phillip Kraft's excellent
> study, "Programmers and Managers" (Springer/Verlag 1977).

I guess this really isn't the place to defend COBOL given the audience,
but I would like to point out that probably the majority of people who
love to trash the ole' girl either don't know COBOL from a candy bar,
or if they have programmed in it, it was only in a one semester (or worse
yet quarter) course in which they barely got into the PROCEDURE DIVISION.
I have found COBOL to be orders of magnitude more useful in the areas
for which it is meant than almost any other language I know. For example,
not many languages offer you a uniform indexed file interface which is
for the most part uniform across environments.  Likewise few languages
support big numbers with no round off errors (how about PIC 9(18) COMP-3?)
due to the underlying number representation.  Not many languages include
a built in binary search verb, or a report writer.

In fact, COBOL has a bunch of neat features, but the average computer
science major never is exposed to them since the first COBOL course
is (1) usually taught at the "beginning programmer" level, so little
tim eis spent on the nice features of the language, and (2) is taught
by faculty whose exposure to COBOL is little more than what they see in the
book, and so aren't even aware how some of the stuff works.

I taught a course in software engineering at the graduate level a few years
back in which none of the students had ever even seen a piece of COBOL
code. Yet these self same students would snicker knowingly when the phrase
"COBOL" came up.

I guess I'd like someone to let me in on the secret too.  What's so bad
about COBOL (besides not having an in-line looping statement - but I've
found that tends to actually result in mor emodular code since every
loop body has to be in a paragraph or section by itself)?  Granted, I can
write some pretty bad code in COBOL, but nowhere close to the bad code I
can write in C.  Using the STRING/UNSTRING/INSPECT verbs I have found
COBOL's string handling to be almost as good as Turbo Pascal, and infact
some compilers are actually (gasp) written in COBOL (eg, Micro Focus COBOL/2,
so I understand).  If I really want to fool with mantissas and exponents,
I can have COMPUTATIONAL fields, and level 88's work better than boolean
variables for most uses

Anyway, I'm really looking forward to some insight on the problem.

Warren Harrison
The University of Portland