Re: 7E7 Flight Controls Electronics

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

Richard  Riehle wrote:

> > 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.
>
> Sorry, but COBOL was totally ill-suited to support of well-formed structures
> of any kind prior to ANSI-85.

COBOL (even 66) was very well suited to support of well-formed *data*
structures. As for control structures, oh yes, it did not provide blocks
(FORTRAN IV also did not provide them - was that FORTRAN stupid also?), and
I think it was right choice, PERFORM statements were better in those
circumstances.

>  Take the horrible model for an IF statement as an example.

Hm, what was so horrible there? I have no bad recollections of that IF.

> Those of us who had to use this half-baked conditional
> formation recall how easily it led to programming mistakes.

Well, some people like to count mistakes, while others (including me) prefer
to consider real counsequences of those mistakes (on a production line). My
experience says that these two accounts lead to rather different results.

And anyway, all constructs easily lead to programming mistakes, without
exceptions. Take for example those begin-end blocks. The following 3-step
scenario I encountered many times:

Step 1. Use the same identifier inside and outside of the block:

  declare i;
  i := ...;
  ...
  begin
    declare i;
    i := ...;
    ...
    ... := i; 
    end;
  ...
  ... =:= i;

Step 2. Reuse that variable inside the block:

  declare i;
  i := ...;
  ...
  begin
    declare i;
    i := ...;
    ...
    ... := i; 
    ...
    i := ...;
    ...
    ... := i;
    end;
  ...
  ... =:= i;

Step 3. Remove the first use of that variable inside the block along with its
inner declaration (just forgetting about the second use of it):

  declare i;
  i := ...;
  ...
  begin
    ...
    i := ...;
    ...
    ... := i;
    end;
  ...
  ... =:= i;

The final result is obvious, I hope.

> The fact that Jackson "was quite happy with COBOL" is simply an indication
> of the widespread stupidity regarding the shortcomings of the earlier forms
> of the language.

Is it a new fashion of political correctness to declare previous techniques
and tools that didn't become current mainstream - simply stupid?

>   No intelligent contemporary programmer would want to
> return to hideous mess of tangled code so typical of pre-ANSI-85.

Well, I can't say for intelligent people (they are so mystically clever, they
so easily differentiate and recognize so many puzzling abbreviations -:),
but in my humble opinion, a hideos mess of tangled systems and products and
concepts and standards isn't much better, and leaves even less hope for
keeping things under control.

> Structures, in the Dijkstra sense, was far more than "GO TO Considered
> Harmful."   More important, though, are the elementary control structures
> of Jacopini and Bohm which, when properly formed, will include scope
> terminators such as ANSI-85, END-PERFORM, END-READ, END-IF,
> etc, without which the resulting code is usually a mess.

Well, I prefer another "definition of scope" - that of H. Mills - a module
that fits into a page, that is, a scope is an amount of code which directly
fits into programmer's view.

> I have written and
> maintained code written by others, in COBOL 68, 74, and 85.  I would
> never want to do anything in 68 or 74 again.

Well, if you prefer to deal with magnificient templates, XSSL, SOAP, ADO,
DRM, Java 1.m.n etc., etc. (at the same time, of course) then it is your taste, 

> In my view, COBOL, prior to the ANSI-85 standard was not "very well
> suited" for writing maintainable, dependable, well-structured code,

Surely. It was just well suited to make programs which ran on production
lines - certainly with much pain, failures etc., but there was no other way
that time, in first place because of incomplete and often self-contradictory
specifications/requirements and unreliable hardware.

> Since the ANSI-85 standard, COBOL has become one of the most interesting
> languages around.  It has corrected the silliness of the earlier standards,

There was no silliness to correct. COBOL just was adapted to changed
circumstances - more powerful and reliable hardware, more challenging tasks,
more educated/experienced programmers, and better understanding of the
processes by analysts.




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