Re: language design implications for variant records in a pascal-like language

> On Monday 10 Jan 2011 at 18:23, compilers@is-not-my.name wrote:
> > Because industry listened to academics, and they shouldn't have,
> > ever. ...
> > Remember the good old days when there was no conditional loop? Either
> > you checked a condition and did a GO TO or you didn't have a
> > loop. Life was good and simple. And yes, I still prefer my source code
> > in all caps.
>
> Suppose you are reading some code from the "good old days"
> and you encounter a GO TO. Is there a loop or not?
> First, you need to find the label that is the target of the GO TO:
> if it is before the GO TO, then you have a loop, right?
> Well, not necessarily. Only if there exists a control flow
> path from the label back to the GO TO. Similarly, a forward GO TO
> might still be a loop if there is a path back to the GO TO
> from the label.


As interesting as that idea is on paper, there just isn't any practical
issue. IBM COBOL provided enough information in the listings to cross
reference and index things so that working on very large programs was not
difficult and most people coded things (at least in the early days up
through the 1980s) reasonably enough that the logic, which anyway was not
that complicated, could be followed. The reality is that not having control
structures in COBOL was not and is not an issue. It may have been an issue
if you pushed COBOL outside its envelope, but when used for what it was for,
it was an effective and simple tool and doesn't really lack anything. And
that statement goes for COBOL 20 years ago as well. It's ironic but a major
problem area in COBOL performance and complexity *is* the PERFORM verb which
does implement DO WHILE/DO UNTIL type processing. I understand that C
programmers are more comfortable working with PERFORM than GOTO when they
write COBOL or look at a COBOL application, but in my view PERFORM is more
trouble than it's worth. Some of that has to do with the realities of
virtual storage management for very large applications systems and some of
it has to do with the uncanny ability of people to abuse even things that
are designed to prevent abuse in the first place.


I don't suggest C coders use GOTOs, and C coders should stop suggesting
COBOL coders *not* use GOTOs. A place for everything, and everything in its
place...


> Suppose you have found out that there *is* a loop involved.
> Now you want to know which statements are in the loop body
> and which are not. To do that you need to construct the control
> flow graph, find the dominator tree, the loop header nodes,
> find all the nodes dominated by the loop header...


You only need to do that if you are a compiler. If you are a programmer, you
don't ;-)


I have personally written and worked on tens or hundreds of millions of
lines of COBOL code and millions of lines of FORTRAN. I'm not a COBOL or
FORTRAN programmer, but in the early days I spent a few years working on
large applications systems so I got a lot of exposure fast and wrote a ton
of COBOL. Later on I got involved in software performance and we looked at
and analyzed a lot of HLL application code, mostly COBOL and PL/I. I also
worked in tech support and had to diagnose and fix failures in applications
that used services our products provided. In that time I do not remember
ever having had a problem because of a lack of control structures available
for my own coding nor have I had a problem understanding and diagnosing and
repairing bugs in other peoples code. In context there are only so many
types of loops in COBOL and they're all pretty obvious and standard. Read a
record, do some processing, produce report headers and totals, etc. There's
nothing here that requires control structures. At the end of the day, over
50 years and billions of lines of code later, people get by. You can say
it's not perfect, but you can't say it doesn't work. The proof is in the
pudding. It does work.


You could argue FORTRAN would have been more readable with control
structures, especially since it *is* heavily used in problem domains
where those constructs make a lot of sense. I guess in that case it
was "you can't miss what you never had. I understand people who
started coding in the nineties don't have that view, but for those of
us who started decades earlier, nobody can tell us we can't get the
job done without all that, because the simple fact is that we
did. It's interesting that PL/I, which is a really nice language and
was available since the early 1960s never caught on, nor did it
replace any COBOL or FORTRAN, even though it had support for control
structures from the beginning and many other useful features. It turns
out that things other than what's hot in academia drive industry. The
most important factor is how productive people are with the tools they
have. Just like a bumble bee doesn't look like it should be able to
fly but it does, those old, simple languages got used and solved real
problems despite their lack of glitter, complexity, and academic
appeal and despite the vitriol and disgrace Wirth and Dijkstra tried
to heap on them ;-)


My post was a little tongue in cheek but not entirely. Everything has
to be understood in context. Things that make sense for certain
languages and problem domains don't for others. There isn't any "one
true way" as the academics would have you believe, and they tend to
focus on problems that aren't real problems or areas of computer
science that don't necessarily have much practical application. "Those
who can, do, those who can't, teach." With very few exceptions I found
this to be true. There are a few notable exceptions, some that come to
mind are Drs. Dewar and Stroustroup but aside from a small group we
don't find academia producing much of anything except textbooks and
mayhem.


I don't argue that control structures aren't worthwhile or necessary
for certain problems domains and languages, I'm just reminding
everybody that two of the world's most successful commercial languages
(COBOL and FORTRAN) got by for many decades without things that are
deemed essential in modern languages, and they still get the job done
today. They put men on the moon and built atomic bombs all without C++
or Java...
[Hey, they put men on the moon in Jovial, and built atomic bombs
with punch cards and accounting machines. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.