To everyone else:
I’ll distract him, while y’all get a rope.
sd
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
[email protected]
wrote:
All e-mails and attachments sent and received are subject to monitoring,
reading and archival by Seminis. The recipient of this e-mail is solely
responsible for checking for the presence of “Viruses” or other “Malware”.
Seminis accepts no liability for any damage caused by any such code
transmitted by or accompanying this e-mail or any attachment.
Should you accidentally encounter this e-mail, any e-mail that refers to
it,
or a reference to the fact that this e-mail may exist you are hereby
instructed to immediately demagnetize your hard drive, and burn any
removable media within 10 feet. All actions must be documented with
unedited
& timestamped non-digital video which you shall immediately delivery to
our
lawyers via bonded bike messenger at your own cost. By receiving this
e-mail
either intententionally or accidentally you hereby agree to not hold
Seminis
liable for anything, ever. Any data potentially lost due to the
demagnetization of hard drives, or burning of removable media, is the
sole
responsibility of you, your cat, your child’s cat and any other sueable
parties other than Seminis.
The fact that we’ve been pussy-wipped by our lawyers and enforce the
resulting stupidity upon our employess shall in no way reflect poorly on
Seminis, it’s CEO, CTO, President, VicePresident, their wives, and most
definitely not it’s lawyers, their cats, their cousin’s cats. Any bad
impression of our company derived from reading this agreement is a
direct
result of the nearest deportable contractor with no direct ties to
Seminis
who happens to be in our office at the moment.
Any mention of this agrrement will be denied in court unless we can use
it
to sue you.
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400]
[email protected] wrote:
To everyone else:
I’ll distract him, while y’all get a rope.
hehe. I recently noticed that C# still has a goto, although it seems
that you can’t have a label right at the end of a function since the
label must precede an actual statement. I found it to be useful in a
case where I was deep in nested loops, searching for a string and had
just found it, so I needed to jump out. It seemed so much clearer and
simpler to use the goto rather than have
if (… & flag_variable)
in every loop condition., even though I had to put silly nop
statements at the end of the functions.
In Ruby I sometimes do similar things with Exceptions, since an
Exception a rather glorified goto-with-parameters.
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.
L
On 5/18/06, Leslie V. [email protected] wrote:
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is
still sometimes simple and useful.
Indeed:
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
-A
On May 18, 2006, at 1:48 PM, Leslie V. wrote:
simpler to use the goto rather than have
if (… & flag_variable)
in every loop condition., even though I had to put silly nop
statements at the end of the functions.
This is what the return keyword is for.
In Ruby I sometimes do similar things with Exceptions, since an
Exception a rather glorified goto-with-parameters.
Yuck. Just use return.
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.
Abusing exceptions the way you describe sounds just as horrible.
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
On 5/18/06, Eric H. [email protected] wrote:
case where I was deep in nested loops, searching for a string and had
just found it, so I needed to jump out. It seemed so much clearer and
simpler to use the goto rather than haveif (… & flag_variable)
in every loop condition., even though I had to put silly nop
statements at the end of the functions.This is what the return keyword is for.
You are right, return works well there.
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.Abusing exceptions the way you describe sounds just as horrible.
The code is long but I’ll strip it down and let you have a look. Maybe
you can suggest a better way then.
Les
Leslie V. wrote:
hehe. I recently noticed that C# still has a goto, although it seems
that you can’t have a label right at the end of a function since the
label must precede an actual statement.
The one cool thing about C#'s goto that can’t be easily done in Ruby is
goto case 5 in switch-case IMHO.
In Ruby I sometimes do similar things with Exceptions, since an
Exception a rather glorified goto-with-parameters.
Please don’t abuse exceptions for this. It’s exactly what catch() and
throw() are there for.
Hi,
On Fri, May 19, 2006 at 05:48:40 +0900, Leslie V. wrote:
On 5/18/06, DEBAUN, STEVE [AG-Contractor/2400] [email protected]
wrote:To everyone else: I’ll distract him, while y’all get a rope.
hehe. I recently noticed that C# still has a goto, although it seems
that you can’t have a label right at the end of a function since the
label must precede an actual statement. I found it to be useful in a
case where I was deep in nested loops, searching for a string and had
just found it, so I needed to jump out. It seemed so much clearer and
simpler to use the goto rather than have
[ snip ]
This is why named loops in Perl was handy.
Cheers,
Phil
Leslie V. wrote:
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.
I couldn’t agree more.
I’d also add that not using goto structures doesn’t help you from
writing spaghetti code that much. Even using well-structured functions
can become a complex mess.
The whole goto issue is sort of similar to the TDD problem in my mind.
The difference is there is a possible fix for the TDD problem in BDD.
It’s not a code problem but a problem of how the we perceive the code.
We used Test Driven Design to help our development processes but we
missed the point of TDD so much that we have to come up with Behavior
Driven Design, which is the really same thing but is more explicit in
the terminology to help us get the point of what TDD was in the first
place.
Back then, with the goto problem, we found that we were writing a bunch
of messy and goto was the central construct that abused. So we decided
that it was better to use the function construct in most cases in order
to help this problem. But in our retreat of messy code we seemed to
place our fear of it wholly into the goto construct itself. My guess is
that this allows us to say that we can ignore a lot of that fear now as
long as we don’t use goto statements, which is sort of ignoring the
central problem of messy code.
Because of all this, it now seems that we are left with a weird
superstition around the goto construct. Which is pretty odd to me
because it’s still a fundamental construct used on the CPU, so why not
use it in the code when it helps?
2006/5/18, Leslie V. [email protected]:
if (… & flag_variable)
in every loop condition., even though I had to put silly nop
statements at the end of the functions.
When refactoring properly this is often easily solved with a “return”
statement.
In Ruby I sometimes do similar things with Exceptions, since an
Exception a rather glorified goto-with-parameters.
The best idiom for this in Ruby is catch throw (as opposed to raise and
rescue).
I think the great fear of having spaghetti code resulted in a bit of
an over-reaction: the universal condemnation of goto. Goto is still
sometimes simple and useful.
I would have to look at the link you provided - I cannot remember when
I last used a GOTO (must have been in my ancient ZX Spectrum times)
and I definitively never missed it after that. All modern languages
have decent program flow control elements that make GOTO really
superfluous IMHO.
Kind regards
robert
PS: Steve, you got the rope yet?
2006/5/19, Mike N. [email protected]:
Back then, with the goto problem, we found that we were writing a bunch
of messy and goto was the central construct that abused. So we decided
that it was better to use the function construct in most cases in order
to help this problem. But in our retreat of messy code we seemed to
place our fear of it wholly into the goto construct itself. My guess is
that this allows us to say that we can ignore a lot of that fear now as
long as we don’t use goto statements, which is sort of ignoring the
central problem of messy code.
I see this differently: experience has shown that GOTO in most cases
leads to bad code. It’s also formally proven that it’s not needed,
i.e. the same semantic can be achieved without it (but using if -
else, loop constructs etc.). Since these other constructs of course
can also be abused (like every feature a programming language
offers) but usually give better code remove the GOTO. And that’s what
they did.
Because of all this, it now seems that we are left with a weird
superstition around the goto construct. Which is pretty odd to me
because it’s still a fundamental construct used on the CPU, so why not
use it in the code when it helps?
Because it leads to bad code too often to outweight the occasional
benefits.
Cheers
robert
2006/5/19, Jake McArthur [email protected]:
On May 19, 2006, at 11:24 AM, Robert K. wrote:
Because it leads to bad code too often to outweight the occasional
benefits.Just because many people would abuse it does not mean that a
programmer who could use it cleanly and elegantly should be unable to.
Sometimes less is more.
robert
On May 19, 2006, at 11:37 AM, Robert K. wrote:
2006/5/19, Jake McArthur [email protected]:
Just because many people would abuse it does not mean that a
programmer who could use it cleanly and elegantly should be unable
to.Sometimes less is more.
But that’s kind of my point. To an experienced programmer, being able
to use a goto can amount to being able to cut a ton of complexity out
of his code.
Issues like this are not black and white. It’s kind of close-minded
to simply rule a tool out because that tool is difficult to use
correctly. Should people stop playing musical instruments, using
manual cameras, and driving cars? Well, that last one is arguable,
but my point stands.
- Jake McArthur
On May 19, 2006, at 11:24 AM, Robert K. wrote:
Because it leads to bad code too often to outweight the occasional
benefits.
Just because many people would abuse it does not mean that a
programmer who could use it cleanly and elegantly should be unable to.
- Jake McArthur
Quoting [email protected], on Sat, May 20, 2006 at 01:24:44AM
+0900:
I see this differently: experience has shown that GOTO in most cases
leads to bad code. It’s also formally proven that it’s not needed,
i.e. the same semantic can be achieved without it (but using if -
else, loop constructs etc.). Since these other constructs of course
It is also formally proven that just a conditional and a goto is
sufficient to implement loops, which I got to “appreciate” when writing
robot controllers in a variant of basic once. Bad memories.
I think goto would be difficult to implement in a dynamic language like
ruby, because of issues of scope and context, its not just where you are
in the code thats important, but how you got there.
If you want a goto, ruby has a number of options that might fit the
need: cast statements, call/cc is like goto on steroids with a laser
blaster, return/break/next, raising an exception, and catch and throw
all jump the point of execution from one place to another.
I use goto frequently in C for structured handling of error conditions.
This use is unnecessary in ruby, or even C++, because they have
exceptions and automatic stack cleanup builtin to the language.
Cheers,
Sam
On Friday 19 May 2006 11:05 am, Jake McArthur wrote:
But that’s kind of my point. To an experienced programmer, being able
to use a goto can amount to being able to cut a ton of complexity out
of his code.
The one time in 4 years of Ruby that I have needed something goto-like,
throw/catch worked perfectly to solve the need.
Goto is an ugly construct that is rarely missed and never needed.
Kirk H.
On 5/20/06, Robert K. [email protected] wrote:
But that’s kind of my point. To an experienced programmer, being able
outweights the benefits and that more is gained by removing it from
languages than would be won be keeping it. Of course you can find for
every tool an application case where it’s ideal but that doesn’t
proove anything.
Nowadays I could only find goto useful in controlling the error
path flow inside the kernel. Not Ruby’s Kernel, but the OS kernel,
where ‘normal’ stack unwinding is usually too expensive. But nobody
uses Ruby for kernel programming, right ? 
On 5/19/06, Phil J. [email protected] wrote:
This is why named loops in Perl was handy.
Precisely what I was thinking. The spaghetti code problem is largely
attributed to non-local use of flow control. I do miss being able to
easily jump out of a nested loop, and with the labeling construct Phil
refers to I think it’s pretty readable.
Of course conditionals, loops, function returns, et cetra are all just
fancy "goto"s in disguise.
2006/5/19, Jake McArthur [email protected]:
to use a goto can amount to being able to cut a ton of complexity out
of his code.Issues like this are not black and white. It’s kind of close-minded
to simply rule a tool out because that tool is difficult to use
correctly. Should people stop playing musical instruments, using
manual cameras, and driving cars? Well, that last one is arguable,
but my point stands.
This was not my point: my point was, that the harm done with GOTO far
outweights the benefits and that more is gained by removing it from
languages than would be won be keeping it. Of course you can find for
every tool an application case where it’s ideal but that doesn’t
proove anything.
robert
On Monday 22 May 2006 6:04 pm, Louis J Scoras wrote:
Precisely what I was thinking. The spaghetti code problem is largely
attributed to non-local use of flow control. I do miss being able to
easily jump out of a nested loop, and with the labeling construct Phil
refers to I think it’s pretty readable.
The Ruby way involes a little more typing than the Perl way, but it
seems
pretty easy to me:
tc = 0
catch(:bailout) do
while true
tc += 1
throw :bailout if rand(50000) == 1
end
end
puts “Bailed out after #{count} iterations.”
I like this. It’s very flexible. It lets me pass data out of the dark
inner
place that the execution path is escaping from, and it will let me nest
catch() statements if I want.
Another silly, slightly more complex example:
def do_iterations
iterations = Hash.new {|h,k| h[k] = 0}
tc = 0
while true
tc += 1
iterations[0] += 1
while tc % 100 != 0
tc += 1
iterations[1] += 1
while tc % 10 != 0
iterations[2] += 1
tc += 1
throw(:bailout,[tc,iterations]) if rand(50000) == 1
end
end
end
end
count,iterations = catch(:bailout) {do_iterations}
puts “Bailed out after #{count} iterations.\nIterations:
#{iterations.inspect}”
catch/throw don’t need to be used often, but when they are needed, they
work
great for all of the same thing that labeled loops in Perl work for, and
then
some.
Kirk H.