comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: GOTO Considered ...
Date: 1997/06/14
Date: 1997-06-14T00:00:00+00:00	[thread overview]
Message-ID: <dewar.866287533@merv> (raw)
In-Reply-To: 5nrvru$jee$1@krusty.irvine.com


Adam's comments about COBOL, e.g.

<<Sigh . . . I think anyone who institutes a no-GOTO rule in a COBOL
environment ought to have their head examined.  I was working as a
COBOL programmer about 20 years ago, when "structured programming" was
just coming into vogue, and I tried to write all my COBOL programs
without using any GOTO's.  I finally gave up.  COBOL doesn't have any
loop constructs---you have to put the body of the loop somewhere else>>


Are complete nonsense. He is talking about COBOL-66 (some of his comments do
not apply to COBOL-74, and none of them apply to the current standard, which
dates from the early 80's, and will soon be replaced by a remarkably
sophisticated object oriented version of the language).

We complain when people assume that Ada means Ada 83, and frame their
comments on this language in terms of this obsolete standard, so please
let's not make the mistake of doing even worse violence to other languages.

In fact, having written an extensive amount of COBOL 74 (I wrote large
sections of a COBOL compiler, the current Computer Associates Realia COBOL
compiler for the PC, and this compiler was written entirely in COBOL), my
experience is that I found the need for GOTO's in COBOL 74 to be entirely
comparable to the need in Ada 95. Sam's article could perfectly well be
rewritten to apply to COBOL!

Robert


Incidentally, looking at the loop issue specifically. COBOL certainly does
have full nesting of typical looping constructs, but it does also allow
the simple abstraction my means of PERFORM, as in

Process-Year.
  perform Process-Month varying Month from Jan to Dec.

Process-Month.
  ...


I find this kind of abstraction very handy, and miss it in the Algol syle
languages such as Ada. The only way to get such abstraction in Ada is to
declare a procedure, but

(a) this is FAR heavier syntactically, look at the light syntax in COBOL
    for these kind of abstraction procedures, just the name of the procedure
    and two periods, and that is it!

(b) the requirement that you declare procedures before you use them is in
    this case a serious impediment, because it means you introduce detail
    before the big picture. It is what results in the complaint in Pascal
    that you have to read the program backwards. In Ada you can get around
    this by using separately compiled units, but that is even heavier and
    more inappropriate for this kind of local procedural abstraction.

Of course if you have never written in a language that allows this kind of
procedural abstraction (COBOL is the most familiar such language, but there
have been others, including SETL, CDL and ABC), then you probably don't miss
it. Certainly you do not see Ada/C/etc programmers using this kind of
abstraction. Instead they tend to nest control structures deeply.

COBOL programmers generally have the same disgust towards heavy nesting
of control structures that anti-goto people display towards gotos in Ada :-)
They find heavy nesting confusing and avoid it using Perform abstraction:

Process-Balance.
   if Balance is negative then
      peform Send-Bill
   else
      perform Register-Credit
   end-if.

Send-Bill.
   ...


Register-Credit.
   ...


And, in case Adam or someone else is remembering COBOL from ancient
historical experience, it is of course the case that COBOL has full
syntactic capabilities for nested control structures, fully comparable
to those in Ada or C, and in some ways superior, but people just do not
like heavy nesting very much anyway.

So, COBOL in the Ada group, irrelevant junk? I think not. In the Ada
community, we find it frustrating that people dismiss Ada without knowing
anything about it. So, as I asked before, let's be especially careful not
to do that ourselves. In particular, I often notice the tendency to trash
C and C++ without knowing enough of the technical details. Yes, there are
significant and well founded technical arguments for the superiority of
Ada over C and C++, but badly informed arguments are unhelpful. It is one
thing to poke fun at C in "The Maiden and the Mandate (*)", but quite
another to present bogus technical arguments.

Sometimes when I read these uninformed attacks on other languages, I feel
like Lindsey Brigman in "The Abyss", who, having just encountered the aliens,
gets immediate support from a UFO nut, and angrily says to him "Get off my
side!"

Robert Dewar

(*) We recently performed TM&M in London (a successful performance, which
was attended by Ada's great great grandson :-) We will put the full script
of M&M on our web site in the near future, along with some clips from the
production.

Now we can get busy with the next chapter in "Musical Adventures of Lady
Ada", which will be a performance at the next Tri-Ada in St Louis. The
title of this show is "Princess Ada or the Castle AdaMandate". Make your
plans to come now (tell your boss how critical it is that you attend the
show to sharpen your Ada skills, and see all the latest Ada stuff, ACT
will certainly be there with lots of nice new Ada stuff, and I am sure
our competitors will also have lots to show also :-) And then come and
see the show :-)






      reply	other threads:[~1997-06-14  0:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <md5:5DC8C3E899C75D983B6B366E4BFCE28C>
1997-06-11  0:00 ` GOTO Considered Al Christians
     [not found]   ` <dewar.866202982@merv>
1997-06-13  0:00     ` Adam Beneschan
1997-06-14  0:00       ` Robert Dewar [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox