Search for a label than a trailing right brace

[AUMathTutor]

Yes Jeff, I think most of it has to do with what you're used to. I'm used to one way of doing things, and it's only natural that somebody with more experience using the GOTO would prefer it.

I wonder if the anti-goto people (I guess I'll throw my lot in with them, though at the end of the day, I'd use a GOTO or the like if it made my life a lot easier) sound as finicky and ante-diluvian to the pro-goto people as the pro-functional paradigm (usually = anti-OO paradigm) people sound to the pro-OO people.

Just out of curiosity, how do you guys feel with regard to that?

And what of studies done regarding the goto? I'll remind everyone that, strictly speaking, these forums aren't about our opinions, however well-reasoned they are. We should really be focusing on facts here... so what are the facts?

 

[D H]

"I use it because it's the right tool for the job."

Back to your old ways, I see. Please use the quote button. Or the multi-quote button. Don't just quote text using quotes.

The same thing can always be done without goto, and whether or not to use it is a matter of taste.

No, it cannot. See the article cited in post #7, repeated here.

Kozen, Dexter and Tseng, Wei-Lung Dustin, "The Böhm–Jacopini Theorem Is False, Propositionally", Lecture Notes in Computer Science, 5133 177-192, Springer-Verlag, 2008
http://ecommons.cornell.edu/handle/1813/9478

"Why? What benefit would there be to restricting goto in such a way?"
Because doing that makes spaghetti code. I cannot imagine any code with gotos going forward and backward that I would want to read. Because to make it not act as a loop, you will need another goto which jumps that goto. And then say you want to go back again. You start getting crossing gotos and nobody likes that.

You are being overly dramatic. Nobody here is advocating a return to 1960's style spaghetti code. The end goal is (or should be) code that is usable, reusable, maintainable, verifiable, ... Spaghetti code has none of those features. Unfortunately, code written according to overly draconian coding rules that make structured programming an end in and of itself often has none of these features, either. See post #21 for a good example.

 

[AUMathTutor]

"Back to your old ways, I see. Please use the quote button. Or the multi-quote button. Don't just quote text using quotes."
Get over yourself. What are you, obsessive compulsive?

"No, it cannot. See the article cited in post #7, repeated here."
Fair enough... I was only just able to actually read the thing, and it looks to be in order. Still, I don't think that this means using the GOTO anywhere is alright. When the GOTO is being used in the place of other constructs which could do the job just as well, I don't think it's a great idea. And honestly, how often have you ever *had* to use a GOTO? Rarely, I imagine.

"You are being overly dramatic. Nobody here is advocating a return to 1960's style spaghetti code. The end goal is (or should be) code that is usable, reusable, maintainable, verifiable, ... Spaghetti code has none of those features. Unfortunately, code written according to overly draconian coding rules that make structured programming an end in and of itself often has none of these features, either. See post #21 for a good example."
It's a matter of degrees, not absolutes. The less structured your code is (read: the more gotos you have), the more likely it is to be (or turn into) incomprehensible spaghetti code.

And I agree that structured programming is not an end, but a means to an end. What seems to be giving me trouble in understanding your POV is that you seem to use the fact that it's a means to an end to throw it out the window whenever it isn't convenient for some or some other reason.

The GOTO has never been accused of not being clear to the person who used it. Then again, the point of employing any of these design ideas into your program is to help other people, not yourself, deal with your code. For me, the GOTO is the code equivalent of spewing acronyms and technical jargon at the customer. You know exactly what you're talking about, and other people familiar enough with what you're talking about can probably follow, but otherwise it's a mess.

I feel like if you're going to have rules, that you stick by them - for consistency's sake, if nothing else. Deviation from these rules should be subjected to scrutiny - which is really all I'm advocating. Clearly the context determines how much deviation is allowed. Under certain conditions, the GOTO - as well as any other bad programming idea you can think of - can be acceptable. Naturally, here, we're talking about generalizations, and in general, the GOTO should be avoided where it is feasible to do so.

