gotos

[Every system needs one]

In article <1988Apr30.230243.15728 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
> > > Language designers and standardizers do have to consider badly-written
> > > existing code...
> > 
> > Standardizers, yes; designers, no.  If you design a language, then there
> > is not existing code.
> 
> Only if you are designing a totally new language, as opposed to one like C++
> that is upward-compatible with an existing language to some degree.  In real
> situations as opposed to classroom exercises, upward-compatible extensions
> are rather more common than from-scratch designs.

This has no application to the subject of ANSI C introducing incompatibilities,
unless you are implying that ANSI C is an upward compatible language rather
than the standardization of an existing one.

> > ANSI isn't considering "badly written" code, aparrently...
> 
> Not true, actually.  X3J11 does not feel *compelled* to consider badly-
> written existing code.  Sometimes it does, though; there are concessions
> to such pragmatic issues here and there, where it doesn't do too much
> violence to other objectives.

Hmmm... this seems to lend even more creedence to the idea that what ANSI is
doing is designing, not standardizing, when added to your prior statement.

> > although defining "badly written" in a standard that makes something badly
> > written is begging the question.
> 
> Only if you believe that no previous standard existed, which is wrong.  There
> was no *formal* prior standard, and this caused a lot of fuzziness, but there
> was consensus on most things.  (Otherwise formal consensus standardization
> like X3J11 would be impossible, after all.)  In the absence of a carefully-
> written formal standard, there is more room for debate about whether specific
> code is badly written, but the term remains meaningful.

Yes, but if the the code was not defined as "badly written" before the informal
standard is "formalized" and is defined as "badly written" afterward, then
the formalization has changed the definition and can not truly be considered
to be "standardization".  It reminds me of that Bill Cosby routine where
Noah tells God "You change one of them".

> > > ... Turning clean human-readable notation into
> > > ugly fast code is the compiler's *JOB*.
> > 
> > You don't agree that less of the same instructions == faster code?
> 
> IF other things are equal (they usually aren't), and IF the generated code
> is in fact different (it often isn't), then it is faster code.  So what?

Well, that "so what?" kind of put a damper on any of the reasonable arguments
I could have used to refute the implication that slow code is a bad idea when
compared to a trivial difference in coding style.

> Remember, I do not advocate bashing code after the fact to remove gotos;
> my experience is that well-organized code never needs them in the first
> place, so efficiency comparisons between goto code and bashed versions of
> it are irrelevant.

Never, huh?  Are you saying that everybody who has ever used a goto in the
first place is, in fact, writing badly organized code?  This is ridiculous.
Am I expected to apply this to all languages?  What do I use instead of a
branch instruction in assembly?  Repeated instructions?

> > ...  Are you trying to tell us that you have *NEVER* used a goto?
> 
> Disregarding maintenance of goto-containing existing code, which sometimes
> is done under time-and-effort constraints that make major cleanup impossible,
> I haven't used one in quite a few years.  I wouldn't say "never", but I
> don't recall the last occasion.
> 
> > How does a goto differ from a break statement when used to exit a for
> > statement to the statement immediately after it... pages of code later? ...
> 
> If you write such things, I suppose the answer is "not much".  Personally,
> I consider *any* form of exit (except a function return) that goes to a
> point pages later to be a serious botch.

For complicated algorythms which defy simplification, this makes for a great
deal of pushing and popping, as well as greatly complicating the use of
for statements, which must have an additional test to check to see if the
flag is set.

> > Why can't goto's be used, in your book, to handle non-standard conditions?
> 
> Because there are better ways.

Such as?  Consider that you have a bunch of non-global fd's which have to
be closed prior to exiting.  In addition, each is required to have a byte
sequence that indicates "END-OF-DATA" for another program.  How is writing
this with a procedure that requires 1) making the fd's global or 2) passing
all of them, as well as generating 6 or so function references for the 6 or
so locations where program flow determines an exit should occurr intrinsically
better than simple goto statements to one location?

> > > I've only programmed in C for 13 years.
> > 
> > What do you write?
> 
> Everything from small patches for existing code to quite large programs.
> The one major gap in my experience is not much involvement in huge multi-
> programmer multi-year projects... which in my opinion are doomed anyway
> unless they can be split into manageable pieces.

How large is quite large?  How do you provide

	1) utility
	2) readability
	3) speed
	4) more speed

> Criticism of new mistakes does not require embracing old ones.  Do remember,
> also, that I berate human use of the feature, not its existence -- I have no
> quarrel with its use in mechanically-generated code, for example.

A mechanical code generator that can't generate code which fits into a
person's arbitrary standard of "goodness" is not a good thing, and therefore
should not be used.  Philosophically, this is why I believe there will
always be programmers.  Machines are too dumb to program well, and humans
are (mostly) too smart to program mechanically... among other reasons for
this being true is the simple, Darwinistic phrase "you're fired".  Bad
programmers "go away".


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'Admit it!  You're just harrasing me because of the quote in my signature!' |