Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow
From: schow@bnr-public.uucp (Stanley Chow)
Newsgroups: comp.software-eng
Subject: Re: Computer langauges and software lifecycle - references request
Message-ID: <432@bnr-fos.UUCP>
Date: 25 Apr 89 04:11:28 GMT
References: <570@umiami.miami.edu>
Sender: news@bnr-fos.UUCP
Reply-To: schow@bnr-public.UUCP (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 66

In article <570@umiami.miami.edu> slores@umiami.miami.edu (Stanislaw L. Olejniczak) writes:
>Several days ago I heard an very vigorous argument about the usability, if
>you will, of various computer programming languages.  A person (a
>professional programmer) was claiming that COBOL is probably the very best
>langauge for software writing _in general_ (i.e., for applications not
>specifically requiring facilities of special purpose langauges) because it
>can do everything C or Pascal or FORTRAN can, and in addition it is so
>widely used and so well standarized, applications are generally
>transportable from machine to machine with no modifications.  The sense
>of the argument was that COBOL was the most "useable" language, which by
>the virtue of its modularity, standarization, and wordiness made it the
>easiest of the major langauges to create reliable, portable and modifiable
>software. 
>

Having had to make a living writing/maintaining COBOL, FORTRAN & PL/I programs
for a couple of years (over a decade ago) and having been involved in some
big software project in very different areas, I agree with your friend with
some provisos.

In the limited domain of file processing (e.g., the classical edit/sort/update
cycle for accounting), COBOL is basically unbeatable. This is assuming you
take into account of the *life-cycle* costs. The reasons:
  - Good input format specification
  - Good output format specification
  - Good file/record handling
  - Good interface to many commercial packages
  - Portable
  - Easy to read for simple programs
  - Versatile (but precise and easy) numeric types

Amazingly, it is possible to write good modular code in COBOL. It takes some
discipline but is certainly an order of magniture easier than doing so in C.
It is also possible to write very bad code in COBOL but it takes real effort
(as opposed to merely bad code, which is always easy). It is also very fast
even with minor tunning (and you should see some accounting files to appreciate
what BIG is).

If I may preempt some objections to COBOL:
 - Verbose. 
    True but irrelevent. Proficent programs can knock out COBOL just as fast
    as C hackers can crank out filters in C. Most COBOL shops will have set up
    libraries of data structures any way, so programers don't have to do much
    data structures (in fact, usually, most programmers are not allowed to
    fiddle file formats).
 - Not-block structured, no variable scoping.
    Again, true but irrelevent. Most shops have set up variable naming rules
    so that scoping is not needed. With the PERFORM verb (calls a subroutine)
    you can write good modular code.
 - Poor choice of control structures.
    True, but in the right domain, the COBOL paradigm is very effective.

As soon as you get into more complicated programs, the verbose nature becomes
a great handicap. Doing interactive programs or number crunching in COBOL is
not what I would consider fun.

The major problem is that very few problems/systems these days are suited to
COBOL. All the new sexy things (real-time, windows, graphics, ...) don't work
well in COBOL.


Stanley Chow    ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public


Since I am talking about a previouse life, I would be very surprised if
my current employer want to be included.