That's my position, and I've: (a) heard it, (b) read it, (c) experienced it, (d) understood it, and (e) agreed with it for too long to just throw it out the window on a whim. Can you find any studies in software engineering that discuss the relative merits of the GOTO?

 

[AUMathTutor]

"http://books.google.com/books?id=c42oYf4zBzMC&pg=PA118&lpg=PA118&dq=bohm+jacopini+false&source=bl&ots=fpxxYAp852&sig=92c8tTVUpm5SAhRNE4eAgfikjgs&hl=en&ei=D1bvSaf7Od6Jtgf_lfHBDw&sa=X&oi=book_result&ct=result&resnum=7"
That might be an interesting read. It seems to confirm what I had been thinking all along - that while a program using GOTOs may not be possible to convert using Bohm and Jacopini's method, the results of it can certainly be achieved using Bohm-Jacopini.

I think it's much more reasonable that a program may not be able to be represented using WHILE and IF-THEN-ELSE, but I have a hard time believing that whatever the program does couldn't be done in such a way that the WHILE and IF-THEN-ELSE were sufficient. If this is true, then we just get right back to the real issue: should we write our programs in terms of GOTO, or in terms of structured programming?

You know, D H, if you can turn that 3-state automaton into a program that computes some value which cannot be computed without a GOTO, I will have to concede at least the point that the GOTO is required in any Turing-complete programming language. Like I said, I don't think it's possible to come up with any computational procedure which, given a set of inputs, produces an output which cannot be replicated by some other procedure using only WHILE and IF-THEN-ELSE. We'll see...

 

[rcgldr]

Of course, if you have any appreciable amount of code being executed where I have // code..., then you could make the separate parts into inline functions or something and do the following:

void bar()
{
   bool cond1 = cond2 = cond3 = cond4 = false;

   cond1 = f1();
   if (cond1) cond2 = f2();
   if (cond2) cond3 = f3();
   if (cond3) cond4 = f4();
}

Here you're using a condition that implies some dependency. The issue to me is the level of dependency between a condition and a code fragment.

In my previous example, an application may require the allocation of multiple resources before it can run, but the invidual allocations of resources are independent of each other, memory allocation is independent of opening a file, or createing a mutex, so I don't write code that implies some inter-dependecy. If someone else has to add or remove allocation statements, there aren't any confusing implied dependency conditionals to deal with.

Otherwise I rarely use goto's. Breaking out several levels of nested code is one case where I'd use a goto. Failure status of an otherwise independent step is another case where I'll use a goto for error and exit handling code, so that the main stream code deals with the non-exceptional sequences of steps in a process.

An anology would be a pilot procedure for an aircraft. How readable would the procedure be if every step was individually preceded with list of conditionals for all the things that could fail? "if (engine_not failed){ if(fuel_not_low){ if cockpit_not_on_fire){ ... { { { ... ask_for_clearance_to_taxi_to_runway)(); ... } } } ... } } }.

discuss the relative merits of the goto?

As I just pointed out in this post, goto's can eliminate the implication of non-existant dependencies (beyond simple non-failure) between independent sequences in a program. Goto's also allow the main line code to not be cluttered with exception handling.

 

[AUMathTutor]

Well, I mean refereed, journal quality papers discussing studies into the GOTO, not personal opinions. I think we all know about where we stand at this point.

 

[Hurkyl]

Still, I don't think that this means using the GOTO anywhere is alright.

Nobody is advocating using goto anywhere. They're advocating using goto when it's the right tool for the job.

When the GOTO is being used in the place of other constructs which could do the job just as well, I don't think it's a great idea. And honestly, how often have you ever *had* to use a GOTO? Rarely, I imagine.

Nobody is advocating using goto when other constructs do the job just as well. They're advocating it when other constructs don't do the job as well -- such as breaking out of a double loop. The question of whether the goto *had* to be used is completely irrelevant.

