5 ms·

I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reas

by sgt101 11y ago

I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reasons to program in a particular fashion are as weak as "look how elegant that code is" appealing to the asthetic of the text and layout rather than any actual metric of clarity, reusability, interpribility or whatever. Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling. I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.

JustSomeNobody 11y ago
Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.
- mc808 11y ago
  Any kind of loop is just syntactic sugar over a goto. Having looping semantics in the language makes it clear when that particular pattern is being used, and it can prevent bugs that might pop up if everyone was writing their own ad hoc loops. Same thing with break. It makes the intent clear and makes it harder to accidentally stray from that intent. Of course, there's a problem when sometimes you want to stray from the patterns encouraged by the language, but it doesn't provide adequate means to do so.
- jerf 11y ago
  The essence of badness of GOTO is precisely that it is not "specific". When a higher level language restricts it, it is no longer the "bad goto" that structured programmers warned against. The problem isn't "transferring control flow", it was the ability to do it completely unrestricted.
- pjc50 11y ago
  Bad GOTO is jumping into a FOR loop in the middle of an entirely unrelated piece of code.
- acveilleux 11y ago
  Fortran IV would let you GO TO out of a DO loop into a whole different procedure's DO loop. (It didn't have FOR.) But why limit yourself to GO TO to fixed places??? Fortran IV also let you GO TO an arbitrary statement that would only be chosen at run-time "assigned goto". Fortran 77 still has that capability but you can limit it to specifically selected statements and it won't GO TO outside of the current unit (a concept Fortran IV lacked.) Dijkstra's remarks were contemporary of Fortran IV.

by sgt101 11y ago

JustSomeNobody 11y ago

Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.

mc808 11y ago
Any kind of loop is just syntactic sugar over a goto. Having looping semantics in the language makes it clear when that particular pattern is being used, and it can prevent bugs that might pop up if everyone was writing their own ad hoc loops. Same thing with break. It makes the intent clear and makes it harder to accidentally stray from that intent. Of course, there's a problem when sometimes you want to stray from the patterns encouraged by the language, but it doesn't provide adequate means to do so.
jerf 11y ago
The essence of badness of GOTO is precisely that it is not "specific". When a higher level language restricts it, it is no longer the "bad goto" that structured programmers warned against. The problem isn't "transferring control flow", it was the ability to do it completely unrestricted.
pjc50 11y ago
Bad GOTO is jumping into a FOR loop in the middle of an entirely unrelated piece of code.
acveilleux 11y ago
Fortran IV would let you GO TO out of a DO loop into a whole different procedure's DO loop. (It didn't have FOR.) But why limit yourself to GO TO to fixed places??? Fortran IV also let you GO TO an arbitrary statement that would only be chosen at run-time "assigned goto". Fortran 77 still has that capability but you can limit it to specifically selected statements and it won't GO TO outside of the current unit (a concept Fortran IV lacked.) Dijkstra's remarks were contemporary of Fortran IV.