Live data from Hacker News

Goto (2007)

beej.us

101–110 of 207 posts

Re: Goto (2007)

#101

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

I agree with you completely.

I once made a poster (I wish I'd kept it) where I was tracing out the behaviour of a single mega function with around 50 labels in it, and gotos all over the place.

I worked on a reimplementation, slowly picking apart the function into subfunctions, while loops, recursive function calls, etc. Took me about 2 weeks.

Re: Goto (2007)

#102

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

Yeah to those still adamant about it, if you've ever used a:

- function call

- if sentence

- any kind of loop

You've used a GOTO under the hood. I hope you can live with yourself, you monster :)

Re: Goto (2007)

#103

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

Yeah to those still adamant about it, if you've ever used a: - function call - if sentence - any kind of loop You've used a GOTO under the hood. I hope you can live with yourself, you monster :)

But there's a reason we come up with sanctioned, constrained concepts built atop more powerful lower-level ones. Constraints in code benefit maintainability, correctness, and sometimes even performance.

"Yeah to those still adamant about it, if you've ever used statically-typed code, you've used untyped assembly under the hood. I hope you can live with yourself, you monster :)"

Re: Goto (2007)

#104
post #91
post #71

Earlier quoted context omitted.

Yep, some goto uses were ostracized without ever providing the alternative. In other languages breaking numerous loops is done by naming the one you want to control: outer: for () { for () { for () { break outer;

This is much more confusing to me than just using a goto. From your example, it's not immediately clear at all to me if you're breaking out of outer, or if you're breaking TO outer. You can figure it out with this simple example, but it's way more confusing than it needs to be. And importantly: way more confusing than just using goto. Given that break and continue are just gussied up gotos anyway, just put the label…

There is no confusion if you're already familiar with the anonymous break:

  // find in a loop
  for (a : array) {
    if (a == target) {
      print("Found it");
      break;
    }
  }
This breaks the loop. A named break is no different except that it names the loop that will be broken out of:

  find:
  for (a : array) {
    if (a == target) {
      print("Found it");
      break find;
    }
  }
Exactly the same as the previous, but we've named the loop for some reason. If you can understand this, then the case of named breaks (or named continues) with multiple nested loops are comprehensible with some effort spent writing or reading illustrative examples like the above. Why would it do anything else? A break is a break, it terminates the loop. To re-enter that loop would be a continue, not a break.

> Given that break and continue are just gussied up gotos anyway, just put the label where you wanna go and goto it. I think it's one of the few perfectly valid uses goto.

The reason not to do this is that goto's can (as illustrated in the submitted article) lead to some erroneous behavior that is harder or impossible to achieve with more structured equivalents (like named breaks and continues). Like, your goto can jump past variable initializations and get you undefined behavior. Using the structured equivalent of:

  for (a : array) {
    if (a == target) {
      print ("Found it");
      goto found_it;
    }
  }
  found_it: ...
Removes those potential errors from the system. That, of course, doesn't mean that goto should be forbidden entirely (plenty of examples in this discussion of where it's useful), or that something like the preceding wouldn't be useful in some circumstance. But if we follow the idea that you present ("break and continue are just gussied up gotos anyway") to its conclusion, we'd be back to the unstructured code that was Fortran and its contemporaries, because why should we have if, if-else, while, for, function calls, etc. when they're all just gussied up goto anyways?

Re: Goto (2007)

#105

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

My first job was writing VB.NET code and it was hammered to us not to use GOTO. Once for a critical production bug, using GOTO was the quickest solution to fix and I used it with a comment to not fire me. And that code lived on for years.

Re: Goto (2007)

#106
post #76

Earlier quoted context omitted.

MISRA doesn't ban it, that rule is only Advisory which pretty much means you can ignore it. Rules 15.2 and 15.3 (Required) define how you can use goto if you decide to use it. Rule 15.2 The goto statement shall jump to a label declared later in the same function (forward gotos only) Rule 15.3 Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement (ca…

I'm familiar with MISRA (embedded dev), I only wanted to point out that the MISRA rules in no way justifies a blanket ban on gotos. The ban (in the case of C, anyway) is almost always the result of someone's completely subjective opinion that gotos are bad.

It's easier to 'ban' it and then to make exceptions on a case by case basis when not using goto make things worse.

That has three practical benefits: It's clear (which is an underrated quality), it forces people to structure their code accordingly, and it prevents endless discussions (another very valuable quality). Otherwise, in my experience the use of goto tends to creep up and every occurrence leads to discussions in code review.

So it's not that those decisions are subjective is that they are practical and workable. Especially, if you are defining practices for contractors to follow it is beneficial to keep those rules simple and clear as they will form contractual obligations.

Re: Goto (2007)

#107
post #11

Earlier quoted context omitted.

It's not arbitrary. The goal is to improve quality by making the code better structured and easier to follow. For instance, MISRA C rule 15.1 that states that goto should not be used explains: " Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand ". Indeed, in practice that's often the case.

Well, in C you very rarely need it, but in assembler (particularly the 8-bit Z80 and 6502 that I've written raft-loads of code for) you definitely do. Of course, something like a CALL is better, if you can manage it.

It's mostly used for error bailing as nested if can be pretty dense to read and error prone.

Re: Goto (2007)

#108
post #22
post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

> Or those novels that do not ever use the letter "e". As a note on this, I think the novel you're talking about is Georges Perec's 'La Disparition'. Supposedly the lack of an 'e' is symbolic of the loss of his family in the Holocaust. Anyway, I always thought one of the greatest feats of the English language was the guy who translated the novel to English, also omitting the letter 'e' . Absolutely mindblowing talent…

Also Gadsby by Ernest Wright

Re: Goto (2007)

#109

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks }…

Yeah to those still adamant about it, if you've ever used a: - function call - if sentence - any kind of loop You've used a GOTO under the hood. I hope you can live with yourself, you monster :)

You put a smiley so I suppose it's possible you know better, but this kind of shallow, thoughtless critique is just painful to read, especially when following such a well-presented, historically accurate description of the debate surrounding goto. This is especially true given that Dijkstra himself refutes your argument, such as it is, in the opening paragraph of his seminal paper.

Re: Goto (2007)

#110

Earlier quoted context omitted.

It's not arbitrary. The goal is to improve quality by making the code better structured and easier to follow. For instance, MISRA C rule 15.1 that states that goto should not be used explains: " Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand ". Indeed, in practice that's often the case.

> For instance, MISRA C rule 15.1 that states that goto should not be used explains: "Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand" Sure, but constrained uses are fine, right? So why blanket-ban it?

At least one of the versions of MISRA explicitly allows for the use of goto to break to cleanup code at the end of a function, if I remember correctly, and another is much more strict, but I don't have any copies of MISRA at hand at the moment.
Post reply on HN