Re: 7E7 Flight Controls Electronics

["Richard Riehle" <adaworks@earthlink.net>]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message
news:mailman.85.1086832128.391.comp.lang.ada@ada-france.org...
> 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.

The data structures were consistently global, thereby making the notion of
localization of data impossible.   The fact that FORTRAN also failed to
provide adequate scoping rules for conditional constructs does not make
the same defect in COBOL any more acceptable.

PERFORM was never parameterized and still isn't.  In addition, there
are somewhat awkward rules for the scope of a PERFORM.  We would
frequently do one of two things.  PERFORM THROUGH where we
had a dummy paragraph with an EXIT, or PERFORM by SECTION.
In either case, all data was global and that led to no end of maintenance
errors.
>
> >  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.

I have seen no end of trouble with nested IF statements in COBOL, many
of which used the NEXT SENTENCE feature, or worse, a GO TO to
escape from nested structure.   The cure for this was the END-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.

The need for end of scope for control structures was recognized early in the
design of most other programming languages.  It came late to COBOL.
>

>
> > 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.

Well, that is also a rather inadequate definition of a module.  I recall
people
using that definition where they would take a red pencil and simply start
a new module every fifty-six lines.  A module, properly defined, will adhere
to the rules of cohesion and coupling, or follow the advice of Parnas, or
Meyer.   Certainly modules should be short, whenever that is appropriate,
but arbitrary page length or screen length criteria will create more
problems
than it will solve.
>
> > 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,
>
Not sure why you make this comparison since it has nothing to do with COBOL.
I am simply arguing that early versions of COBOL fell short of what was
needed for creating well structured, maintainable code that provided support
for good modularity (e.g., cohesion and coupling) and modern COBOL is
much improved.

> > 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.

I have written and maintained so much COBOL over my career that I have
no difficulty remembering the problems with it.  I have also used
contemporary
COBOL and it is lightyears ahead of the earlier versions of the language.
It is interesting to me to realize that, when I was using those
earlier versions of COBOL, I did not understand just how crippled the
language was because I learned all the workarounds.
>
> > 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.
>
Sorry.  But when I compare old-time COBOL with contemporary COBOL,
I see such vast improvements that the older versions look to me now like
primitive cave drawings.   This has nothing to do with improved hardware,
improved programmers, or better processes.  It has everything to do with
a greatly enhanced language definition where I can more effectively create
parameterized modules with call by value or reference,  can create control
structures that have well-defined scope, and can avoid excessive use of
global data.

Richard Riehle