It's a matter of degrees, not absolutes. The less structured your code is (read: the more gotos you have), the more likely it is to be (or turn into) incomprehensible spaghetti code.

So? Spaghetti code is bad because it's spaghetti, whether or not it uses a goto is irrelevant. Containing a goto is simply not grounds for condemnation.

the GOTO should be avoided where it is feasible to do so.

"Feasible" isn't good enough. The goto should be avoided only when other methods are better.

 

[AUMathTutor]

""Feasible" isn't good enough. The goto should be avoided only when other methods are better."

And you know what my response would be, so let's look for some refereed papers on the subject rather than continuing this tired debate.

 

[rcgldr]

What is the signifcant difference between "goto", "break", or "continue"?

 

[Hurkyl]

""Feasible" isn't good enough. The goto should be avoided only when other methods are better."

And you know what my response would be, so let's look for some refereed papers on the subject rather than continuing this tired debate.

There is no point in looking if we cannot agree upon what we're looking for. I want to write the best code I can, and I don't care whether or not it involves goto. You, on the other hand, seem to consider "avoiding goto" a goal, and you're willing to sacrifice the quality of your code to achieve it.

 

[AUMathTutor]

"willing to sacrifice the quality of your code to achieve it."

Again, you know how I'm going to respond to this. But just so we're on the same page, my response would be something like:
"And you're willing to sacrifice the quality of your code by ignoring software best practices and using the goto in an ad-hoc fashion to get quick and dirty results."

As far as refereed papers are concerned, I'll do my best to find some which are freely available and deal with the GOTO, when and why it's used, and whether it's good or bad software engineering practice to use them freely, use them sparingly, or avoid using them as long as possible. Dijkstra's paper on this is one example, but I think there are others. Perhaps there are even a few papers defending the goto. Who knows?

 

[D H]

You've been given one paper already, and by none other than Knuth.

None of us are advocating a return to the days of spaghetti code. As Hurkyl and I have both said many times, the ultimate goal is to write the highest quality code; code that is usable, maintainable, understandable, verifiable; all those -ilities.

There are, in fact, several good places where all but the most rabid of structured programming workplaces still gotos:

• To break out of a nested loop in a language that does not provide a multi-level breakout.
  
  
• Error handling, particularly in
  • Languages that do not support or projects that do not allow exceptions. For example, even though C++ provides a powerful exception-handling capability, use of it is often verboten in real-time systems (as is use of new).
  • Projects with the (IMHO) incredibly onerous "single point of entry / single point of return" rule. (BTW, very few languages support multiple points of entry. Fortran is the only one that I can think of that does.)
  
  
• To directly implement finite state machines. The use of gotos here is in a sense the natural implementation of an FSM. The more typical implementation as a loop around a switch statement is a somewhat artificial, but not too onerous, construct invented solely to avoid use of gotos.

 

[rcgldr]

The days of spaghetti code.

Maybe spaghetti code was more prevalent during the 1960's, but I started programming as high school student back in 1968, and good coding practices were being taught back then, even for assembly language programming.

One 1960's standard that has carried through current times is the ideal of modularizing code; keeping the main program and any subroutines (functions) reasonably small, with each subroutine performing one main function. There are always exceptions, but this was a general rule.

Another concept was top down design, bottom up implementation, to simply unit level testing of subroutines without having to create stubs and generation of data. The bottom up implementation wasn't a strict rule, but a general guide. In some cases, key or potentially problematic subroutines would be implemented (or partially implemented) first to see if there was a flaw or problem with the design.

One thing that has mostly gone away is the manual drawing of flow charts. Some of us always preferred writing psuedo-code since it could be easily maintained, and eventually the flow chart tools ended up using pseudo-code like languages as input to create their flowcharts. Then programmers started becoming aware of the fact that it was easier to read the pseudo-code input files than to view the created flowcharts for any but the simplest of algorithms. I still have my plastic flow chart drawing guide, as well as an old K&E slide rule, but thes are just collectors items now, along with my Microsoft OS/2 coffee cup.

