Re: What's really wrong with COBOL?

[billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )]

From article <420@mck-csc.UUCP>, by jw@mck-csc.UUCP (Jeffrey Weiss):
> All these recent jokes about COBOL's age and verbosity are fun, but, if
> we can get serious for just a sec. or two...
> 
> What are the real SUBSTANTIVE problems with COBOL?  Suppose I were suddenly in
> charge of a large DP shop.  Would it make sense for me to migrate away from
> COBOL?  Remember that my DP shop has billions of lines of installed code in
> COBOL, and conversion will require enormous time and cost.  Not to mention
> exposing me to the risk of problems when installing new softwares.
> 
> Now, I'm a reasonably hi-tech guy, not long out of Engineering school, but
> I need real arguments (that make business sense) to give to my boss, the CEO.
> And, are there viable alternatives such as "re-engineering" the existing code
> and investing in tools that make the COBOL environment more palatable?

   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.

   The language COBOL was invented by the US Department of Defense, and
   later abandoned because it was no longer adequate as a tool for the
   effective support of good software engineering practices.  Since the
   DoD also has had a large installed base of COBOL software, it has been
   the leader in applying effective strategies for dealing with that
   particular problem.

   The Ada programming language was designed with a mechanism called
   "pragma Interface" which enables it to call code written in other
   languages.  If you have one of the compilers which supports calls
   to COBOL (the IBM Ada compiler should certainly be able to do this),
   you can simply call upon your existing COBOL software system for as
   long as it remains serviceable.  Ultimately, old COBOL systems become
   so unmaintainable that it makes sense to rewrite the system, and at
   that point the system should be rewritten in Ada.  So the conversion
   need not be done all at once (although there are a number of companies
   which will gladly do such a conversion for you, for enough $$$); by 
   simply using Ada for all NEW code, it is possible to upgrade to Ada 
   incrementally without too much stress on the organization.

   Now let me just briefly sketch out why COBOL is considered to be no
   longer adequate.  In Ada there is a concept of separating specification
   from implementation.  You can design a software system in terms of 
   different subsystems by specifying (in a "package specification") how
   each of the subsystems is to function.  Then you compile these into
   the Ada program library.  Now there is an agreement among the members
   of the software development team that this is what the different 
   subsystems will do, and all that remains is to write the software 
   which will cause the subsystems to do what is expected of them.  What
   has happened is: we have broken down a large problem into several
   smaller subproblems.  Now the project can be broken up into several
   different programming teams, NONE OF WHICH KNOWS ANYTHING ABOUT HOW
   ANY OF THE OTHER SUBSYSTEMS ARE ACTUALLY IMPLEMENTED.  It is enough
   that they understand how the other subsystems are to operate.  They
   can then write their particular subsystem relying only on the services
   which the other subsystems have agreed to provide -- the specification
   of their subsystem is a "contract" that they must fulfill, and in turn
   the other teams must fulfill their contracts.  The Ada compiler will
   ensure that the terms of the contract are adhered to.  

   So why is this going to help us in maintenance?  Well, let's assume
   that a change is needed.  Unless it's a truly major change which would
   basically invalidate the entire system, we can almost always limit the
   scope of the change to a particular subsystem.  If that subsystem is
   in turn partitioned into different sub-subsystems, the change can be
   limited even further.  Only the changed area will have to be recompiled,
   and soon the modified system is up and running.  But what if there has
   to be a change in the terms of a contract?  Now the Ada compiler REALLY
   helps you out... it will automatically identify parts of the software
   system which depended upon the old contract but which are no longer
   being satisfied due to the changes which were made.  It helps you to
   minimize the extent of any needed changes, and helps you to track and
   control the effects of any major change.  But more than this -- think
   about the potential for reusing subsystems.  Once you have a very useful
   subsystem written and tested, you can use it over and over again without
   any copying of code.  With copying of code there is the problem of trying
   to find all the copies to update them in case there is a change, but in
   Ada there is no need.  If you find a defect in the implementation of a 
   subsystem, you can simply correct the implementation and let the Ada 
   compiler handle the rest.  And there is even the ability to construct
   "generic" subsystems -- subsystems which are written to do something
   generally and which (with you supplying a small amount of information)  
   can be quickly customized to do it in a particular fashion.  For one
   example, suppose that you wanted to have a priority queue (a system
   in which items are deposited with different priorities, and you always
   want to retrieve the item which has the minimum or maximum priority).
   In Ada, you can write a package Generic_Priority_Queue in which the
   idea of a priority queue is programmed, without knowing exactly what
   type of object is to be carried in the queue (the user will decide this).
   Later, the user comes along, describes the type of object to be carried,
   and all that software for handling a priority queue is immediately made
   available for use with that type of object, courtesy of your Ada compiler.
   You could also describe a network and how to do things with it (compute
   the shortest path between two points, find out how many connections will
   have to break in order to cut off all paths between two given points, etc.)
   independently of the type of object at each point or the nature of the 
   connections.  As you can see, this is a very powerful mechanism for reuse.

   This article is long enough already, but if you pick up a book on the
   Ada programming language and study it, you will begin to realize just
   how much advancement has occurred over the last 20-30 years, and how
   COBOL has not kept up with the times.  Please contact me via electronic
   mail (the address is wtwolfe@hubcap.clemson.edu) if there is anything
   I can provide (such as hard numbers on exactly how much Ada has been
   demonstrated to improve productivity) which would fall outside of the
   intended scope of the alt.cobol newsgroup.  As a specialist in Business
   Information Systems who has chosen Ada as the preferred technology for
   that domain, I will be happy to provide assistance to anyone who would
   like more information on why I believe this is far and away the best 
   language technology for the domain of Information Systems applications.
   

   Bill Wolfe, wtwolfe@hubcap.clemson.edu