goto statement
-
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
OCaml is a live, thriving project with many new contributors. It's perfectly maintainable, and, in my books, an example of the perfect C coding style. Linux has megabytes of commits every week. Far from being "dead for decades". So, what are you talking about? What's the point of generating code which is perfectly readable anyway? State transition is, essentially, goto. Any higher level language will feature the semantically equivalent construction to represent state transitions. Yes, arrows in your UML are not any different from goto.
-
I may be bordering on dogma, but as I stated above, I've never seen any good C/C++ example where using goto was the better alternative - at best you could argue that it wasn't conceivably worse than using standard control statements. That's not to say that there aren't examples in favor of goto, in C/C++ or other languages. I just haven't seen any yet.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
OCaml is a live, thriving project with many new contributors. It's perfectly maintainable, and, in my books, an example of the perfect C coding style. Linux has megabytes of commits every week. Far from being "dead for decades". So, what are you talking about? What's the point of generating code which is perfectly readable anyway? State transition is, essentially, goto. Any higher level language will feature the semantically equivalent construction to represent state transitions. Yes, arrows in your UML are not any different from goto.
-
Goto "debate" is not over. Dijkstra had a bit of trolling, and now hordes of incompetent dummies are taking his jokes as some kind of sacred revelation. There are *no* arguments against goto, besides complete ignorance of the opponents. I pointed to several code examples which absolutely *must* use goto. And you, goto haters, as usual, ignored the uncomfortable truth. Mind explaining, how would you rewrite OCaml bytecode interpreter without goto? Code is here, in case if goto haters are as low as I suspect and cannot even use google: https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c[^] And please, mind explaining, how exactly this Knuth's code is "unreadable": http://www.literateprogramming.com/adventure.pdf[^]
vl2 wrote:
hordes of incompetent dummies
says who?
vl2 wrote:
There are *no* arguments against goto
At this point the discussion with you is over. I did make the mistake of spending time to look into some of the things you linked to, because I was genuinly interested in good examples in favor of goto. But now I realize you are but a troll. BTW, most of Knuth's code is unreadable by todays standards. Welcome to the third millenium.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Mind naming a language feature which is semantically closer to the notion of "state transition" than a simple goto?
switch
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
switch
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
No way. Switch is semantically more complex, and if you want to implement state machine over it, you need to introduce additional entities - namely, current state variable. And, in case of C, there is a horrible way to fail by forgetting a break statement - which also has nothing to do with the essence of a mere state transition.
-
vl2 wrote:
hordes of incompetent dummies
says who?
vl2 wrote:
There are *no* arguments against goto
At this point the discussion with you is over. I did make the mistake of spending time to look into some of the things you linked to, because I was genuinly interested in good examples in favor of goto. But now I realize you are but a troll. BTW, most of Knuth's code is unreadable by todays standards. Welcome to the third millenium.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
of ocaml is your idea of perfect coding style we have very different views how good codes looks or reads.
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
-
I have read "Modern C++ Design" by Andrei Alexandrescu, which covers template metaprogramming in great detail. I use it, however, I don't use it when there is a simpler solution. In this case, the code is auto-generated by another program that writes the entire file. Also, the code I posted is written in C#, not C++.
I was aware this was C#, I was simply saying that this is an area where templates (as opposed to generics) pay dividends.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
-
Because in nearly every case I have seen of it's use in C# or C++ it has been unnecessary, and only served to both confuse the code and show that the person who used it did not understand what he was doing.
gotois not evil - but it is a "rule breaker" in that it violates all the principles of good code design and so using it should only be done with care. The problem is that it it taught on courses by lazy tutors as an easy way to get them started and then gets abused later because the students consider it "Normal" and don't learn to structure code well in the first place as a result. If you had grown up withGOTOas pretty much the only form of flow control (as I did) you would probably understand how easy it is to create impenetrable code with it, and why it should be discouraged until the coder is experienced enough to know when it is appropriate. About five years of "real" coding should be enough. But by then, he is probably experienced enough to know that there are probably better ways to achieve the same result...The only instant messaging I do involves my middle finger. English doesn't borrow from other languages. English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
It (goto) is unattractive certainly, and it's usage rightly deprecated. But for my money it's a mere misdemeanour compared to the worst sin in programming, namely global data. There are developers who would rather eat their own limbs than use a goto, yet happily employ global variables with lavish abandon, supremely oblivious to the misery they are imposing on those who inherit their code. I'm currently engaged in modifying a legacy VB6 app comprising around half a million lines of code. The many goto's therein are tiresome but just about tolerable. The multitude of global variables, all absolutely unnecessary, all toxic in the extreme, guarantee that an innocent change in one source file results in incomprehensible failures in a dozen others. I'll happily deal with all the goto's a naive developer cares to throw at me, if they would just understand and apply the simple notions of encapsulation and data hiding. Not that I'm justifying the goto mind, but there are far, far worse offences.
-
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
vl2 wrote:
You'll never be able to implement a bytecode interpreter faster than this one.
One however might suppose that there are at least a couple of programming jobs out there where one does not need to implement a byte code interpreter though. Might even be a few lines of code from those jobs that maybe one or two other developers might need to maintain in the future as well. And none of which where optimal performance is a goal or even a requirement.
-
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
None of which however addresses whether those generated solutions are optimal performance implementations. In my experience performance optimization, based on actual bottleneck analysis, can often lead to code that is less than ideal in some other aspect such as design and/or maintenance.
-
Tools can only get you so far, and they're not suitable for prooving code correctness. So I'm not sure why you brought that up. As for benefits, I've read and taken part in countless discussions, and not a single example brought up managed to convince me. In every single case there was a suitable alternative using standard control statements. Most of the time the person bringing up either didn't come up with the proper way, or considered the effort of writing 2-5 additional lines of code too much to bear. Based on that experience I'm convinced that there is always a better alternative. People claiming otherwise are just not sufficiently experienced to see it, or understand the need. That said, all this assumes you're looking at code where proper coding guidelines and style even makes sense to take care of: if you're just programming away a piece of throw-away-code, then yes, use whatever suits you best and solves the problem. In actual production code that is going to live through years of maintenance and adding features, the presumed benefits of goto never outweigh the long term maintenance problems.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
Based on that experience I'm convinced that there is always a better alternative.
Could be. But I don't write code for fun but rather I get paid for it and it is often critical code that I can't spend weeks finding an optimal solution but rather the first one that is good enough goes out the door. Nor can I refactor millions of lines of code every two weeks every time I figure out a "better" way to do it. And neither can the guy that is going to maintain my code after I am gone.
Stefan_Lang wrote:
People claiming otherwise are just not sufficiently experienced to see it, or understand the need.
Of course there are always people willing to rationalize that their way is "best" despite the fact that they can't demonstrate that with objective data and often can't even construct a coherent argument as to why it is "best". And technology rationalizations are often based on nothing but technology while ignoring the realities of delivering software in a business environment.
Stefan_Lang wrote:
In actual production code that is going to live through years of maintenance and adding features, the presumed benefits of goto never outweigh the long term maintenance problems.
That would of course be an excellent argument if in fact none of the following was true. - Maintenance was the sole and only driving business requirement. - The business had a firm enough grasp on process control to be able to quantify maintenance costs. - The process control was structured enough that it could enforce quality on the entire rest of the enterprise and to such an extent that the trivial cost of infrequent code misuse rose above the most miniscule noise level of maintenance cost. Versus for example, no requirements, poor requirements, unused requirements, invalid requirements, zero architecture, chaotic process management, etc, etc, etc.
-
My point wasn't about code that died decades ago, but code that continued to live and be modified over decades! Readability is just one aspect, maintainability is more important. Besides, the author himself stated in the comments that his reason for using goto was implementing multistate transitions. Come on! I've used tools to generate those automatically from UML 10 years ago! And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
We essentially agree that gotos are undesirable the vast majority of the time. I'm just not positive that gotos are bad all of the time. One can develop tunnel realities, even with decades of experience. Take the saying at the end of your post: "GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)" While I expect that is often the case, I would think it untrue in some situations. If a well-managed team were to find a reason to use a goto, and the team had guidelines that were documented in the code around the goto to not do this elsewhere, then I don't think that goto's would necessarily proliferate. But again, I've always used break or continue and avoided them too, and I agree with your philosophies, just not the absolutist part of your philosophy. I don't know absolutely every situation for ever program in every context, and there actually is a documented benefit to gotos in some circumstances. Even though there can be dire consequences from using a single goto, nonetheless the tradeoff might be that without using a goto, something isn't fast enough to do that job. In that case, the developer might decide that practicality takes precedence over good software engineering. I can't prove that situation doesn't exist. So I can't be absolute about the rule. I don't get that someone posted that goto's were needed for a state machine. A switch statement works, and there are other solutions too. The book "Design Patterns" provides the Strategy pattern, which (and I expect you know this already Stefan) where different "state" classes derive from a common base class, and switching states is done by switching the type of object. Virtual methods are called on the current state object. And, except in rare instances, I suspect a goto isn't much faster than well-written code, and probably even slower in some cases. Today, often instruction cache fetch limitations, data cache fetch limitations, or instruction ordering (the last less of an issue with modern Intel compilers than it used to be) affect performance more than the number of instructions in the code path. (I know you know this too). So, in general, the only way today to find out if code is faster is to profile the code. (Note, I wrote "in general" there - of course there are exceptions). I would need pretty strong proof in a particular situation to even consider that using a got
-
Ah, let me guess, your brain is mutilated by that pathetic OOP thingy? Ok. Carry on writing your buggy, slow, unreadable code. But do not lecture the real programmers on how to do things the right way. You'll never be able to implement a bytecode interpreter faster than this one.
Look, I disagree with the absolutist position too, but I agree that using goto's is generally bad. I just acknowledge there might be exceptions. But, having worked on code with gotos, which I did not write, but I had to maintain it, and having worked on object-oriented code, in my experience the code with gotos had both many more bugs and also worse bugs. I've had this same experience in more than one job too, so I see that as a recurring pattern. And, I've also seen object-oriented code that was faster than the older C code. Efficiency has to do with many other factors than the language used. If only encapsulation is used in C++, there is no calling penalty and the generated code is essentially C code. And, 'often' the overhead of calling virtual functions is typically less than using a 'switch' statements, so if the setting that is being tested is in a loop, doing the switch statement outside of the loop and choosing an object with a virtual function based on the switch results can be much faster. In C, you can do that same thing with function pointers, but it's more complicated, and people don't typically write code that way in C. In C++. it's very simple to do that, plus, there are other benefits. Here's another issue about performance unrelated to the language used: I once unrolled a loop for a floating point routine and the code got significantly faster. I did the same thing for a routine that did the same calculations, but was for a different processor. That routine used integer arithmetic. When I unrolled the loop, the routine got much slower! The integer routine required shifting the products down after every multiplication. These extra shift instructions made the code grow to over 4Kbytes, and 4Kbytes is the size of the instruction cache. The code was cache-thrashing. I've seen the pattern of people imagining their code was faster than some other implementation, when a profiler later showed that the other implementation was actually faster. Modern systems do multiple levels of caching for both instructions and data, do branch prediction, and even do instruction reordering based on both the instruction types and register pressure. Predicting how fast code will run is more complicated today than it ever was. Without using a profiler, it's usually just guesswork. Finally, languages are tools. Use the right tool for the job. If you think object-oriented languages are slow and buggy, then you definitely don't understand them. Also, performance is not always the most
-
Stefan_Lang wrote:
And I could even choose if I wanted to generate the statemachine using swicth or inheritance! In other words, there are valid alternatives and even tools that help you generate the code.
None of which however addresses whether those generated solutions are optimal performance implementations. In my experience performance optimization, based on actual bottleneck analysis, can often lead to code that is less than ideal in some other aspect such as design and/or maintenance.
Please tell us about your experience. In some projects I worked on, there was UI code, audio code, and video code. The video code was the bottleneck. I can't imagine it making any sense to change the design of the system to fix the video code. Nor was the overall design of the video codec redesigned. Only minor implementation changes were made. And, ironically, using a goto for performance optimization is often an example of code that is less than ideal. (Note, I didn't write "always" - I can't know that because I don't know all possible situations - and sometimes that last tiny bit of performance gain does matter - but such situations are certainly extremely rare). As an aside, to make a generalization (and most generalizations are false, including this one!), the overall concern for code should be maintainability. Typically, 85% of the cost (or time) for software is maintenance, so making code easy to maintain usually should overrides all other concerns. Also, for most software, performance isn't an issue. So, if a goto is ever justified, it would have to be in a fringe case.
-
Threaded OCaml bytecode interpreter is several times faster than the switch-based one. Far from being "a very small speed increase".
Yes, but I wrote: "Using a goto is likely to only result in a very small speed increase." (Of course, that is only in specific situations, as listed in the paper I mentioned earlier by Hopkins). I did not write anything at all to refute what you wrote.
-
Are you deliberately avoiding commenting on OCaml bytecode interpreter example? Show me the "better alternative", or admit that your so called "experience" is deeply flawed and very limited.
You replied to me, not Stefan. Or it might be that you're arguing about switch statements when this topic is about the goto. Since you haven't written that the OCaml bytecode interpreter uses gotos, it's not clear where you're going. Plus, is there only one difference between the two implementations. How does this compare to using virtual functions to represent state. Perhaps that would be faster still.
-
Goto "debate" is not over. Dijkstra had a bit of trolling, and now hordes of incompetent dummies are taking his jokes as some kind of sacred revelation. There are *no* arguments against goto, besides complete ignorance of the opponents. I pointed to several code examples which absolutely *must* use goto. And you, goto haters, as usual, ignored the uncomfortable truth. Mind explaining, how would you rewrite OCaml bytecode interpreter without goto? Code is here, in case if goto haters are as low as I suspect and cannot even use google: https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c[^] And please, mind explaining, how exactly this Knuth's code is "unreadable": http://www.literateprogramming.com/adventure.pdf[^]
Of course there are arguments against using the goto. Have you actually read Dijkstra's paper? I did, and it was not a joke. I also read Hopkin's paper, "A Case For The Goto". That was a serious paper too.
