Re: 7E7 Flight Controls Electronics

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

Richard  Riehle wrote:

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

First, not generally impossible - you had subroutines for that. Second, it
was just good thing that that localization was not too easy - it would
constantly confuse programmers and severely increase number of nasty mistakes.
Please don't confuse abstraction skills of typical COBOL programmer (that
time) with those of typical Algol-60 programmer (those of average FORTRAN IV
programmer - "typical" was't applicable to FORTRANers - were somewhere in
between).

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

Again, it wasn't a defect - it was adequate for that reality. Well, if there
were scopes in COBOL-66, I could use them, but probably I wouldn't - because
it would be impossible to explain those "tricks" to almost all programmers
around me, and I had no intention to maintain my production programs myself
infinitely. And the same was often true for FORTRAN (but not so often as for
COBOL).

> PERFORM was never parameterized and still isn't.

Well, begin-end blocks are non-paramerized also. If you needed parameters
you had subroutines for that.

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

Well, it is true that those rules required either training or experience for
their good application, but I don't call then awkward for that - because their
relative proximity to the language used by "analysts" (who composed problem
specifications/requirements) that time was more important than any abstract
clarity.

> In either case, all data was global and that led to no end of maintenance
> errors.

In fact, the was a good opportunity to provide a kind of localization in
COBOL-66: you could put you data into a structure even if that data does not
participate in I/O and need not be structured for the algorithm. The data
remains global, but nevertheless it becomes "localized" in some sense (well,
if you wish an exact, abstract definition of this "localization" then here it
is: the variables become localized in the space of identifiers).

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

Nested IFs are evil (well, dangerous -:) anyway, and there can't be any cure.
For me, END-IFs (in all languages that employ them, including Ada) bring
little help when IFs are nested - the visibility decreases drastically and
the code becomes error-prone.

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

Well, that *need* came late to COBOL, not the *recognition* of that need.
I hope you agree that 1) COBOL designers most probably were aware of Algol
(58/60) and 2) there were no significant syntactic or semantic problems with
introducing begin-end blocks into COBOL. 

> > > 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 pointed at the current programming "biblioware" for commercial data 
processing. I meant that those problems with early COBOL, which you mentioned,
aren't bigger or more painful than current problems (associated with
programming languages of various kinds) within the same application domain.

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

Well, you were lucky in that you had opportunity to see and use COBOL-85.
I had no such opportunity. Even COBOL-74 was far remote thing for me - I could
only see some distorted (translated) documentation. Possibly this difference
plays its role - you saw more advanced COBOL and therefore the previous one
seems too bad for you, while I saw that old COBOL only, and remember that it
was good enough.

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

Excellent. Now realize that as I did not see later versions of COBOL, the
time stopped for me at that point, regarding COBOL. And I'm quite sure that
I was not stupid that time, and I definitely knew Algol-60 (and even tried
to learn Algol-68 -:) . So if we have a disagreement on this issue, it seems
more about of role of time in our opinions than about COBOL-66 itself.

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

But those people who created cave drawings probable weren't stupid. Moreover,
I venture to think that if one of now-famous painters somehow appeared in
those caves between those tribesmen then, perhaps, he would decide to create
similar drawings - just because they could be understood by people around him.

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

Programming language is a language - it must be understood by people who use
it. If only 10% of users can properly understand sufficient part of the
language then the language will fail. Therefore education of programmers and
level of understanding of problems by analysts - matters for a programming
language.




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