billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/16/89)
From ok@cs.mu.oz.au (Richard O'Keefe): > COBOL has changed *dramatically* with time. Successive COBOL standards > have not merely added new things (like nested programs, terminators on > compound statements, new statements) but have also discarded old things > (like the ALTER statement). Oh, come on. How about recursion? How about generics? How about multitasking? Are you seriously suggesting that COBOL has made more than a shabby pretense of keeping up with the technology of software engineering? These are band-aids, which totally disregard the many fundamental problems that COBOL has been steadfastly ignoring for decades. (Followups to comp.lang.misc...) Bill Wolfe, wtwolfe@hubcap.clemson.edu
ok@cs.mu.oz.au (Richard O'Keefe) (10/16/89)
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).