10 Mar
2023
10 Mar
'23
9:37 p.m.
From: "Ronald Natalie"
Multilevel breaks are as bad as goto with regard to
structure violation.
In a way, you are right. There isn't really much difference between:
for (mumble) {
for (foobar) {
do some stuff
break-2;
}
}
and:
for (mumble) {
for (foobar) {
do some stuff
goto all_loops_done;
}
}
all_loops_done:
The former is basically just 'syntactic sugar' for the latter.
I think the point is that goto's aren't necessarily _always_ bad, in and of
themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
in a _structured_ way (oxymoronic as that sounds), to get around things that
are lacking in the language's flow-control, they're probably fine.
Then, of course, one gets into the usual shrubbery of 'but suppose someone
uses them in a way that's _not_ structured?' There's no fixing stupid, is
my
response. Nested 'if/then/else' can be used to write comletely
incomprehensible code (I have an amusing story about that) - but that's not
an argument against nested 'if/then/else'.
As I've said before, the best sculpting tools in the world won't make a great
sculptor out of a ham-handed bozo.
Noel
10 Mar
10 Mar
9:46 p.m.
New subject: I can't drive 55: "GOTO considered harmful" 55th anniversary
I've used gotos for decades but in a "structured" way. My functions
have a pattern:
<allocation section>
<work section>
<deallocation section>
and there are a series of labels in the deallocation section. Then while
you are wandering through the allocation section, you can jump to the
right spot in the deallocation section.
And yes, this is a simplification because I initialize all my pointers to
NULL so the deallocation is all
if (p) free(p);
but the idea is the same. You wind up some state and wind down some state
and the gotos are used to jump to the right place to unwind.
On Fri, Mar 10, 2023 at 10:37:02AM -0500, Noel Chiappa wrote:
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
From:
"Ronald Natalie"
Multilevel breaks are as bad as goto with regard
to structure violation.
In a way, you are right. There isn't really much difference between:
for (mumble) {
for (foobar) {
do some stuff
break-2;
}
}
and:
for (mumble) {
for (foobar) {
do some stuff
goto all_loops_done;
}
}
all_loops_done:
The former is basically just 'syntactic sugar' for the latter.
I think the point is that goto's aren't necessarily _always_ bad, in and of
themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
in a _structured_ way (oxymoronic as that sounds), to get around things that
are lacking in the language's flow-control, they're probably fine.
Then, of course, one gets into the usual shrubbery of 'but suppose someone
uses them in a way that's _not_ structured?' There's no fixing stupid, is
my
response. Nested 'if/then/else' can be used to write comletely
incomprehensible code (I have an amusing story about that) - but that's not
an argument against nested 'if/then/else'.
As I've said before, the best sculpting tools in the world won't make a great
sculptor out of a ham-handed bozo.
Noel 
10:04 p.m.
New subject: I can't drive 55: "GOTO considered harmful" 55th anniversary
On Fri, Mar 10, 2023 at 10:37 AM Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
[snip]
I think the point is that goto's aren't necessarily _always_ bad, in and of
themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
in a _structured_ way (oxymoronic as that sounds), to get around things that
are lacking in the language's flow-control, they're probably fine.
Something that I think was likely a useful outcome of Djikstra's
polemic is that people began looking at what they were using goto for
and the things that were useful were extracted and codified as
first-class mechanisms in lots of languages (e.g., `break` and
`continue` for loops; exceptions; early function returns;
multilevel-break where that's a thing in a particular language, etc).
Goto is sort of like a hammer stone, it's useful for all kinds of
things, but it's difficult to control without practice and patience.
You can probably cut a diamond with one, but why endure the difficulty
and take the risk if you have access to a jeweler's hammer?
- Dan C.
11 Mar
11 Mar
12:55 a.m.
New subject: I can't drive 55: "GOTO considered harmful" 55th anniversary
That’s my point. Both break structure.
Just hinding the break with some construct that isn’t “goto” doesn’t
make it acceptable.
------ Original Message ------
From "Noel Chiappa" <jnc(a)mercury.lcs.mit.edu>
To tuhs(a)tuhs.org
Date 3/10/2023 10:37:02 AM
Subject [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th
anniversary
From:
"Ronald Natalie"
Multilevel breaks are as bad as goto with regard
to structure violation.
In a way, you are right. There isn't really much difference between:
1:04 a.m.
New subject: I can't drive 55: "GOTO considered harmful" 55th anniversary
On Fri, Mar 10, 2023 at 1:55 PM Ron Natalie <ron(a)ronnatalie.com> wrote:
That’s my point. Both break structure.
Just hinding the break with some construct that isn’t “goto” doesn’t
make it acceptable.
The alternative is often worse, though. I'd take a well-aimed goto or
a nested break over a bunch of conditionals in the bodies of loops any
day, both in terms of readability and performance.
That said, I'm not a huge fan of the `goto fail;` pattern. Apple had a
pretty major bug with that, and I find that many, many times it can be
replaced with a restructuring of the code. For example, perhaps do
your allocation, call a function and capture the return value (passing
the allocated resources as arguments), and then de-allocate and return
the cached return value. Let the compiler optimize it.
As an experiment, I rewrote the Apple bug code (which was open source)
to do that and it was cleaner and simpler than the original. Someone I
showed it to said, "but what, are you going to do that for _every_
function that can fail?" Well no, but generally you don't have to; we
fixate too much on the general problem and ignore the specifics.
- Dan C.
1:35 a.m.
New subject: I can't drive 55: "GOTO considered harmful" 55th anniversary
That's a good point about the specifics, there's no one-size-fits-all error
condition that describes every possible exceptional circumstance, so how could there be
one singular best practice for handling the abstract concept of an "error".
Plus, given one person's error is another person's business logic sometimes...if
we can't agree on what an error is, how can a computer be expected to :P
- Matt G.
------- Original Message -------
On Friday, March 10th, 2023 at 11:04 AM, Dan Cross <crossd(a)gmail.com> wrote:
On Fri, Mar 10, 2023 at 1:55 PM Ron Natalie
ron(a)ronnatalie.com wrote:
That’s my point. Both break structure.
Just hinding the break with some construct that isn’t “goto” doesn’t
make it acceptable.
The alternative is often worse, though. I'd take a well-aimed goto or
a nested break over a bunch of conditionals in the bodies of loops any
day, both in terms of readability and performance.
That said, I'm not a huge fan of the `goto fail;` pattern. Apple had a
pretty major bug with that, and I find that many, many times it can be
replaced with a restructuring of the code. For example, perhaps do
your allocation, call a function and capture the return value (passing
the allocated resources as arguments), and then de-allocate and return
the cached return value. Let the compiler optimize it.
As an experiment, I rewrote the Apple bug code (which was open source)
to do that and it was cleaner and simpler than the original. Someone I
showed it to said, "but what, are you going to do that for every
function that can fail?" Well no, but generally you don't have to; we
fixate too much on the general problem and ignore the specifics.
- Dan C.
653
days inactive
653
days old
5 comments
5 participants
participants (5)
-
Dan Cross -
jnc＠mercury.lcs.mit.edu -
Larry McVoy -
Ron Natalie -
segaloco