1. "To goto or not to goto, that, is the question"
Hi again Kat,
The age old argument of the goto or no goto has been around for quite
a while now. Arguments started around 1980 or maybe even sooner. The
pros and cons seem to boil down to one common factor though, and that's
whos using the gotos.
An experienced programmer uses the gotos sparingly, as im sure you would,
but the inexperienced not only use the gotos (at seeminly random intervals)
but get so adopted to incorperating them into their programs that they dont
learn programming structure as well as someone who doesnt have the liberty
of expelling gotos about the program files like confetti spewn at a
birthday party, not to mention the feeling of loss of control when they
turn to a language that doesnt have them.
So its seems if we do get gotos, it would subject all the beginning
programmers who start out on Euphoria to using the seemingly desirable
goto statement wherever they felt like it, as well as adopt not-so-good
programming practices, which they might hate to let go of later on.
Perhaps we will see a new keywords come up soon in Euphoria:
"with gotos"
"without experience"
hee hee
--Al
2. Re: "To goto or not to goto, that, is the question"
Al Getz wrote:
> Hi again Kat,
>
> The age old argument of the goto or no goto has been around for quite
> a while now. Arguments started around 1980 or maybe even sooner. The
> pros and cons seem to boil down to one common factor though, and that's
> whos using the gotos.
Having been around since well before 1980 (and yes, trains had already been
invented, thank you), I can only forward what was then -and is now- a valid
reason for distrusting straight gotos.
>From the very beginning (cf. Ada Augusta, Countess Lovelace) several facts
were clear to every programmer and designer:
a) A program will rarely stay intact forever; sooner or later it will be
added to, modified or in some way changed.
b) This may happen later today, next week, or ten years from now.
c) The changes may be done by the original programmer, but probably not.
All this means that the program not only must work properly. It must also be
readable.
I don't mean nice languages with non-cryptic sentences, nor tons of
documentation, nor fifty-line comments. I mean that when you reach a line
that says "goto sleep," you must be able to find a label called "sleep." An
also that when you reach the "sleep" label, you should be able to tell why
it's there, i.e. from which place or places in the program there's a jump
there.
I've never found a compiler or interpreter that will tell you that, unless
it can also print out an xref map, which can run to many pages, is normally
quite unreadable itself, and most people tend to ignore.
In fact, most compilers will let you insert labels wherever you like,
whether they are valid destinations or not. And several compilers I've
worked with would let you put a goto without the corresponding destination
label, and wouldn't holler until the procedure was actually ran, for they
treated it as a runtime error and not as a compile error (at most, they'd
insert a warning).
There's nothing wrong with gotos. In fact, most programs are chock full of
gotos, even if you don't see them. And I'm not partial to languages that
forbid them, as in the times of structured programming. But a programmer who
uses gotos had better never lose control of them. The only practical way
I've found to do this is to comment my every jump, even if it's just a memo
to myself tomorrow morning. Too many times I've had a program turn up
unexpectedly where it shouldn't have, and spend hours and days (literally;
try cobol-74 someday) drawing a map of the program just to detect where it
might have gone.
One final piece of boring experience: if your gotos gang up on you, try to
straighten them out only so far. Ask for help. After a few hours all your
wires are crossed, and you wouldn't see the connection if it bit you. Print
your source, don't read it onscreen. Read it aloud. Pay the price. Sigh...
Gerardo E. Brandariz
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
3. Re: "To goto or not to goto, that, is the question"
- Posted by Kat <gertie at PELL.NET>
Jan 07, 2001
-
Last edited Jan 08, 2001
On 8 Jan 2001, at 1:56, gebrandariz wrote:
> Al Getz wrote:
>
> > Hi again Kat,
> >
> > The age old argument of the goto or no goto has been around for quite
> > a while now. Arguments started around 1980 or maybe even sooner. The
> > pros and cons seem to boil down to one common factor though, and that's whos
> > using the gotos.
>
> Having been around since well before 1980 (and yes, trains had already been
> invented, thank you), I can only forward what was then -and is now- a valid
> reason for distrusting straight gotos.
>
> >From the very beginning (cf. Ada Augusta, Countess Lovelace) several facts
> were clear to every programmer and designer:
>
> a) A program will rarely stay intact forever; sooner or later it will be
> added to, modified or in some way changed.
> b) This may happen later today, next week, or ten years from now.
> c) The changes may be done by the original programmer, but probably not.
>
> All this means that the program not only must work properly. It must also be
> readable.
>
> I don't mean nice languages with non-cryptic sentences, nor tons of
> documentation, nor fifty-line comments. I mean that when you reach a line that
> says "goto sleep," you must be able to find a label called "sleep." An also
> that when you reach the "sleep" label, you should be able to tell why it's
> there, i.e. from which place or places in the program there's a jump there.
I agree. That's why i use it to jump a section of code usually small enough
that the target is onscreen with the goto. Or i use it to get out of a
procedure totally, like goto eoprocedure.
> I've never found a compiler or interpreter that will tell you that, unless it
> can also print out an xref map, which can run to many pages, is normally quite
> unreadable itself, and most people tend to ignore.
I have wished for that.
> In fact, most compilers will let you insert labels wherever you like,
> whether they are valid destinations or not. And several compilers I've
> worked with would let you put a goto without the corresponding destination
> label, and wouldn't holler until the procedure was actually ran, for they
> treated it as a runtime error and not as a compile error (at most, they'd
> insert a warning).
Need a smarter compiler.
Kat
4. Re: "To goto or not to goto, that, is the question"
Hi again Kat,
What is a good method of indentation for the labels?
Would your ideas be mainly for "private" gotos?
Another point is, if someone ELSE with less experience then you have writes
a program with gotos, are you going to want to read it?
--sample program with gotos
without warning
with gotos
without experience
goto lab1
lab2:
goto lab3
lab4:
goto lab5
lab6:
goto lab7
lab1:
goto lab2
lab3:
goto lab4
lab5:
goto lab6
lab7:
printf(1,"%s\n",{"remind self to use less gotos in future programs 
"})
--Al
5. Re: "To goto or not to goto, that, is the question"
Kat says:
> I agree. That's why i use it to jump a section of code usually small
enough
> that the target is onscreen with the goto. Or i use it to get out of a
> procedure totally, like goto eoprocedure.
Wish everyone were so careful. Also that they used self-documenting labels,
which most don't.
> > In fact, most compilers will let you insert labels wherever you like,
> > whether they are valid destinations or not. And several compilers I've
> > worked with would let you put a goto without the corresponding
destination
> > label, and wouldn't holler until the procedure was actually ran, for
they
> > treated it as a runtime error and not as a compile error (at most,
they'd
> > insert a warning).
>
> Need a smarter compiler.
Not smarter, just more thorough. You want to be free to code as you wish,
but also to find your mistakes (or just where to modify something) without
wasting hours or days. Anyway, you will always be able to hang a program, or
even the whole system, with a short infinite loop. No compiler can
substitute for good, careful programming.
Gerardo
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
