Re: 7E7 Flight Controls Electronics

["Alexander E. Kopilovich" <aek@VB1162.spb.edu>]

Richard  Riehle wrote:

> COBOL, prior to the 1985 standard, was a dreadful language for
> structured programming.  In fact, it was so horrible that I have no
> compunction in stating that true structured programming was almost
> impossible in the language.

Certainly you are using here the words "structured programming" as a special
term, that is, in Dijkstra's sense. But that way of structuring programs is
not the only possible way, and it is not generally best, that is, there are
major application domains for which this way isn't the best. There are other
ways for structured programming (in general sense), and COBOL was very well
suited for some of them. For example, if you have ever read "Principles of
Program Design" by Jackson, you may recall that JSP was quite happy with
COBOL.

Commercial data processing domain in those times required data-based (and not
algorithm-based) structuring. Therefore "structured programming" in Dijkstra's
sense was absolutely useless for most of applications in that domain, and can
be even harmful indeed.

>   Even after the improvements in the 1985
>standard, COBOL programmers continued to use the language in
>stupid ways.

Well, there is a section in Dijstra's book "Discipline of Programming", in
which the famous author fell into stupidity. It is the section, in which he
tried to prove that "commercial" (commercial data processing) programming
isn't different in any meaningful way from other kinds of programming
(probably meaning scientific programming). The author honestly provided an
example and finished with a complete program. Reading that program, and being
an expert in that application domain (that time) I concluded that the program
is very bad, it would be disaster to put that program on production line, and
that this program must be completely rewritten. So that example in fact proved
that commercial data processing is (was) different indeed.

Several years after that, I read an article (I can't remember the title and
the journal, but I think that the name of the author was Lucas or something
like that) in which that difference was explained very clearly: in scientific
programming the algorithms are eternal - a method for solving a certain kind
of equations remains right forever; but in commercial data processing the
algorithms are volatile - the rules for calculation of taxes are changed
rather frequently.

> The ANSI-1985 standard added scope terminators to the IF, READ,
> and PERFORM statements, added an in-line PERFORM, added the
> powerful EVALUATE statement, and enabled subroutine calls by
> both value and reference.  These and many other enhancements to
> the language were substantial improvements.  However, most
> COBOL programmers took a long time to learn to use them.
>
> The COBOL EVALUATE statement is one of the most powerful
> constructs of any existing programming language.  I wish we had
> something like it in Ada, but we don't.

I remember that several years ago Robert Dewar remarked (here in comp.lang.ada
or elsewhere) that the concept of "object" in current COBOL standard is more
rich and complex than even in C++ (and certainly more rich and complex than
in Ada).




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia