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:120 comp.lang.ada:3526 comp.infosystems:81
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!nosc!crash!ncr-sd!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: alt.cobol,comp.lang.ada,comp.infosystems
Subject: Re: What's really wrong with COBOL?
Message-ID: <8468@hubcap.clemson.edu>
Date: 23 Mar 90 06:27:30 GMT
References: <423@mck-csc.UUCP>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From article <423@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
>>   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.
> 
% 	- 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?

   There's considerably more as well... Ada's exception handling (a means
   of "damage control", similar to COBOL's "ON END" but considerably more
   sophisticated) and many other safety features enhance the reliability 
   of software systems in ways that simply cannot be attained within COBOL.

   There is also multitasking -- the ability to express the idea of 
   objects which do their work in parallel.  Here COBOL is helpless,
   even though it is much more natural in many cases to break down a
   system into different objects which exist in parallel and interact
   with one another.  

   And remember the generic priority queue I described earlier?  If one
   is to design such a system so that it can hold any number of objects,
   it is necessary to implement it using what is known as "recursion". 
   This is what happens when a procedure or function calls itself, an
   idea which COBOL strictly prohibits.  Recursion is considered to be
   fundamental to the proper implementation of many such data structures,
   and in fact is a fundamental basis of much of Computer Science.

   There is also tremendous difficulty when one tries to describe what
   is known as an "abstract data type" in COBOL.  This is a style by
   which one identifies and characterizes a real-world object through
   a description of the operations which can be done with that object,
   such that a guarantee exists that nobody can do anything with the
   object without making use of the predefined operations available 
   for it -- this makes sure that the "integrity of the abstraction",
   or the standard concept that everyone has of the object, is upheld.
   In COBOL, even the idea of having user-defined types is not supported,
   much less supported with the level of enforcement provided by the
   Ada "limited private" mechanism.

   There is quite a lot that COBOL has missed out on over the years,
   and this is why the DoD has given up on the idea of continuing to 
   use it.  With Ada support available now for typical MIS platforms, 
   and given the prospect of an incremental conversion, it just doesn't 
   make much sense to continue on with COBOL. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu