Re: What's really wrong with COBOL?

[mph@lion.inmos.co.uk (Mike Harrison)]

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;