Gotoless programming
-
I agree on the state machine. Each state has one subroutine for it. Each subroutine could transition to one or more states. Simple, concise. How (and why) would a goto improve this? Other thoughts In assembly, ever high level loop is implemented with gotos/branches. Java does not have or need a goto because they allow labeled break and continue statements. I don't think C# copied that feature (unfortunately).
Subroutines cause stack push pulls, the goto doesn't which makes it much more efficient. If you want your code to run in an ever shrinking hardware platform world things like that put you in front of the competition.
-
Hmm, looks remarkably like a very basic finite state machine to me 8)
Same for me, this is a state machine!!
-
Agreed. I really don't understand the goto hate, although I've never worked in an environment where it was an issue. There are times when goto makes sense even in modern programming techniques.
When I was a kid, I had a book with a BASIC program that generated mazes. I loved the game, but it was a mess of code. There were GOTOs that led straight to other GOTOs! (Check out line 780.) As an exercise when I got older, I went through and made it structured -- took days! That is why all the GOTO hate. Anyway, using a GOTO on occasion isn't such a big deal. The problem is when it is the backbone of a complex program. And I agree with the person who said very few programmers come across a situation in which GOTO would be the preferred method.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
Is it better to have a ridiculous number of nested levels of "if" statements? Sometimes the inability of having a goto results in a lengthy "elegant" work-around to avoid nesting purgatory.
-
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
CDP1802 wrote:
Thinking and making most of the resources at your disposal is more important than blindly following rules.
Well said. My thoughts exactly. It's a matter of the right tool for the job. This is true in any field of endeavor. You use a spoon when you need one and a front-end loader when you need one of those. You don't just say "never use a spoon" once you've discovered that you have a front-end loader at your disposal. You use whichever one suits the job at hand. GOTO makes sense in a lot of contexts, in others it doesn't. Whatever construct allows you to express the idea in code most elegantly is what you use. I have to laugh at the religious fervor that develops over this particular subject. -Max
-
Subroutines cause stack push pulls, the goto doesn't which makes it much more efficient. If you want your code to run in an ever shrinking hardware platform world things like that put you in front of the competition.
I think his point was that in the end, everything ends translated to gotos by the compiler.
-
Subroutines cause stack push pulls, the goto doesn't which makes it much more efficient. If you want your code to run in an ever shrinking hardware platform world things like that put you in front of the competition.
Deep recursion could potentially stand to be replaced with a goto. The problem as others have mentioned is that it has been heavily abused. And since it usually would only be needed under a limited set of circumstances it's better to just make it off-limits unless someone can make a compelling case for its use.
-
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
When I was a professional Systemprogrammer (Assembler)we were fighting against branches whereever. This because the instruction prefetch which fails when you go out of the straigt forward. Also todays machines do that prefetching and will fail to guess the thread! So avoid going left or right - go straight on.
Jordi
-
Hmm, looks remarkably like a very basic finite state machine to me 8)
Yep, seems like goto used to implement a simple "Case" statement to me too. In fact, "If", "Case", "For", "While" are just patterns captured from observing the repeated use of "Goto"; I would imagine. Thereby simplifying the language so you as the read don't have to search through the connecting statements to realize the "Goto" is just implementing a "While" or "If" pattern. Of course not all conceivable "Goto" pattern has been captured. Consequently, there are no doubt algorithms in which the "Goto" is either necessary or a simplier description than combinations of the aforementioned patterns, as rare as these may be.
-
Deep recursion could potentially stand to be replaced with a goto. The problem as others have mentioned is that it has been heavily abused. And since it usually would only be needed under a limited set of circumstances it's better to just make it off-limits unless someone can make a compelling case for its use.
The key to any job is having the right tool. If we start removing tools because people abuse them we would have to take computers away from people entirely. Just saying ;P
-
Deep recursion could potentially stand to be replaced with a goto. The problem as others have mentioned is that it has been heavily abused. And since it usually would only be needed under a limited set of circumstances it's better to just make it off-limits unless someone can make a compelling case for its use.
-
Is it better to have a ridiculous number of nested levels of "if" statements? Sometimes the inability of having a goto results in a lengthy "elegant" work-around to avoid nesting purgatory.
That sounds like a false choice to me. Do you often find yourself programming a ridiculous number of nested if statements? I often encounter situations with a lengthy series of if statements. But for those, you execute a short code block and return.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
The original point of limiting goto's was lost almost immediately in COBOL where a goto out of a paragraph that was performed would result in a stack overflow or the more harder to debug no-longer-valid stack entry. This type of goto was discouraged for the proper reasons, namely that the program would fail completely or fail to work properly when mixing performs and goto's in this manner. In the effort to promote 'structured programming', this message morphed into "no goto's". This was a much simplified version and promotes code reuseability, although it eliminates the very useful goto beginning-of-paragraph and goto exit-paragraph statements. This 'simplify the message' has carried over to every programming language ever since. Too bad. Charlie
-
Subroutines cause stack push pulls, the goto doesn't which makes it much more efficient. If you want your code to run in an ever shrinking hardware platform world things like that put you in front of the competition.
I've been sitting here cogitating on this. Every switch statement that I write is just a calculated goto. The compiler takes care of all the gubbins behind the scene. brian
a sig? i don't need no stinking sig!
-
I agree on the state machine. Each state has one subroutine for it. Each subroutine could transition to one or more states. Simple, concise. How (and why) would a goto improve this? Other thoughts In assembly, ever high level loop is implemented with gotos/branches. Java does not have or need a goto because they allow labeled break and continue statements. I don't think C# copied that feature (unfortunately).
englebart wrote:
Java does not have or need a goto because they allow labeled break and continue statements. I don't think C# copied that feature (unfortunately).
Incorrect. Not only are break and continue supported, they have been ported with slight syntax changes to VB.Net (e.g. Exit For/Loop, Continue For/Loop). I've used these features in both these environments.
-
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
You have to be pretty ancient to appreciate the goto controversy. I was writing FORTRAN in the mid-sixties and my oh-so-clever programs were an unreadable tangle opf goto's and labels. My initial response to Dijkstra's letter was "program without goto - impossible!". But I soon saw the need for sensible control structures. Also, I see goto-restriction as a high-level language issue. I have never hesitated to use goto (or equivalent) instructions in assembly-language programming - often because there's nothing else. But knowing high-level control structures certainly improved my assembly style.
-
Yep, seems like goto used to implement a simple "Case" statement to me too. In fact, "If", "Case", "For", "While" are just patterns captured from observing the repeated use of "Goto"; I would imagine. Thereby simplifying the language so you as the read don't have to search through the connecting statements to realize the "Goto" is just implementing a "While" or "If" pattern. Of course not all conceivable "Goto" pattern has been captured. Consequently, there are no doubt algorithms in which the "Goto" is either necessary or a simplier description than combinations of the aforementioned patterns, as rare as these may be.
George Dennie wrote:
Of course not all conceivable "Goto" pattern has been captured. Consequently, there are no doubt algorithms in which the "Goto" is either necessary or a simplier description than combinations of the aforementioned patterns, as rare as these may be.
Theoretically, ANY goto can be replaced with a finite state machine. Practically speaking, after ten years of trying I still never eliminated two goto's in a C module that did some rather hairy financial estimation at a former employer of mine, and I did eliminate the other several dozen or so that originally decorated the same module. It wasn't that it couldn't be eliminated, it was that the refactoring necessary to eliminate it was always too painful for the time we wanted to spend. The fact is, though, that it's much easier to teach someone how a piece of structured code works than it is to teach how a piece of spaghetti code works. That same module was one evil monster to troubleshoot when it had its maximum lifetime gotos because it was not structured; I got permission to eliminate the gotos because the original guys who wrote it were gone, and even the owner/entrepeneur who'd come up with the algorithm couldn't explain exactly how the code was doing it, so any attempt to update or enhance it required hours to days of analysis first; after I got done, that time spent went down by at least 90%. When you're not living with a piece of code but simply visit it every now and then, it does not pay to use any technique that you may not be able to understand easily a year or two later, especially if it's not your code but your employer's.
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
Haters being haters again. Sigh. A little historical context might be helpful here. If you never programmed in a circa 1980 BASIC, the language did not provide named subroutines or structured control statements, symbolic labels or indentation. GOTO was all you had. To complain about GOTO in a language that has nothing else is just hating. This code implemented a very structured thing, a finite state machine. It was actually best practice for this language that the states were in subroutines and the GOSUBs in the main loop were all together. Back in the 1960's when many of your moms and dads were children, W Edsgar Dijkstra penned his fameous "GOTO Considered Harmful" article, and Ed Yourdon and others kicked off the "Structured Programming" movement, with its emphasis on single-entry/single-exit programming. (The structured programming movement was a good idea, but it had the same high hype-to-value ratio as Agile does today.) Languages of the day, led by PASCAL, went a little too far, requiring for instance that all functions return out the bottom, so that you often had to use a bit of state to guard if and while statements (WHILE NOT DONE AND ...) so execution would flow down the page and out the end of the function. People used this as evidence that we did so need GOTO. Then C came along with its break, continue, and return statements and relaxed the rules a bit. There were arguments from the SP folks that these statements were a bad thing, but practitioners won the day. There were GOTOs to exit code that returned resources. These, said GOTO fans, were evidence that GOTO was unavoidable. This was mostly hogwash, as you could test most resources to see if they'd been allocated, and only return the ones that were. And the arrival of exception handling and the resource-allocation-is-initialization idiom in C++ rendered that discussion moot. GOTO has few places left to hide. I haven't needed to use a GOTO since 1995, and I have cleaned up many a function by removing GOTOs and fixing up the logic to make it simpler and more correct. I would not miss GOTO if it were removed from C++. It's only there (like many C++ features) for compatibility with old and poorly written C programs. [pours gasoline on the fire]
-
Inspired by the goto comments in the lounge today... Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company. His program had a main loop like: If var = 1 gosub 100 If var = 2 gosub 200 and so on.. and inside each subroutine before leaving, it would set var to whatever it needed to be next. An abstracted goto ! This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
Why use all of those ifs? There is an 'on gosub' statement in a lot of BASIC implementations. Yep, it sure is a horror. Just because goto would be better in this instance does not make goto any less of a horror in my opinion.
-
I can understand it. There are indeed times when
gotomakes sense. The problem is that it is taught to people who do not have the experience to understand when those times are, so use it when a "proper" alternative would be more work. Blame the teachers! I do... :laugh:Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
