From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Xref: utzoo alt.cobol:118 comp.lang.ada:3521 comp.infosystems:79
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!mck-csc!jw
From: jw@mck-csc.UUCP (Jeffrey Weiss)
Newsgroups: alt.cobol,comp.lang.ada,comp.infosystems
Subject: Re: What's really wrong with COBOL?
Message-ID: <423@mck-csc.UUCP>
Date: 22 Mar 90 20:34:16 GMT
References: <420@mck-csc.UUCP> <8458@hubcap.clemson.edu>
Reply-To: jw@mck-csc (Jeffrey Weiss)
Organization: McKinsey & Company, Inc., Cambridge, MA
List-Id: <comp.lang.ada>

In article <8458@hubcap.clemson.edu>,
 billwolf exercises the keyboard and comes up with:

>>From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
>> 
>> ...What are the real SUBSTANTIVE problems with COBOL?
>
>   From a business perspective, the real substantive problem with COBOL
>   is that typically 80% of effort is spent trying to maintain code which
>   fundamentally is unmaintainable.  The reason for this is that COBOL has
>   found itself unable to evolve quickly enough to keep up with the last
>   20-30 years' worth of evolution in programming language technology.
>
[   ...history of COBOL and Software Engineering 101 deleted...]

>   Now let me just briefly sketch out why COBOL is considered to be no
>   longer adequate.

[   ...brief 80-line description of Ada features deleted...]

Those lines indicated two features (apparantly well supported by Ada) that
might be linked to maintainability.  Those are:
	- Module dependency tracking to aid in identifying "ripple-effects"
	  when implementing a change.
	- Ability to build callable libraries of generic functionality, thus
	  supporting layered, modular programming.

I agree, these are important.  (Someone else has mentioned local variables not
existing in COBOL, a feature which fits nicely in the above list.)  Now, are 
there really no ways to implement the above features in a COBOL environment?
Are function calls and libraries not possible for some reason?  And could
tools such as SCCS or "make" provide the first point?

...mit-eddie!mck-csc!jw
Jeffrey Weiss