Speed is less of an issue now. I can remember some projects where microseconds mattered, and I would do things like changing interrupt vector address pointers to handle a sequence of interrupt driven steps to minimize latency. Perhaps this explains why I'm still fond of using pointer to functions for handling interrupt or message driven code.

 

[Hurkyl]

Again, you know how I'm going to respond to this. But just so we're on the same page, my response would be something like:
"And you're willing to sacrifice the quality of your code by ignoring software best practices and using the goto in an ad-hoc fashion to get quick and dirty results."

How would I know that? My stated goal is to write the best code I can, and I cannot write the best code I can if I sacrifice the quality of my code. Your response makes absolutely no sense.

 

[AUMathTutor]

Hurkyl, your feigned indignity is very entertaining, and I'm assuming that was the intent. Clearly this is the case; either that or you have never fully understood the phrase "beating a dead horse".

"How would I know that?"
Because we've been doing this little tete-a-tete for the last 15 or so posts, it seems. We can both come up with new ways of saying the same thing all day and night, but that's not going anywhere fast.

"My stated goal is to write the best code I can"
As is mine... the difference is in how we seek to achieve this goal, viz. whether or not using the goto is a good idea, ergo this discussion thread.

"and I cannot write the best code I can if I sacrifice the quality of my code."
Finally we agree. I generally accept the truth of tautological statements, but it never hurts to check.

"Your response makes absolutely no sense."
In the best case, that's the pot calling the kettle black. In the worst case, it's the pot making wild accusations that apples are in fact black, if that's how he sees it.

 

[AUMathTutor]

D H:

That you did, and I appreciate the effort to find relevant material. I don't recall how old the paper you provided was, however, and I really wanted to see if there's any current research in the area, or if it is generally considered to be dead and buried. In fact, I have a few minutes, let me do a quick Google search and see what we turn up:

Here's the Dijkstra paper I've mentioned:
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

Ironically, that's even older than the one by Knuth.

Here's another pretty basic one that's turned up:
http://portal.acm.org/citation.cfm?id=800283.811114

There are others out there, but I'm running low on time, so I think I'll let you guys take a look at some of these if you're interested. The last one, in particular, was very enjoyable.

Here's a deliciously mathematical look at how it may come to pass that such questions as whether the GOTO is an appropriate statement to use or not may some day no longer be a matter of opinion:
http://www98.griffith.edu.au/dspace/bitstream/10072/12328/1/5314.pdf

 

[Hurkyl]

"My stated goal is to write the best code I can"
As is mine... the difference is in how we seek to achieve this goal, viz. whether or not using the goto is a good idea, ergo this discussion thread.

Then you need to explain something. You made a comment earlier:

in general, the GOTO should be avoided where it is feasible to do so.

which seemingly directly contradicts the claim you just made, that you seek to write the best code you can. Here, you assert that (generally speaking) goto should be avoided when feasible. You didn't say that goto should be avoided when when there are better options, you said it should be avoided when feasible.


You have made similar comments in the past:

I, personally, avoid the GOTO when it is not too inconvenient to do so.

Where again, you suggest that code quality is not your primary concern: instead, you avoid goto whenever sufficiently convenient.

 

[AUMathTutor]

Yes, because my philosophy is to avoid mistakes which can be caused by using the GOTO by avoiding the GOTO; yours is to avoid those mistakes by simply not making them, which is a great philosophy if you can pull it off, but which is generally speaking not a satisfying solution to the problem, since if it were, there would be no problem in the first place.

This sort of reminds me of The Feynman Problem-Solving Algorithm:
(1) write down the problem;
(2) think very hard;
(3) write down the answer.

That's a great general-purpose way to go about things, too, if you can pull it off.

"You didn't say that goto should be avoided when when there are better options, you said it should be avoided when feasible."
In my way of looking at it, if other options are feasible, they are by default better options.

And was it you who said earlier that thinking about new control flow structures was not a productive activity since you can't go use them in C++? New languages happen... and when new control flow constructs or constraints are added to the language, people need to have thought about them and discussed the need for them in future languages.

And what about declaring blocks of code as GOTO if they use GOTOs, loops as BREAK or CONTINUE if they use BREAK or CONTINUE, and MULTIPLE ENTRY / EXIT if they contain multiple points of ENTRY / EXIT? This seems like a good idea to me. I think that in C# you can do the same thing to use pointers, which I think is a great idea.

 

[rcgldr]

Yes, because my philosophy is to avoid mistakes which can be caused by using the goto by avoiding the goto; yours is to avoid those mistakes by simply not making them

What are "mistakes" that can be caused by using goto? I've never seen a list of these anywhere. How difficult would be it be to avoid these mistakes? In my examples where I did use goto, would you find it difficult to understand or maintain the code where I used goto's?

Why is goto the only statement to be avoided? Couldn't the same argment be made for any statement type of a language? What mistakes can goto cause that couldn't also be caused with poor usage of break, continue, if+else, ... ? Should we also ban the usage of pointers because of the risk of mistake? Should be ban recusion because it can be coded around?

 

[AUMathTutor]

Mistake may not have been the best word for it. I'll think about exactly how I want to say this bit before I get back to you.

As far as the other part of your post, I agree that other constructs are just as bad as the GOTO. The GOTO is sort of a scapegoat. However, I do believe that some constructs are inherently "better" than others.

I feel that the more limited in scope and more rigid in behavior a construct, the better. Why? Because if people are familar with what a construct is capable of accomplishing, it is easier to understand code which uses this construct. Naturally, this necessitates a larger set of constructs than may otherwise be required. The GOTO is sufficient to simulate the IF-THEN-ELSE, the SWITCH, the WHILE, the FOR... you name it, the GOTO can do it. So why have any constructs at all?

We know how to reason about if-then-else constructs, while loops, and for loops from mathematics. These constructs correspond to very familiar ideas in mathematics... they are, in a sense, referentially transparent in that their semantics do not depend on their context. This makes it a lot easier to reason formally about what a program is actually doing.

 

[rcgldr]

Maybe it would help to mention my restrictions for the usage of goto. I didn't make it clear that I limit the usage of goto's to two situations, only providing examples instead of stating restrictions on usage.

1. I use goto's for exception or failure cases, so the main code flow deals with the normal case, and without "undeeded" indentation.

2. I use goto's for multiple exit paths out of nested code, but these situations are relatively rare. In languages where this could cause problems, compilers will usually issue errors or at least warnings. I'll prefix such sections of code with a comment regarding any breakout gotos, a warning similar to the try clause of a try throw catch sequence.

One annoying (to me) situation is when reacing the end of a nested section represents failure. Due to my rule #1, no significant exception handling in the main line of code, I end up using another goto just after the nested sequence to deal with the exception, followed by a "success" label to continue the main line code.

In other cases, the early or final exits are simply alternate conditions. For example when building and using a dictionary, it's expected to not find a match, so the two main paths are create new entry and/or use existing entry.

 

[Hurkyl]

Yes, because my philosophy is to avoid mistakes which can be caused by using the GOTO by avoiding the GOTO;

So it's more like buying insurance then. You (may) pay a price on every piece of code you write -- your will write poorer code than you could have in any situation where using goto, break, multiple returns, et cetera would be an improvement -- to help protect against a particular kind of problem.

Is this a fair characterization? If so, it really is misleading to discuss alternatives to goto as if they are better pieces of code...

And was it you who said earlier that thinking about new control flow structures was not a productive activity since you can't go use them in C++?

I am the one you're thinking about, but you have the intent wrong -- the point was that it's not fair to criticize a particular implementation on the grounds that it really should the "condexpr" construct when it doesn't actually exist.

 

