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.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo comp.lang.ada:2778 comp.lang.misc:3589
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.ada,comp.lang.misc
Subject: Re: COBOL (Was: Modernizing Ada; now moving to comp.lang.misc)
Message-ID: <2437@munnari.oz.au>
Date: 16 Oct 89 03:50:49 GMT
References: <2431@munnari.oz.au> <6783@hubcap.clemson.edu>
Sender: news@cs.mu.oz.au
List-Id: <comp.lang.ada>

In article <6783@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
> From ok@cs.mu.oz.au (Richard O'Keefe):
> > COBOL has changed *dramatically* with time.

>    Oh, come on.  How about recursion?  How about generics?  How about
>    multitasking?  Are you seriously suggesting that COBOL has made more
>    than a shabby pretence of keeping up with the technology of software
>    engineering?

This is a very strange form of argument.  Has Fortran 8X got multitasking?
Nope.  Is Fortran 8X dramatically changed from Fortran 77?  Yes.

Wolfe's original claim was
	COBOL has stood absolutely still
	therefore DoD has abandoned it.
Nothing could be further from my mind than to suggest that COBOL is an
advanced language or that it has generics or multitasking (although the
COBOL I used back in the 70's did have multitasking).  My points are:
	COBOL has not stood absolutely still;
	It has in fact changed fast enough to hurt COBOL users.

The reason for mentioning this in comp.lang.ada (other than to correct
a false claim about COBOL's stasis) is the second point.  Converting
from one COBOL standard to the next is seldom just a matter of recompiling.
I repeat, there are companies that make large sums of money converting
other people's programs from (old) COBOL to (new) COBOL.

Do we really want that to happen to Ada?  If there turn out to be
compelling reasons for the Ada 8X -> Ada 9Y transition to require
more than recompilation, would it be possible to require an Ada 9Y
compiler vendor to provide a validated conversion tool for 8X?
Not necessarily a tool to do all the conversion, but at least one
to indicate all the places where changes are needed.  It is particularly
important to detect the parts of a program which will pass syntax and
semantics checking in a 9Y compiler but do something different ("quiet
changes", to use the X3J11 term).