From: alawrenc@sobeco.com (a.lawrence)
Newsgroups: alt.cobol
Subject: Re: The inevitable question
Date: 29 Jul 92 01:20:52 GMT
Distribution: usa
Organization: Sobeco Ernst & Young

WAIT A MINUTE!  Doesn't everyone involved in this discussion realize that
they are comparing apples and oranges.  Just for the record.  I have been
programming professionally in assembler and machine languages since 1967,
COBOL since 1970, RPG-II, III & 400 since 1976, BASIC since 1981, C and PASCAL
since 1984, not to mention the dozen or so other languages I used for various
project.

COBOL is going to survive and continue to be used for business application
simple because of its the best language for that environment.  After all 
it is the COmon Business Oriented Language.  It is also the most portable of
all languages I have ever encountered.  Probably because, thanks to Grace 
Hopper, is was the first to be standardized.

For writing systems software for a cross platform environment, C is the best
I have met to date.  I expect it to expand the almost monopoly is now has
even more in the future.

For simple multilevel reports and will manipulation RPG (or some IV GL) will
win every time.

etc. etc. etc.

My choice of a language for any development project depends first on what
the system is (business, graphics, database, etc) and secondly what is
supported on the platform or platforms the application is supposed to
run on.

In <Bs2r39.Hot@snuffy.wa.atk.com> mluders@snuffy.wa.atk.com (Matthew_Luders) writes:

>emery@Dr_No.mitre.org (David Emery) writes:

>>The hallmark of COBOL systems is maintenance.  

Sorry, the hallmark of all *production* systems is maintenance.  To the
order of 80% maintenance to 20% new development.  Whether the application
is an operating system, accounts payable, a windowing environment,
general ledger or a word processor.  The language the system is written
only impacts the time necessary to develop the application.  Maintability
is impacted by the quality of the documentation and how well the original
design was structured and the programs written.  Again, irregardless of
language.

>... I find that a well-written C program is
>easier to maintain than a poorly-written COBOL program.  

Any well written program is easier to maintain that a poor written program.
Again, the particular languages involved have very little to do with it.
Seems kinda obvious to me.

>Why are the programs in such bad shape?  Three possible reasons spring to 
>mind:

>(1) Many of them were written 15-20 years, before the importance or principles
>    of stuctured coding and design were well known and accepted.

Structured programming has been with us 1972.  Before that we used a 
technique called modular programming which was the same think defined
less formally.  Before that smart programmers designed and wrote their
code that way because it worked and was maintainable.

>(2) The people that wrote these programs had backgrounds in accounting or
>    business management, not computer science or electrical engineering.
>    Actually, this seems to be true even today.  

The computer "scientists" and engineers I have met who actually program 
are the some worst *production* programmers I have ever met.  So are
the accountants and managers.  Mostly because these people work alone
on relatively small projects.  Give me professional programmers, who
know about standards, walkthoughts, documentation and coding efficienty.
In reality bad code is the result of bad system management.  The 
project manager is the one who decides whether or not to adher to
programming standards, not the programmer.  In the past I've sent
more than one program back for a major rewrite because the programmer
was sloppy and I've fired programmers who thought standards were for
others.  Again the language involved has no importance.

>    In fact, this is probably why
>    COBOL is under the alt heading instead of comp.lang with the other
>    languages.  I wonder how many COBOL programmers even know of the existence
>    of the Internet?

Very, very few.  Most programmers, not just COBOL, go to work in the
morning, work at their assigned tasks throughout the day, and go home
at the end of regular business hours.  alt.cobol vs comp.lang.cobol is
not a function of the attitudes or COBOL programmers but rather who
the subscribers to Internet are.

>(3) COBOL programmers (like programmers everywhere) are often under pressure
>    to make changes to code quickly.  This can lead to "quick-and dirty"
>    patches that are not well-integrated with the basic design of the program.
>    Over time, this leads to code that is a convoluted mess of patches on top
>    of patches on top of patches, ad nauseum.

Again, this applies to any programming environment.  Its a management
problem, not a language or programmer problem.

>There is a bright side.  For all the criticism that COBOL gets from software
>engineers, it is possible to write structured, readable, maintainable code with
>it.  

It is possible to write structured, readable maintainable code in any language,
possible exception APL.

>Its record and field handling capabilities make it well-suited for
>creating reports, which is probably what it's used for the most.  But the fact
>that a program is written in COBOL certainly does *not* guarantee (or even
>improve the chances) that it's maintainable.  In fact, you could argue that
>there are elements of COBOL that tend to make programs written in it *less*
>maintainable (e.g. the lack of local variables).  Some of these problems were
>addressed with the release of COBOL-85 (e.g. the addition of the end-if and
>evaluate statements), but I don't know how widely COBOL-85 is being used yet.

Actually most COBOL code is involved in processing files.  One of COBOL's
strong points is that sequential, random and indexed file access methods
are built into the language standard.  Another advantage is decimal
precision.  PIC S99999V99 COMP is just that in COBOL, guantanteed.
Just as COMP is guaranteed to be the most efficient arithmetic format
on the platform, and I know of one computer where that is *not*
binary.

>I'd be curious to hear other people's opinions on these topics.

So you have.
-- 
On a clear disk you can seek forever.
-------------------------------------------------------------------------
Andrew Lawrence, Informaticien Conseil           |  alawrenc@sobeco.com
3605 St-Urbain, #1605                            |  uunet!sobeco!alawrenc
Newsgroups: alt.cobol