[AUMathTutor]

"your will write poorer code than you could have in any situation where using goto, break, multiple returns, et cetera would be an improvement"

By my definition of quality, surely you realize that - almost by definition - the fewer unconditional jumps, the better. Exceptions to the rule can certainly be allowed, but only when the alternatives aren't feasible - that is, to do it another way won't work for some reason. I won't agree that my philosophy is to write poor-quality code just to dogmatically avoid a language construct, because that's not my intent.

 

[rcgldr]

unconditional jumps

Unconditional jumps aren't the issue, or at least not mine. All the exampes of the goto's and discussion here have been about using goto's for conditional branching.

Unconditional goto's might be used to implement the equivalent of a while(1){...} in a language that didn't suport it, where the exit point is in the middle of a loop instead of at either end, but this wasn't brought up until now.

 

[Hurkyl]

I won't agree that my philosophy is to write poor-quality code just to dogmatically avoid a language construct, because that's not my intent.

You (practically) define goto to be bad. How is that not dogmatic?

Anyways, your definition of "quality" is irrelevant to me -- I'm interested in things like correctness, readability, portability, efficiency, reusability, rather than in syntactic games -- so I'll stop discussing it.

 

[AUMathTutor]

"You (practically) define goto to be bad. How is that not dogmatic?"
Please. I have said over and over again that my position is to avoid the goto when feasible, and to use it only when necessary. Feasability is a broad term. In high-level user-interface programming, where efficiency is not an issue and the code is not complicated, the goto should never have to be used. For lower level code where efficiency is an issue, the use of the goto can become appropriate (although, like I said, none of the examples provided so far in this discussion thread seem very compelling to me).

Is it dogmatic to have principles which guide programming practice? If so, I'm dogmatic, and so are all good programmers. You need a consistent system... I would say it's better to be consistent in the development of software than to just use whatever you think (in passing) might be right for the job.

"I'm interested in things like correctness, readability, portability, efficiency, reusability, rather than in syntactic games"
Wow... that's what we've been talking about all along. Are you following any of this? Your opinions really don't mean much to me, since your only justification for using goto is that it's easy, and your defense of this decision to use unstructured programming techniques whenever you feel like it is that it "improves quality", supposing the conclusion. Several papers have been linked to which discuss issues such as the GOTO... perhaps you should recommend some of the ones you've read, or perhaps you should find and read some.

"so I'll stop discussing it."
Or, instead of trying to make a meaningful contribution to anything, you can pretend you're better than the rest of us, and stock off like a child. Whatever.

 

[D H]

As you are still a student (see [post=2172341]this post[/post]), AuMathTutor, you are simply not qualified to discuss this topic. You most likely have not discovered the true horrors of project managers who never yield on the programming rules they have established. You have not discovered the wonders of hacked-and-slashed legacy code (but hacked-and-slashed in accordance per programming rules) that has turned into a monster as bad as any code from the 1960s. See [post=2169275]post #21[/post].

You have been indoctrinated and are being incredibly dogmatic about your indoctrination. Hurkyl wants to write the best code possible, where "best" to Hurkyl means extensible, reusable, maintainable, understandable, etc. Avoiding GOTOs where a higher level construct would serve better is one means of achieving this goal. Using a GOTO where a higher level construct would reduce the quality of the code is also a means of achieving this goal. Hurkyl is being pragmatic.

Your concept of the "best" is anything without a GOTO. You have elevated avoidance of GOTOs to a goal in an of itself. That is dogma.

 

[mXSCNT]

No need for ad hominems.

I've yet to see any situation where a "goto" does a good job and could not be replaced with modern programming constructs. The "principle of least power" is at work here. goto is simply a tool of uncontrolled power; a goto can produce a huge range of behaviors depending on the destination of the goto. If you have two code constructs which accomplish what you need, but one of them is more powerful, usually go with the weaker one; more power means more ways the code could become complicated and hard to understand, and also more chances to introduce bugs. Another way to put it is, too much power introduces unintended consequences. The principle of least power underlies several good programming maxims, in addition to avoiding goto:

• the idea that a function should have a clearly defined purpose, doing only one thing. This follows because functions that do multiple things are more powerful, and therefore have more potential to be misused or buggy.
• the idea that functions should be referentially transparent (when possible) or at least not access many global variables. A function that is not referentially transparent has less constrained behavior, thus it is more powerful (and thus can have more unintended consequences).
• the idea that values should have types. An untyped value has greater potential to be misused. It could be the number 3, the string "suzy", or an instance of a mysterious class. Thus it is less constrained than a typed value, and more powerful.

Power means lack of constraints. The principle of least power can alternately be stated as, given a choice between a way of doing things which is constrained, and a way of doing things which is less constrained, choose the more constrained one.

On the other hand, generality is a form of power that is "good." For example, if you have a function "snd" that extracts the second element of an ordered pair, this is more general than a function "sndInt" that extracts the second element of an ordered pair of ints. snd is less constrained and more powerful, but it is probably better because it has wider applicability. What can be taken from this is, things should be as general as they need to be, but they should avoid any kind of generality that is not convincingly justified.

 

[AUMathTutor]

"As you are still a student (see this post), AuMathTutor, you are simply not qualified to discuss this topic."
I hope your software isn't as flawed as your logic. Let's stick to the issues, D H. I could just as easily say that your experience has corrupted you and made you a biased observer, incapable of seeing both sides of the issue.

"You have been indoctrinated and are being incredibly dogmatic about your indoctrination."
Would you please cut out the pretending like you know me? Experience doesn't count for **** if you can't even come up with a compelling case for your position... much less if you can't even understand the difference between avoiding the GOTO to support good programming and "elevating avoidance of GOTOs to a goal in an of itself.".

I think it's healthy to feel a little nervous when the GOTO starts showing up over and over again in your code. However you slice it, our opinions differ only in degree, not in kind... you just avoid the GOTO less, and I avoid it more. Otherwise you wouldn't need any special control flow constructs at all.

That's all the response I'm going to give to your post, D H, because it's really not worth anything and contributes nothing to the discussion. If you want this to turn into an ad-hominem flame war, by all means, let's go.

 

[AUMathTutor]

mXCSNT:

I like the idea that GOTO is too powerful to admit general, default use of it when it seems like it could get the job done.

For me, it's sort of like information hiding. The GOTO is sort of like global variables... alright in small doses and with justification, but that doesn't mean it's alright to start making every other variable global in scope. The number of possible interactions grows too quickly to be scalable in larger applications.

You know, in a way, I think that functional programming languages are probably the best idea, in terms of writing good code. They force you (or at least strongly suggest to you) to abandon state altogether... without state, you gain referential transparency and guarantee control flow in very clear terms (usually). In fact, if it weren't for the fact that they're less efficient than imperative languages, I'd probably advocate using them. The syntax is easy, the semantics are easy, and it sidesteps all the problems of global variables, gotos, etc. I wonder if in a parallel universe there's a group of people arguing on physics forums about some feature of functional programming languages which should or shouldn't be used for functional programming.

 

[Hurkyl]

Would you please cut out the pretending like you know me?

He may not know you, but he knows the persona you present through your posts...

much less if you can't even understand the difference between avoiding the GOTO to support good programming and "elevating avoidance of GOTOs to a goal in an of itself.".

I know the difference. Are you sure you do?

Suppose, for the sake of argument, you have two pieces of code, X and Y. X uses goto's. Y does not. Y is more readable than X. X is more error-prone under modification than Y. All other qualitative aspects are equal.

We can all agree, I believe, that Y is a better piece of code than X.

Question: consider the statement "X uses goto, Y doesn't, therefore, Y is better". Is this an example of
(1) "avoiding goto's to support good programming"
or is it an example of
(2) "elevating avoidance of goto's to a goal in of itself"
?

