|
Stefan_Lang wrote: No exception. And IMHO it would have been a net gain every single time.
And presumably other problems would have been corrected as well. Thus one process control process which would have impacted that along with other problems would have eliminated many problems. Yet it wasn't in place. So an example of a chaotic development environment of which the use of goto was very likely a minor problem.
|
|
|
|
|
My point wasn't about process control (or the lack thereof) some unspecified time ago, it was about process control being in place and effective at the time I was working there. I totally agree that 20-30 years ago process control had quite a different quality.
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: My point wasn't about process control...
Thought my original post was clear...the culture that leads to the inappropriate use of goto is one that is going to have other problems, including in code, which will be more serious than the use of goto.
|
|
|
|
|
jschell wrote: greater than 99%, relies on chaos for their process control.
That doesn't match my experience. At all. Every company I worked for, was contracted to, or was in contact with as a client used some sort of process control. In many cases mostly through paperwork and manually entering hand-written reports into a database. I know this is quite different in other countries (I lived and worked in germany and switzerland), so you may have a point depending on what country you look at.
But we're going off-topic here: the important point is that goto has an increased risk of causing lower quality pruducts and higher maintenance cost - whether or not your company successfully applies process control shouldn't matter to you - all you can and should do is improve it on the level that you can affect!
As for you're working experience with process control I clearly have been more lucky (sometimes too much so: I do hate SAP!  ). But as stated above: don't let the quality of process control )or lack thereof) in your company sidetrack you from producing high quality 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: Every company I worked for, was contracted to, or was in contact with as a
client used some sort of process control
I have also worked with companies that claimed to use process control. I have however also read a great deal, including actual studies, about processes and real (measured) benefits that companies that are strongly dedicated to process control achieve. And I have never seen much less worked for or with a company that was even close to what was actually possible.
Stefan_Lang wrote: your company successfully applies process control shouldn't matter to you
Again though the point is that such companies have more serious problems.
Stefan_Lang wrote: sidetrack you from producing high quality code
This thread has nothing to do with the code that I produce.
|
|
|
|
|
jschell wrote: I have never [...] worked for [] a company that was even close to what was actually possible.
I have, in the 90s. At first the company did use various processes in their departments with equally varying rates of success. But there was little process control behind it, and few synergies and overall organisation over the whole company.
Then the management pushed to introduce a software ISO certification (which at the time they started didn't even exist - they cooperated with the certificate institute to actually create it). Over the course of about 3-4 years the new company-wide standards and process was in place, and the improvements were huge. It was an eye-opener if I've ever seen one.
Since then I'm a believer in process control, on all levels of a company. It's true that few companies ever reach that level of control I've witnessed back then, but that doesn't mean you should stop trying to improve processes on the levels that you can effect.
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: ...ISO certification (which at the time they started didn't even exist - they
cooperated with the certificate institute to actually create it). Over the
course of about 3-4 years the new company-wide standards and process was in
place, and the improvements were huge. It was an eye-opener if I've ever seen
one.
Not surprising to me.
Stefan_Lang wrote: Since then I'm a believer in process control
Great. Doesn't alter what I said however. The vast, vast majority of companies are not ISO certified. Matter of fact it is quite possible that 'fewer' companies seek such certification now as versus when you encountered it. That is very definitely the case for CMM certification. Keep in mind that I am not referring to business domains where those types of certification might be required to get business but rather the entire software industry.
Stefan_Lang wrote: but that doesn't mean you should stop trying to improve processes on the levels
that you can effect.
It does however mean that the overall impact within a company is that it will still remain in the 'chaos' level which means that in most (vast, vast) majority of cases that any attempts will never rise above the noise level.
And AGAIN noting that this has nothing to do with code/designs that I produce but rather it has to do with the overall 'goodness' of the software process and what one can expect in terms of that within a company. One might claim that X is better but everyone else in the company will have their own idea what X is and each will strive to maximize that. And since the industry as a whole can be said to have no real process control consequently, per my original comments, any single version of X is so inconsequential that it is pointless to attempt to suggest that it by itself is significant. Because it isn't significant. What is significant is the lack of complete process control.
|
|
|
|
|
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? 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
