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:119 comp.lang.ada:3525 comp.infosystems:80 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!inmos!mph@lion.inmos.co.uk From: mph@lion.inmos.co.uk (Mike Harrison) Newsgroups: alt.cobol,comp.lang.ada,comp.infosystems Subject: Re: What's really wrong with COBOL? Message-ID: <4877@ganymede.inmos.co.uk> Date: 23 Mar 90 11:07:07 GMT References: <420@mck-csc.UUCP> <8458@hubcap.clemson.edu> Sender: news@inmos.co.uk Reply-To: mph@inmos.co.uk (Mike Harrison) Organization: INMOS Limited, Bristol, UK. List-Id: In article <8458@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >>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... ... > > 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. First let me say that I am an enthusiastic supporter of Ada's separate compilation mechanism and the separation of specification and implementation. I believe that those mechanisms, together with private types and packages are *well* worth the (occasional) infelicities of Ada. [I particularly miss the 'everything is an expression' character of Algol 68!] However, let's not get carried away by all this. Yes, the Ada specifications do provide a sort of interface contract, but they only enforce the *syntactic* (and perhaps *static* semantic) aspects of the interface, for example, for subprograms: - number and order of parameters, - types of parameters, - modes of parameters, - types of results. There is however, no support for checking the *dynamic* semantics of the interface, so the programmers on opposite sides of the interface may take very different views of the *meaning* of so data or code object, eg. a parameter may describe a 'length'; the specification writer may view this as 'feet', the writer of the body may treat the value as 'inches' and some user may be expecting 'metres'. This is usually handled by an associated 'specification document', (I know that complicated data type definitions can be written to ameliorate this example, but that still can't prevent a programmer from multiplying by 12 to convert from 'feet' to 'inches'). I am not saying that Ada should have included mechanisms to control this sort of problem, it was a considerable advance of previous languages, but I think that we should not try to *oversell* Ada. There is probably a case for putting some kind of assertion mechanism (at least on interfaces) into the new Ada design. I know about the problems of dynamic assertions, what I mean is some sort of statically evaluable assertions, to be used as an extension of the present separate compilation checks. Has anybody done any work on this? Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;