|
I don't think we need to discuss that the lack of process control is bad, and unless we somehow manage to improve that situation in the company or at least department, then, yes, your own contributions and efforts may be wasted.
I probably was lucky to work in companies that either valued my opinion (on this matter) or already did practice process control at a satisfactory level. I understand that this is the exception rather than the rule: I keep reading studies about the bad rates of success of software projects, hinting at how bad process control is elsewhere.
We seem to be agreeing, generally, it just seems I'm more optimistic about the effect of my efforts. Whether this is justified or just a projection of my generally good experience - time will tell. Until then I wish you a share of my good experiences - if not in your current job, maybe you can find another in a company that actually values process control and your contributions!
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: I probably was lucky to work in companies that either valued my opinion (on this
matter) or already did practice process control at a satisfactory level.
Ok, but note that my original point specifically pointed out that if the process control wasn't in place then that is where the problems came from.
And you also said the following in a different sub-thread "But it was nigh impossible to disentangle the mass of conditional code and goto statements (few as there were)... I'm not saying that the goto statements were the sole reason for the sorry, unmaintainable state of the code, but they were the main reason why I was unable to transform it into something maintainable!"
And in the context of that statement it would suggest to me that in that company one of the following would seem to be true.
- There was no process control
- The process control was basically ineffective (regardless of what the employees thought of it.)
- At some point in time those gotos were considered proper and correct. (As for this one then hindsight is not a rational basis to condemn the previous determination.)
And the first two of those conditions is what the vast majority of the industry is in. And if one of the first two then you have experienced at least indirectly what it is like.
|
|
|
|
|
Stephan_Lang wrote:
"The main reason however that you shouldn't use goto is that there is no benefit. Over the past 30 years I've used, learned about, read about, and had plenty of discussions about goto. In all that time I've never heard or read one compelling argument in favor of using it. Yes, you can use it to reduce or avoid nesting, or otherwise reduce the amount of code. But that by itself is not a valid argument in my book."
Over the past 39 years, I've never used a goto in C or C++. I did use the goto in Basic. My first computer only had GWBasic and assembly language.
Some situations where there is a benefit to a using goto are mentioned in Hopkin's 1979 paper, "A Case For The Goto", which I believe was written in response to Dijkstra's paper, "A Case Against The Goto". Even with modern compiler optimizations, the examples in both papers still apply today.
I would, and have, gone to extreme lengths to avoid using a goto, for the reasons you mentioned. Even when I've had to jump out of the center of multiple nested loops, I used an exit-flag and an if-statement with a break after each loop. Still, there is no question that this is a bit slower than using a goto to jump out of the center.
I have coded many real-time Digital Signal Processing algorithms with streaming data. Often these algorithms must be fast enough to keep up with the input data stream. In some cases, I have had to write special assembly code routines for some calculations, otherwise the algorithm couldn't keep up with the input data. Unfortunately, unlike the C language, assembly language isn't portable.
Using a goto is likely to only result in a very small speed increase. I doubt that using a goto is typically justified, if it is ever justified. Still, there can be a benefit to using one, and I acknowledge that there might be some fringe case where, after other necessary algorithm and implementation optimizations have been done, using a goto is warranted. Thus I reject any dogmatic statement to the contrary.
I say, as a general rule, use all possible techniques to avoid using a goto. I've always been able to avoid the goto. You can probably avoid the goto too.
Check out one of the links in my first message in this thread where issue of dogma and the 'goto' is addressed. I also showed a loop construct as a way to avoid using a goto in some situations in that message.
modified 11-Nov-13 23:56pm.
|
|
|
|
|
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.
|
|
|
|
|
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)
|
|
|
|
|
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.
|
|
|
|
|
Remember
goto is a four letter word and bad things will happen if you use it...
|
|
|
|
|
No. Simple as that. the only reason to use goto is to write bad code 
|
|
|
|
|
You are so ignorant. Mind explaining, is the OCaml byte code interpreter really can be dismissed as an example of a "bad code"? Or you simply failed to think of this particular way of using goto?
|
|
|
|
|
and i thought this must be a trolling competition- i mean the goto debate is over for decades now.
seriously- there are many arguments against gotos (as already posted in this thread) and i have yet to find problems better solved with goto instead of proper object orientation.
ad bad code: working code != good code. that code works is the foremost and basic assumption- good code easily readable, understandable, maintainable and extensible- all things where goto brings nothing to the table- on the contrary it may (and has) severely hinders it...
|
|
|
|
|
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[^]
modified 12-Nov-13 6:54am.
|
|
|
|
|
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)
|
|
|
|
|
As expected, a moron just managed to prove his complete lack of ability to think. Applause!
You're incompetent. Admit it. People like you should not be allowed to code.
|
|
|
|
|
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.
|
|
|
|
|
Most of the first and second-generation languages were conceptually founded on some problem-oriented model. In focusing on a particular problem space, they tended to neglect other considerations. One result was that many languages were merely "assembler with better syntax" -- and the GOTO or branch instruction is impossible to do without in that scheme.
Third-generation languages such as Algol and C began the move away from a hard problem orientation. They focused on other desiderata, such as structure and legibility. With the expansion in the variety of conditional and iterative control structures they offered, the GOTO became less necessary. That caused Dijkstra and others to study the relation between the GOTO and legible / comprehensible program design, and to reach the conclusion that the GOTO is harmful in the great majority of cases.
All that having been said, there are still occasions when writing a GOTO is better practice than what it would take to avoid it. Indeed, some such cases involve using a GOTO to improve legibility and maintainability; transfer of control to a procedure's error handling exit is sometimes like that. However, it's best to be biased against GOTO, and to use it reluctantly, because 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.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Fran Porretto wrote: 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.
Ooooh, I like that! Can I use it in my sig? 
|
|
|
|
|
(chuckle) Feel free. It was spontaneous, but the more I ponder it, the more accurate it seems!
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Yes, I can agree that the goto statement can be confusing and I've never found a good use for it. However what is the difference between a goto and a exceptions? Exceptions are only suppose to be used for things that should never happen. Most of the time that I've seen them used for all error-handling methods. (E.G. Invalid user input) However I find throwing exceptions for this purpose, even with the performance hit, useful. It keeps the code cleaner and shows the next guy what I expect to happen. Just wondering what you thought?
P.S. I once worked in a 4k memory space divided into 2 sections. The only way to get to the second memory space was with a goto statement.
|
|
|
|
|
In 1974, my manager asked me to evaluate the new, highly touted discipline called "structured programming."
I was skeptical. At that time, I was programming in COBOL. In those days, COBOL was somewhat deficient in the amount of control structures provided. I had not yet read Bohm and Jacopini so I had no idea that the control structures of COBOL were more than adequate for the task. I suggested that I wait to perform a structured programming experiment until a new project came along.
In July, I was assigned a new project. The Chief of Naval Operations (CNO) Budget Office was in need of a text editor that could edit the descriptive portions of records in an indexed sequential file. The program would be developed and executed on a Unisys 1106 main frame computer. Unfortunately, the Budget Office also knew about the University of Maryland Text Editor (med) which, for all intents and purposes, replaced the Unisys provided editor (ed). The Budget Office wanted the interface to be "just like med" a seemingly impossible job for the short project time (three months). Fortunately, I found that med contained an API that would allow me to use the editor against the textual fields of the indexed sequential file.
So it began. For this project I could not use a GOTO statement, a standard tool of the COBOL programmer of those days. I struggled with the problem. It wasn't that the solution was difficult; the solution was difficult without using GOTOs. Finally, in September, I finished. When queried by my manager, I told him that the programming effort took longer than it would have had I not used the structured programming paradigm. We agreed that, even though some rather impressive academians had suggested that structured programming was the way to go, we would shelve further use of the method. I placed the code listing in one of the drawers of my desk and returned to programming in my normal unstructured way.
Then, in December, I received a call from the CNO production office. It appeared that a program that I had written had blown up. The production office provided the symptoms and the name of the program. I looked in my drawer and found the flawed program. When I opened the listing, I realized that this was the program that I had struggled with. As I reviewed the code, in light of the comments provided by the production office, the bug just seemed to jump from the page. It was such a simple error. But had I written the code in my normal manner, I would never have found the problem so quickly. After about fifteen minutes, during which I recoded, recompiled, and rebuilt the software, I called the production office and advised them that the software was ready for reinstallation. Neither they nor I could believe how quickly the bug was found and fixed.
Since that December day in 1974, I haven't used a GOTO statement in my work (excluding assembler, of course).
Gus Gustafson
|
|
|
|
|
Because they are ignorant idiots. Goto is absolutely essential in a number of cases. Most notable are:
- Implementing state machines. The closest construction to state transition is goto, so it must be expressed as goto.
- Various generated code (from higher level languages/DSLs)
|
|
|
|
|
gotos are definitly not essential for state machines. there are a number of patters and frameworks that are a better solution than goto hell.
if this code has higher level languages as output then i dont believe gotos are required but if the code is not touched by human hands...
|
|
|
|
|
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)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
