I call BS. 2009 attendance data (to date) - Best are the Yankees, with a 45K per game average.
Yeah, and the LA Dodgers are #2 only a couple of hundred tickets behind. Dodger Stadium is very cool, though a pain to drive into.
I had my worst baseball experience ever there. My father took us to a game against the Braves to watch Hank Aaron play and we got to the game late and missed his early inning home run...:-(
And my best experience taking a friend to Jingu who knew nothing about baseball, let alone NPB and pointing at Alex Ramirez and Roberto Petagine during the pregame warmup and saying I want to see those guys hit home runs and they did, Petagine's being the game winning run.:-)
Trust me, just about nobody does baseball at this point.
A baseball game in a good stadium is good fun, though expensive. I note that the LA Dodgers are #2 in average attendance so far this season. Dodger Stadium, ground level, is a wonderful place to watch a game. As is Jingu Stadium (Yakult Swallows), except Jingu is better as the Swallows are underappreciated and good seats are always available.
Get out of your mother's basement sometime, live a little. Baseball is a nerdy game. The very first computer program I ever wrote (on a hard copy terminal and saved to paper tape) computed baseball league standings.
If the concentration is so dilute that you can't smell it, then the molecules, even if yes, they really are floating in the air, aren't in plain view. Just like if you have your drugs inside a cardboard box
Interesting point. Haven't we been told that a significant amount of US currency has detectable traces of cocaine on it?
A police dog can decide your vehicle has drugs or whatever else they're looking for and when the dog starts barking, suddenly the officer has a perfectly legal search.
That's kind of sad. I've seen the dogs "hired" after Superferry 14 http://globaljihad.net/view_page.asp?id=528 and they just seem more interested in finding food in baggage than bombs.
I find it amusing that someone would go to such lengths to forge US Government correspondence but not bother to run spell check and/or proof read the letter.
I find it amusing that someone could be found to code up an auto execute function for inserted media. I find it even more amusing that there was a stupid enough manager to sign off on it.
"This planet should spiral inwards on such a short time scale that the likelihood of seeing it is very low," said Coel Hellier, an astrophysicist at Keele.
Oh ye of little faith...
Maybe we're just getting better at observing our surroundings?
Yeah, I felt ashamed about that. I offer my humble apologies.
There's been too much name calling on both sides. Dijkstra's original comment regarding programmers who had not been taught structured languages from the start still burns me...
I really wish snprintf was available on my C implementation.
You still have %*.*s, just pick 125 for all of them and you won't overflow. What kind of person has (or has parents who would give him) a name Christian or family longer than that?
I was so taken aback that I probably just stared at him for a few seconds. Then, I stupidly said "So... You want to see my code?" but he was like "No, the result is correct, and your implementation is very fast, so I don't need to see the code. Good job. Send in the next guy."
This is so sad. He notices your code is faster and he's not the least bit curious? (I presume he's some kind of CS prof.) Anyway, good for you, but still...:-(
Yeah, sad. When I was demoing my OS class project I was told that it was the best project they had seen in a decade and a half of teaching the course and could they please keep a copy of the source. Which absolutely worked for me. I got it done so fast I had time to implement online help in the shell which rather stunned them.
This was in HP-1000 assembly and the main display was a row of LEDs on the front. I arranged my idle task to flash different LEDs as it got scheduled. The TA had earlier issued a challenge (for someone like me) that he liked to crank the timer up to max and watch student projects crash (the HP-1000 had 3 possible time intervals and the fastest interval was very fast). I added a command to my shell to allow changing the timer interrupt at run time. The LEDs showed that I was spending a lot of time in the scheduler (I didn't bother to optimize it once I knew it worked) in the shortest timeslice mode. But it worked and the terminals were still responsive.
Absolutely the most fun class I've ever had. The prof even had me teach for a day towards the end of the semester on VMS IPC mechanisms.
One developer I worked with liked using the following for code he wasn't using right away: if (1 == 2).
Don't judge him too harshly. It was possible in early FORTRAN implementations to do `1 = 2' and thus modify a constant making the constant `1' in the source code `2' in the running code. It was a bit more complicated than that, but that was the effect. As I recall, though I can't find it now, people did that to fix last minute bugs when certain "constants" needed to be changed.
Now, had they follow a more linux/apple approach, and released something every 6 months to 1 year, they would have known much soon that they were headed down a bad path, and they would have also been able to get new features into the hands of users much sooner.
It's been about 2 years since 10.5. I am not going to buy 10.6 for awhile and certainly not on Friday.
But let's see. My vital app in Mac OS X is X11 so I can do work. It works great when Apple doesn't break it like they did in 10.5.
Sadly, I have to agree that a long release cycle between O/S versions is probably a good idea.
Since goto need to be paired with a label it's the least evil of the group.
I don't follow that argument. Why wouldn't return, which doesn't need a label because it's always unambiguous, not be less evil?
I don't follow your statement. An IDE can always follow a local goto to its intended target label via `M-.' or whatever. A return is ambiguous as to where flow of control goes next. There's no way that an IDE (or a compiler) has of knowing which routine you want to see the source code of. That's always a runtime issue. The best an IDE can do is present a menu of calling sites in the source code it knows about.
Show me your code and I'll show you an alternative.
So what? I guarantee that whatever you come up with will be slower, less readable and hence more expensive to maintain.
Kernel code is the perfect application domain at this time for use of goto for slow path error clean up. And see the example of a proposed structured construct with identical semantics that requires both bottom-to-top and top-to-bottom semantics that I posted earlier.
Many modern languages don't support GOTO, or only include it to support machine generated code (ADA).
Ada is not an acronym. And Ada supports goto because it is a low level systems programming language and kernel code that separates fast path usual case code with error handling slow path code is less error prone and faster.
As you can tell from that, and many other sides, there are no major pros to using GOTOs, but very major negatives.
Um, did you even bother to read that link? He's basically arguing from the same position I am and against dogmatic wankers like you appear to be.
In the remaining one case out of 100 in which a goto is a legitimate solution to the problem, document it clearly and use it.
Seems like a fair statement. Compare that to
GOTOs have no place in man made code.
There's been little argument that most gotos can be replaced with equivalent and convoluted "structured" code. One of my favorite languages (Icon) does not have goto. It has a rich set of control structures that permit you to do pretty much what you need to do. Its functional domain does not require the use case of whittling clock cycles off of interrupt handlers.
No need for goto, though occasionally it comes in handy.
Congratulations. You have just implemented goto with a variable assignment. How is that any more readable than a plain goto?
If that switch statement is of any size, you will be forced to check the code after it before going to the next state when manually tracing execution. It's not any cleaner than straight gotos and arguably worse (extra levels of indentation). Now if there is actually code that needs to be done in between state transitions, then you're better off.
The key is not that all uses of goto are harmful. The key is "if I use goto, is my code more or less fragile when the next guy comes along to maintain it?" Fragile code is guaranteed to be broken and often times, obeying top to bottom, no multiple exit points, no break or continue, multiple flag variables to track state and deeply nested if-then-elses is the most fragile code of all if it needs to be modified. I believe I'll write a journal entry about that. Hello Ron Louie if you're reading this.
As long as the gotos only go down, i.e. like a return or break, there is no spaghetti code.
The Ada guys seem to agree with you on that. Break, but no continue. I don't personally have any issues with continue. In code that's a spaghetti of deeply nested if-then-elses mixed with loops, it can be somewhat difficult to see where they go to next, but the same can be said of break too.
The issue has always been unstructured use of goto. The difference is that with a formal control structure you have strict rules as to when there is a goto (as to the else clause). With a goto you have to read a bit harder to see what is happening because it's usage is not guaranteed to be structured.
They called it Structured Programming for a reason, but it's still syntactic sugar.
wouldn't a switch be just as easy? just leave out the break in each section and it'll flow through everything below it
The semantics on switch are not correct. Think of it as a computed goto.
Now if you had a dynamic switch, with the cases computed bottom to top, you would have the correct semantics.
reverseswitch { case ret = initialize4():/* executed fourth */
unwind4();/* and fall through */ case ret = initialize3();/* executed third */
unwind3();/* and fall through */ case ret = initialize2();/* executed second */
unwind2();/* and fall through */ case ret = initialize1();/* executed first */
unwind1();
return ret; }/* further processing, we know we initialized */
Now, if the individual cases are evaluated bottom to top (oops, just violated the top to bottom rule), then that would give the correct semantics.
So now, we have mixed orders of execution, bottom up in the case of the evaluation of the different cases and top down in the case of the error unwind. Which is exactly what we want. Is this any easier to read than the gotos?
I suppose we could count on the compiler to separate out the unwind logic. We want the machine to execute the equivalent code with gotos, not necessarily have to look at it.
It's not. But nor is code that uses goto in the idiom that FourthAge posted above.
My objection to that code is that if you do even just three or four allocations, you start getting very large indentations pretty fast, especially if you like 8-character indentations [sourceforge.jp]. (They get pretty long even with 4, which is what I like!) This causes a problem if you restrict yourself to 80-columns [sourceforge.jp].
Arguably this is a problem with restricting yourself to 80 columns,
For me, these are the main reasons I love having both of those restrictions. It forces one to keep nested ifs to a minimum, the bane of testing and reading comprehension.
Now it is time for a language designer to step up to the plate. We know what kind of control structure we want - code that compiles into something as icache friendly as the geode driver. It's not going to be exceptions. Even with exception support in Ada, it was still deemed necessary to have goto. Exceptions are fairly heavy weight since potentially stack frame unwinding must done (which implies additional runtime code when only a simple goto is needed).
There is not much difference between "return 0;" and "ret=0; goto exit_function;".
Indeed.
Both are unconditional jumps there is no rational reason why one should be "considered harmful" and the other not.
The most anal of the anal retentives of the goto-less persuasion do indeed consider them the same and consider both harmful. Wirth's original Pascal did not have a return for that reason. I'm not sure why he allowed a goto and no return. He later reversed himself in Modula II where he added return, but removed goto.
Languages that provide a rich set of control structures (an if statement has an implied goto too) do not need goto. Icon (my favorite language for recreational coding) http://www.cs.arizona.edu/icon/refernce/ref.htm does not need a goto. Neither does the Unix shell.
Low level languages intended for systems programming do need a goto for the reason I noted above - every prefetched byte in the icache counts and you DO NOT want to mix slow path error handling code in with hot path usual case code. Even Ada, which otherwise frowns at non-local flow of control, provides a goto.
To me, nested ifs are much easier to read - they convey the meaning/intent of the code a lot better. As in 'if this function call works, then do this. Otherwise, just clean up and exit'
Besides the excessive indentation, my mind starts to swim in a wall of close braces. More than something like 2 levels of nested ifs is hard to read, in my opinion. Indeed, I find the original version easier to read, though I would remove the assignments in the conditionals.
It probably doesn't matter in a probe routine, but in code that has a really hot path the separation of slow path, error handling code causes less icache line pollution in the hot path, thus maximizing performance in the normal case.
Now as to your experience with the differences in British vs American english and an unintentional insult, did you apologize? Did you go "I'm sorry, I was unaware and didn't mean to cause an insult"?
Something like that, except I did a lot more groveling. I had no intention of causing insult.
Actually, because they are changing the old world landscape anyway, adding support for flying (basically filling every part of the map) shouldn't be a huge amount of extra work.
I'm only citing blue posts from their own forum.
I think you're right and I also think that they've done a ton of work on their own internal editing tools that help them design landscape which will incidentally allow them to design a whole lot more in-game spaces quicker.
According to what I read on the forum earlier today, the stuff they demoed at Blizzcon last weekend was in better shape than when they demoed WotLK at the previous Blizzcon, which likely means that Cataclysm is going to come sooner than most of us expect.
Slashdot Mirror
I call BS. 2009 attendance data (to date) - Best are the Yankees, with a 45K per game average.
Yeah, and the LA Dodgers are #2 only a couple of hundred tickets behind. Dodger Stadium is very cool, though a pain to drive into.
I had my worst baseball experience ever there. My father took us to a game against the Braves to watch Hank Aaron play and we got to the game late and missed his early inning home run ... :-(
And my best experience taking a friend to Jingu who knew nothing about baseball, let alone NPB and pointing at Alex Ramirez and Roberto Petagine during the pregame warmup and saying I want to see those guys hit home runs and they did, Petagine's being the game winning run. :-)
Trust me, just about nobody does baseball at this point.
A baseball game in a good stadium is good fun, though expensive. I note that the LA Dodgers are #2 in average attendance so far this season. Dodger Stadium, ground level, is a wonderful place to watch a game. As is Jingu Stadium (Yakult Swallows), except Jingu is better as the Swallows are underappreciated and good seats are always available.
Get out of your mother's basement sometime, live a little. Baseball is a nerdy game. The very first computer program I ever wrote (on a hard copy terminal and saved to paper tape) computed baseball league standings.
If the concentration is so dilute that you can't smell it, then the molecules, even if yes, they really are floating in the air, aren't in plain view. Just like if you have your drugs inside a cardboard box
Interesting point. Haven't we been told that a significant amount of US currency has detectable traces of cocaine on it?
A police dog can decide your vehicle has drugs or whatever else they're looking for and when the dog starts barking, suddenly the officer has a perfectly legal search.
That's kind of sad. I've seen the dogs "hired" after Superferry 14 http://globaljihad.net/view_page.asp?id=528 and they just seem more interested in finding food in baggage than bombs.
I find it amusing that someone would go to such lengths to forge US Government correspondence but not bother to run spell check and/or proof read the letter.
I find it amusing that someone could be found to code up an auto execute function for inserted media. I find it even more amusing that there was a stupid enough manager to sign off on it.
Was Dilbert written at Microsoft?
"This planet should spiral inwards on such a short time scale that the likelihood of seeing it is very low," said Coel Hellier, an astrophysicist at Keele.
Oh ye of little faith ...
Maybe we're just getting better at observing our surroundings?
Why resort to namecalling?
Yeah, I felt ashamed about that. I offer my humble apologies.
There's been too much name calling on both sides. Dijkstra's original comment regarding programmers who had not been taught structured languages from the start still burns me ...
Again, my humble apologies.
I really wish snprintf was available on my C implementation.
You still have %*.*s, just pick 125 for all of them and you won't overflow. What kind of person has (or has parents who would give him) a name Christian or family longer than that?
I was so taken aback that I probably just stared at him for a few seconds. Then, I stupidly said "So... You want to see my code?" but he was like "No, the result is correct, and your implementation is very fast, so I don't need to see the code. Good job. Send in the next guy."
This is so sad. He notices your code is faster and he's not the least bit curious? (I presume he's some kind of CS prof.) Anyway, good for you, but still... :-(
Yeah, sad. When I was demoing my OS class project I was told that it was the best project they had seen in a decade and a half of teaching the course and could they please keep a copy of the source. Which absolutely worked for me. I got it done so fast I had time to implement online help in the shell which rather stunned them.
This was in HP-1000 assembly and the main display was a row of LEDs on the front. I arranged my idle task to flash different LEDs as it got scheduled. The TA had earlier issued a challenge (for someone like me) that he liked to crank the timer up to max and watch student projects crash (the HP-1000 had 3 possible time intervals and the fastest interval was very fast). I added a command to my shell to allow changing the timer interrupt at run time. The LEDs showed that I was spending a lot of time in the scheduler (I didn't bother to optimize it once I knew it worked) in the shortest timeslice mode. But it worked and the terminals were still responsive.
Absolutely the most fun class I've ever had. The prof even had me teach for a day towards the end of the semester on VMS IPC mechanisms.
One developer I worked with liked using the following for code he wasn't using right away: if (1 == 2).
Don't judge him too harshly. It was possible in early FORTRAN implementations to do `1 = 2' and thus modify a constant making the constant `1' in the source code `2' in the running code. It was a bit more complicated than that, but that was the effect. As I recall, though I can't find it now, people did that to fix last minute bugs when certain "constants" needed to be changed.
http://www.ibiblio.org/pub/languages/fortran/ch1-8.html
Now, had they follow a more linux/apple approach, and released something every 6 months to 1 year, they would have known much soon that they were headed down a bad path, and they would have also been able to get new features into the hands of users much sooner.
It's been about 2 years since 10.5. I am not going to buy 10.6 for awhile and certainly not on Friday.
But let's see. My vital app in Mac OS X is X11 so I can do work. It works great when Apple doesn't break it like they did in 10.5.
Sadly, I have to agree that a long release cycle between O/S versions is probably a good idea.
Since goto need to be paired with a label it's the least evil of the group.
I don't follow that argument. Why wouldn't return, which doesn't need a label because it's always unambiguous, not be less evil?
I don't follow your statement. An IDE can always follow a local goto to its intended target label via `M-.' or whatever. A return is ambiguous as to where flow of control goes next. There's no way that an IDE (or a compiler) has of knowing which routine you want to see the source code of. That's always a runtime issue. The best an IDE can do is present a menu of calling sites in the source code it knows about.
Please see above my example. Sometimes not to use goto is impossible if you also want to avoid duplication of the code.
Hear! Hear! Document it in the comments. You're fine.
Repeated code is *a lot* more of a maintenance nightmare than a few gotos.
Show me your code and I'll show you an alternative.
So what? I guarantee that whatever you come up with will be slower, less readable and hence more expensive to maintain.
Kernel code is the perfect application domain at this time for use of goto for slow path error clean up. And see the example of a proposed structured construct with identical semantics that requires both bottom-to-top and top-to-bottom semantics that I posted earlier.
Many modern languages don't support GOTO, or only include it to support machine generated code (ADA).
Ada is not an acronym. And Ada supports goto because it is a low level systems programming language and kernel code that separates fast path usual case code with error handling slow path code is less error prone and faster.
As you can tell from that, and many other sides, there are no major pros to using GOTOs, but very major negatives.
Um, did you even bother to read that link? He's basically arguing from the same position I am and against dogmatic wankers like you appear to be.
In the remaining one case out of 100 in which a goto is a legitimate solution to the problem, document it clearly and use it.
Seems like a fair statement. Compare that to
GOTOs have no place in man made code.
There's been little argument that most gotos can be replaced with equivalent and convoluted "structured" code. One of my favorite languages (Icon) does not have goto. It has a rich set of control structures that permit you to do pretty much what you need to do. Its functional domain does not require the use case of whittling clock cycles off of interrupt handlers.
No need for goto, though occasionally it comes in handy.
Congratulations. You have just implemented goto with a variable assignment. How is that any more readable than a plain goto?
If that switch statement is of any size, you will be forced to check the code after it before going to the next state when manually tracing execution. It's not any cleaner than straight gotos and arguably worse (extra levels of indentation). Now if there is actually code that needs to be done in between state transitions, then you're better off.
The key is not that all uses of goto are harmful. The key is "if I use goto, is my code more or less fragile when the next guy comes along to maintain it?" Fragile code is guaranteed to be broken and often times, obeying top to bottom, no multiple exit points, no break or continue, multiple flag variables to track state and deeply nested if-then-elses is the most fragile code of all if it needs to be modified. I believe I'll write a journal entry about that. Hello Ron Louie if you're reading this.
As long as the gotos only go down, i.e. like a return or break, there is no spaghetti code.
The Ada guys seem to agree with you on that. Break, but no continue. I don't personally have any issues with continue. In code that's a spaghetti of deeply nested if-then-elses mixed with loops, it can be somewhat difficult to see where they go to next, but the same can be said of break too.
If you regard language features as âjustâ(TM) syntactic sugar, why arenâ(TM)t you programming in raw machine code?
If-then-else, do-while, for, etc. are syntactic sugar. They can all be rewritten fairly cleanly with gotos. See http://www.amazon.com/Elements-Programming-Style-Brian-Kernighan/dp/0070342075
The issue has always been unstructured use of goto. The difference is that with a formal control structure you have strict rules as to when there is a goto (as to the else clause). With a goto you have to read a bit harder to see what is happening because it's usage is not guaranteed to be structured.
They called it Structured Programming for a reason, but it's still syntactic sugar.
wouldn't a switch be just as easy? just leave out the break in each section and it'll flow through everything below it
The semantics on switch are not correct. Think of it as a computed goto.
Now if you had a dynamic switch, with the cases computed bottom to top, you would have the correct semantics.
reverseswitch {
case ret = initialize4():
unwind4();
case ret = initialize3();
unwind3();
case ret = initialize2();
unwind2();
case ret = initialize1();
unwind1();
return ret;
}
Now, if the individual cases are evaluated bottom to top (oops, just violated the top to bottom rule), then that would give the correct semantics.
So now, we have mixed orders of execution, bottom up in the case of the evaluation of the different cases and top down in the case of the error unwind. Which is exactly what we want. Is this any easier to read than the gotos?
I suppose we could count on the compiler to separate out the unwind logic. We want the machine to execute the equivalent code with gotos, not necessarily have to look at it.
And so on ... it basically gets you exception handling formatted code. Of course, goto is probably still cleaner :)
Yeah. Where is execution intended to go after the if() at the bottom of the while() fails? I also fail to see how unwinding occurs.
Personally, I find free variables a lot more irritating than an occasional goto, even if the goto is not very well thought out.
+1
It's not. But nor is code that uses goto in the idiom that FourthAge posted above.
My objection to that code is that if you do even just three or four allocations, you start getting very large indentations pretty fast, especially if you like 8-character indentations [sourceforge.jp]. (They get pretty long even with 4, which is what I like!) This causes a problem if you restrict yourself to 80-columns [sourceforge.jp].
Arguably this is a problem with restricting yourself to 80 columns,
For me, these are the main reasons I love having both of those restrictions. It forces one to keep nested ifs to a minimum, the bane of testing and reading comprehension.
Now it is time for a language designer to step up to the plate. We know what kind of control structure we want - code that compiles into something as icache friendly as the geode driver. It's not going to be exceptions. Even with exception support in Ada, it was still deemed necessary to have goto. Exceptions are fairly heavy weight since potentially stack frame unwinding must done (which implies additional runtime code when only a simple goto is needed).
There is not much difference between "return 0;" and "ret=0; goto exit_function;".
Indeed.
Both are unconditional jumps there is no rational reason why one should be "considered harmful" and the other not.
The most anal of the anal retentives of the goto-less persuasion do indeed consider them the same and consider both harmful. Wirth's original Pascal did not have a return for that reason. I'm not sure why he allowed a goto and no return. He later reversed himself in Modula II where he added return, but removed goto.
Languages that provide a rich set of control structures (an if statement has an implied goto too) do not need goto. Icon (my favorite language for recreational coding) http://www.cs.arizona.edu/icon/refernce/ref.htm does not need a goto. Neither does the Unix shell.
Low level languages intended for systems programming do need a goto for the reason I noted above - every prefetched byte in the icache counts and you DO NOT want to mix slow path error handling code in with hot path usual case code. Even Ada, which otherwise frowns at non-local flow of control, provides a goto.
To me, nested ifs are much easier to read - they convey the meaning/intent of the code a lot better. As in 'if this function call works, then do this. Otherwise, just clean up and exit'
Besides the excessive indentation, my mind starts to swim in a wall of close braces. More than something like 2 levels of nested ifs is hard to read, in my opinion. Indeed, I find the original version easier to read, though I would remove the assignments in the conditionals.
It probably doesn't matter in a probe routine, but in code that has a really hot path the separation of slow path, error handling code causes less icache line pollution in the hot path, thus maximizing performance in the normal case.
Now as to your experience with the differences in British vs American english and an unintentional insult, did you apologize? Did you go "I'm sorry, I was unaware and didn't mean to cause an insult"?
Something like that, except I did a lot more groveling. I had no intention of causing insult.
Actually, because they are changing the old world landscape anyway, adding support for flying (basically filling every part of the map) shouldn't be a huge amount of extra work.
I'm only citing blue posts from their own forum.
I think you're right and I also think that they've done a ton of work on their own internal editing tools that help them design landscape which will incidentally allow them to design a whole lot more in-game spaces quicker.
According to what I read on the forum earlier today, the stuff they demoed at Blizzcon last weekend was in better shape than when they demoed WotLK at the previous Blizzcon, which likely means that Cataclysm is going to come sooner than most of us expect.