And of course there were languages of the time like FORTRAN, which
encouraged unconstrained use of "GO TO" and the creation of "spaghetti
code". FORTRAN at that point had very limited support for structured
programming: one very restrictive loop construct and a conditional
branch which was essentially a three-way "GO TO". There were even cases
where the conventions being followed might require a "GO TO" to reach
corrective additions which would then use a "GO TO" to resume the
original statement stream, either to preserve statement number
sequencing conventions, or to avoid resequencing the entire program deck
when all cards had sequence numbers.
I think more people interpreted Dijkstra's remarks as a complaint
against the "unstructured" use of "GO TO" and the lack of language
support for structured programming constructs that forced frequent "GO
TO" use, rather than an arbitrary total ban. The complaint was
primarily one about use of the "GO TO" degrading comprehension of the
program structure, not about program performance. Ultimately, all code
is reduced to the Assembler or machine language level, where the
machine-level equivalent of the "GO TO" is essential and unavoidable.
ACM SIGPLAN (Special Interest Group on Programming Languages) Notices
tended to publish humor, especially near April 1. One proposal many
years ago to totally eliminate the FORTRAN "GO TO" was to replace it
with a "COME FROM" statement. This totally eliminated the confusion
over whether any FORTRAN statement with a statement number might be the
target of some unseen remote branch -- and replaced it with the even
more confusing concept that every statement with a statement number
might actually be a disguised branch to some remote "COME FROM" statement.
JC Ewing
On 04/16/2012 07:42 AM, McKown, John wrote:
What??? "monopolizes the CPU"??? GO TO was made a pariah by an article by Edgar
Dijkstra.
http://en.wikipedia.org/wiki/Considered_harmful
And, of course, management went stupid (again) and came up with "you cannot use the
GOTO in any code at all!!!!". Which actually makes some COBOL more complicated due
to the requirement of nesting IF statements within IF statements. And before the END-IF,
that could be very complicated. I've see old code like:
IF ... THEN
...
IF ... THEN
...
ELSE
NEXT SENTENCE
...
IF ... THEN
...
IF ... THEN
...
ELSE
NEXT SENTENCE
ELSE
...
.
Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