Now, answer the same question regarding the statement "Y demonstrates that avoiding goto is feasible, and therefore, you shouldn't use X".

 

[mXSCNT]

Sure, it's possible that good code uses gotos or that bad code has no gotos. I don't think anyone here would disagree with that.

 

[AUMathTutor]

"He may not know you, but he knows the persona you present through your posts..."
Not that it makes his argument valid, or that it should factor into any discussion, or that it makes any difference at all to the issues we're discussing what sort of persona I present, but alright, sure.

"I know the difference. Are you sure you do?"
I'm pretty sure I do. I'm glad you think you do too.

"Suppose, for the sake of argument, you have two pieces of code, X and Y. X uses goto's. Y does not. Y is more readable than X. X is more error-prone under modification than Y. All other qualitative aspects are equal.

We can all agree, I believe, that Y is a better piece of code than X."
Granted...

"Question: consider the statement "X uses goto, Y doesn't, therefore, Y is better". Is this an example of
(1) "avoiding goto's to support good programming"
or is it an example of
(2) "elevating avoidance of goto's to a goal in of itself""
I think this demonstrates that you have a fundamentally distorted view of my position with respect to the GOTO. Yes, if two otherwise identical pieces of code are being compared, and the only difference is that one uses the GOTO and one doesn't, I would select the one without the GOTO every time. If all things are not equal, then I may select the one containing GOTOs under special scenarios if *I must do so*. In my (limited, as pointed out by D H) experience, the GOTO is not really ever neededfor high-level programming. For most usual operations, including all the ones brought up here, I'd sooner resort to structured techniques, including state variables, if-then-else blocks, and loops. If I don't need it, I don't use it.

"Now, answer the same question regarding the statement "Y demonstrates that avoiding goto is feasible, and therefore, you shouldn't use X"."
Depending on exactly what you mean by feasible, then yes, I agree with this statement in every case I can imagine. However, when I think of feasibility, I think of it in terms of being an appropriate solution... not just any solution. Maybe this is a non-standard usage of the word, and if I caused a misunderstanding by using it, I apologize.

 

[AUMathTutor]

"Sure, it's possible that good code uses gotos or that bad code has no gotos. I don't think anyone here would disagree with that."

It's not a matter of good or bad... it's a matter of degrees. I, for one, believe that it's a good idea to avoid the GOTO, but that's not to say that GOTOs cannot be used correctly. I just feel that it's all too easy to misuse them, and that what may seem like an appropriate use to one person may not be so to another. Most constructs have the property that when you look at it, you can tell what's going to happen next. I don't think the GOTO necessarily possesses this property.

But yes, all control constructs are based on the GOTO, so GOTO code can be alright. But in my way of looking at it, most things you need to do can be done without GOTO... unless you're doing something that really merits their use, like as in specifically the GOTO and not some other construct.

 

[rcgldr]

The part I don't understand is why "goto" gets so much attention? What about the triple branch in fortran "if(expression)a,b,c where a,b,c are labels branched to if the expression is negative, zero, or positive, since it requires the usage of labels, and there is no execution path that follows such an if, it's the termination of a code sequence (always branches). Why pick on just "goto"? Are there any other constructs in C that we should consider abolishing?

Regarding avoiding a particular construct of a language, I recall a real world disaster on a project. The team was using an old version of Pascal that typed all 8 bit values as characters and didn't allow any math operations on them. This project was character intensive, (data entry system), and functions similar to converting to all caps were common. The compiler could have been fixed to allow 8 bit integers, but the "gurus" on this team argued that not allowing math on 8 bit values would prevent programmers from making the mistake of accidentally doing math with 8 bit values, and preventing this "mistake" was worth the penalty of having to move strings or arrays of characters to strings or arrays of integers and back in order to do numerical operations, even though the code was messier and performance degraded (to the point that the project failed to meet it's peformance requirements and was canceled).