<p><code>goto</code> is not bad <em>per se</em>, it depends the way you use it, that's the way Dijkstra and other papers should be read. It can be very useful to simply get out from inner loops without creating weird boolean conditions. Of course if you use it to produce spaghetti code, that is bad.</p>

<p>For example, Java banned <code>goto</code> but gives a <code>break</code> to label statement which is exactly a kind of good <code>goto</code>. On the converse, C lacks of this useful extend break so you need to write thing like:</p>

<pre><code>for (...) {
  for (...) {
      for (...) {
          ....deep inside...
          if (...) goto end;
  }
}
end:
</code></pre>

<p>which is much much better than using boolean condition to exit from the loops one-by-one. I doubt anyone would consider such usage as bad, in really helps reading the code which would be much more difficult with a mess of strange combinations of conditions.</p>

<p>Naturally flowcharts illustrate the jumps in between portions of code and this can be simply implemented with jumps. After all an <code>if</code> necessitate a unconditional jump. Beginners have sometimes difficulties to understand what exactly happens in construct like <code>if</code>, <code>while</code>, etc and ask "what code is executed after that", saying that a jump exists from the end of a block to the beginning of another one is a good way to explain, much more than a purely syntactic explanation.</p>

CC BY-SA 3.0
2017-09-30T17:58:01.977Z
Every control structure in any language can be described as "a kind of goto".
T.E.D.
CC BY-SA 3.0
2017-12-03T15:21:27.697Z
@T.E.D. Every high-level program is compiled to machine code. The only flow control instructions in machine code, are `jump` (goto), and `jump_to_subroutine` (gosub / call, this one is almost structured). The point is not that it gets converted to a goto, the point is that all gotos should be used to implement control structures, and preferably these structures should be baked into the language, and add-hock goto removed from the language. `break` in a `for` look is a control structure, but break in a `case` may not be. You have to make your own structure with `case` in the `C` languages.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-29T11:28:47.840Z
2017-10-01T10:53:34.113Z
2017-10-01T10:53:34.113Z
Jean-Baptiste Yunès
<p>Here is a generic flowchart of a specific type of control flow:</p>

<p><img src="https://i.sstatic.net/4mcK1.png" alt=""></p>

<p>This control flow cannot be implemented with only control flow structures (<code>if</code>, <code>switch</code>, <code>while</code>, <code>for</code>, <code>do while</code>). You <em>have</em> to either use a <code>goto</code> after one of the conditions, or bend up another structure to simulate it. The latter naturally results in code ranging from slightly weird to awful (loops that don't actually loop, infinite loops with <code>if+break</code> conditions in the middle, artificial flag variables which form some kind of state machine, one-off functions that don't actually represent a stand-alone operation...).</p>

<p>The truth is that control flow structures do <em>not</em> cover all possible cases. <code>goto</code> should always be the last ever tool you try to solve a problem, but you shouldn't throw it away from your toolbox lest you want to end up driving a screw in with a hammer.</p>

CC BY-SA 3.0
2017-09-28T15:33:30.173Z
Good to know your history, of course: https://en.wikipedia.org/wiki/Structured_program_theorem. You have something nice and tricky, but not essential.
Buffy
CC BY-SA 3.0
2017-09-28T15:38:44.177Z
@Buffy I guess nothing is "essential" if you give up on readability. I really like the "Single-while-loop, folk version of the theorem" section from the page you linked, even if it addresses an extreme form of what you have to do with control flags (`p` is completely artificial, and is only needed because of the shortcomings of the structured flow). I especially like the last quote before the block of code, which neatly sums up my PoV.
Quentin
CC BY-SA 3.0
2017-09-28T15:45:56.540Z
I worry about "readability". Suppose that your "simple" flowchart results in code that is spread over about 5 pages. Is it still "readable". The history of computing languages seems to imply that go-to should just go. Python, Scala, etc, don't include it and there are other ways to think than with low level structures. These result in cleaner and more maintainable code. One problem with go-to is that it often results in "write-once" or even "write-only" software that is impossible to maintain in the face of changing requirements.
Buffy
CC BY-SA 3.0
2017-09-28T15:46:17.097Z
For Ruby's support of goto see: http://patshaughnessy.net/2012/2/29/the-joke-is-on-us-how-ruby-1-9-supports-the-goto-statement
Buffy
CC BY-SA 3.0
2017-09-28T15:57:02.083Z
A five-page nested loop won't do you any good either, so that's a job for another structuring tool (namely, functions). Anyway, there's no doubt that structured control flow is a benefit in the overwhelming majority of cases. But wanting, in the tiny number of cases when it isn't enough, to simulate a goto by misusing a control structure is just a bad idea. The tell-tale symptom is the apparition of infinite or do-once loops with `breaks`, or the proliferation of control flags. That's not "more maintainable" code in the slightest compared to a simple labeled `goto`.
Quentin
CC BY-SA 3.0
2017-09-28T16:06:23.833Z
Hmmm. No one is suggesting misusing other control structures. And yes, functions are one of the classic ways to solve many such control issues. Could you imagine suggesting such a control structure to a Scheme programmer? You seem to be insisting that such things are _needed_. They are not. Finding out why and how will expand your horizons, I think.
Buffy
CC BY-SA 3.0
2017-09-28T16:11:45.207Z
For a little more perspective. For "replacements" of some of these poor control structures a small local change may not do the job, resulting in even poorer code and misuse of structures. Sometimes you want to step back and re-think the algorithm. There is likely a clearer, simpler, more readable, more maintainable way to do it. I'd suggest the Gries book mentioned elsewhere here (The Science of Programming) as a good place to learn such things. https://www.amazon.com/Science-Programming-Monographs-Computer/dp/038790641X
Buffy
CC BY-SA 3.0
2017-09-28T16:11:51.003Z
@Buffy you can implement it in a functional language by wrapping it in a function, and tail-recursing from the first condition. That's not ideal in imperative languages though. As for misusing control structures, ending up with loops that don't actually loop, or depend on some phantom flag unrelated to the data you're processing, or have their condition in a weird place (granted, that one is pretty tame) seems definitely off.
Quentin
CC BY-SA 3.0
2017-09-28T16:26:10.213Z
Procedural languages can do tail recursion as well: The C and C++ specifications allow it, but do not mandate it. `gcc` implements it. But tail recursion is no more `goto` than `if` is. It is a `while` with out mutation.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T16:42:15.323Z
@ctrl-alt-delor it still isn't that idiomatic, and might not fit the meaning of the algorithm. Not sure about your comparison with `goto`: tail recursion is equivalent to just jumping back to the beginning of the function, while wiping the stackframe.
Quentin
CC BY-SA 3.0
2017-09-28T16:47:09.187Z
@Buffy I do make this answer on the premise that this flow *is* the best you can do to model your requirements. I also didn't design it, but actually stumbled upon it while writing actual C++ code. I've also been bitten by another case in Java, which doesn't have `goto` and left me needing to write a degenerate `do`-loop with `break`s so I could skip to the end.
Quentin
CC BY-SA 3.0
2017-09-28T17:03:29.950Z
@I can accept that tail recursion is goto, when I accept that while and if are goto. Depends how you look at them. I prefer mainly to look at there structure not their implementation. I too have sometimes had to do weird things with goto and flags. I have come to realise that it because the languages we use don't have the higher order structures. Same as in the 1960s we used goto because we did not have the basic structures (while,for,if). There are still other higher order structures. If our languages did them, then we would not need to do weird stuff.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T17:11:20.070Z
@ctrl-alt-delor yes, maybe some new structures would be the solution, so we can avoid falling back to `goto` and its caveats. I'm purposefully avoiding the "but a `while` is just a `if+goto` in disguise" argument because it's moot, for the reason you stated. I do invite you, though, to try implementing that flowchart, and then verify that each abstraction and structure you used is actually meaningful -- loops actually loop, conditions are about the (imaginary) data you're processing, and there's no weird flags floating around. Maybe you'll get a great idea for the missing structure :)
Quentin
CC BY-SA 3.0
2017-09-28T17:25:16.207Z
@Quentin I took up this challenge once before, when it was a concrete problem. So I could re-write it. But I agree that this abstract problem is not elegantly solved.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-29T12:06:08.550Z
Use the Jacopini method:  1. Give different a block-number to each block. 2. Define a `next_block` variable with initial value 1.  3. replace first action by `if (next_block == 1) { instructions for action 1; next_block = 2 }`. 3. Replace first test (block 3) by `if (next_block == 3) { if (condition1) next_block = 1; else next_block = 4;`. Do the same for all, use number 0 for exit. 5. Put it all in a `while(next_block != 0)` loop. 6. Done: structured flowchart where all the logic disapeared and nobody can understand anymore. 
That what Dijkstra was referring to.
Michel Billaud
CC BY-SA 3.0
2017-09-29T12:26:59.573Z
Seems your flowchart can be written as `action1; aux; action3; while(condition2) { aux; action3;}, action4`, where `aux` is `action2; while(condition1) { action1; action2} ;`.    (obtained by loop unfolding)
Michel Billaud
CC BY-SA 3.0
2017-09-29T12:48:05.197Z
@MichelBillaud but then you have duplicated code.
Quentin
CC BY-SA 3.0
2017-09-29T13:35:09.530Z
@Quentin If it is a problem to have the same code, change the names. Well, no, better idea, put the repeated code in a function, and call it where it is needed.  Joke aside, It is probably a theorem "given a finite set of 'flowchart schemes' there are flow charts where gotos cannot be be removed without code duplication or use of extra variable." Should check. So the the point would be : what are the schemes needed for most practical use ?
Michel Billaud
CC BY-SA 3.0
2017-09-29T13:49:35.483Z
@MichelBillaud as an anecdote, this very scheme popped up while I was implementing a turn scheduler similar to that of HoMM5, which handled a list of actors and had to work with turn skipping, reordering, etc.
Quentin
CC BY-SA 3.0
2017-09-29T13:56:06.930Z
@Quentin It means that a specific structure is needed to express clearly what you need to do, which seems to be retrying previous steps.  `#define retry(label) goto label`
Michel Billaud
CC BY-SA 3.0
2017-09-28T15:23:53.040Z
2017-09-28T21:46:24.193Z
2017-09-28T21:46:24.193Z
Quentin
<p>Three quick answers:</p>

<ul>
<li><p>flowcharts are useful to <em>communicate and document the logic of a process</em>. Not knowing how they work may well be a problem in some kinds of work.</p></li>
<li><p><code>goto</code> has value in many situations where some programmers (not all) will work. Not everything is done in high level or modern languages. At a low level on most processors there are no loops, only conditional and unconditional <code>goto</code>s (branches). Older non structured languages also remain in use.</p></li>
<li><p><code>goto</code> also has considerable importance in security/vulnerability. That's because hacking and vulnerability work (and therefore security) can involve understanding stack manipulation techniques and disassembly (machine code to assembler) which are completely based on jumps not loops. If you look at an infosec analysis of malware you'll see the need to comprehend code that doesn't have high level classes and objects.</p></li>
</ul>

CC BY-SA 3.0
2017-09-28T17:43:22.643Z
I can't tell what "[hacking... is] completely based on jumps not loops" is trying to get at.  I would suggest removing your third bullet point, or trying to provide evidence for it.  That doesn't match my experience of security.  Are you perhaps trying to hint at ROP attacks?  But that's something entirely different; ROP has to do with CALL/RET instructions, and I don't see what the difference between jumps vs loops has to do with it.
D.W.
CC BY-SA 3.0
2017-09-28T18:16:28.850Z
Anyone analysing malware, or looking at vulnerability testing that requires analysis of compiles software, will need to dip into assembler. Which means understanding assembler, CPU address (+other) stacks (and perhaps interrupts) and so on. Which means understanding code that exclusively uses jumps and branches, such as JMP/JEQ/JL/JNE (or whatever the equivalent is on your CPU/SCAD). AKA understanding goto. Crucial for infosec work.
Stilez
CC BY-SA 3.0
2017-09-28T22:08:46.733Z
That's an argument for eventually teaching students assembly language, at least if they want to do infosec reverse engeering.  That's not the same as an argument for teaching goto.  And it has nothing to do with "jumps vs loops".
D.W.
CC BY-SA 3.0
2017-09-29T21:41:21.000Z
@D.W. I think that by “goto also has considerable importance in security/vulnerability”, Stilez means “goto is important to write native exploits”. Which is true, as part of the more general fact that writing native exploits requires a very good understanding of how a machine executes a program. But teaching how to write exploits is not relevant to  the context of the question, which is teaching to fairly novice students (the author of the article seems to insist that it's especially relevant for middle school students).
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-29T21:45:40.200Z
By the way, the statement “at a low level there are no loops, only conditional and unconditional gotos” is partly wrong (some processors do more than that for you, e.g. they manipulate the stack, and conversely a jump can actually be *more* than a goto if it involves changing processor modes). It's also misleading, because even in microcontroller programming, very little code is written in assembly and goto is rarely used in C, let alone higher-level languages.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-30T09:37:44.490Z
This isn't hard to understand. C wont help you, nor is it about writing exploits. Example paper: malware analysis of stuxnet: https://www.codeproject.com/KB/web-security/StuxnetMalware/Stuxnet_Malware_Analysis_Paper.pdf . Among the earliest pages (bottom of p.6) is _" at the place of the entrypoint of the unloaded module, stuxnet writes a "jmp" instruction"_. `jmp`. That's effectively `goto`. Is there any value in "teaching goto"? Evidently yes, if analysing malware, or you won't be able to do so.
Stilez
CC BY-SA 3.0
2017-09-28T08:25:37.593Z
2017-09-30T10:35:56.777Z
2017-09-30T10:35:56.777Z
Stilez
<p>Flowchart like drawings are a great help when trying to solve problems with multiple cases. A simple example</p>

<blockquote>
  <p>Exercise:  given three numbers a, b and c,  print them in ascending
  order.</p>
</blockquote>

<p>The student is expected to articulate a lot of comparisons, and quickly gets lost because his/her brain can't handle 6 cases and the necessary tests at the same time.</p>

<p>So some intermediary representation is needed to work on it.  Say, I obviously have to compare things. Let's start with a comparison of a and b.   On one side, I know a is bigger. On the other side b is bigger. What else ?</p>

<p>A graphical representation helps to work on the decision tree, much more than a textual representation if embedded if-then-else.</p>

<p>Image of work in progress. 1 of 6 cases solved. Extending the diagram can be done on any order.</p>

<p><a href="https://i.sstatic.net/xW3Oj.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/xW3Oj.png" alt="enter image description here"></a></p>

<p>Yellow boxes show what I know about the order in some case.  <code>c?</code> means :  "<code>c</code> could be there".</p>

<blockquote>
  <p>Question : What is obviously wrong? :-)</p>
</blockquote>

CC BY-SA 3.0
2017-09-28T08:47:01.577Z
You have used a flowchart to model a program flow tree, to model a decision tree. Just use a decision tree. This is basically the same as what you have draws, but minor notation change. And more importantly, no suggestion that this is what the program looks like. Imagine writing a program from this flowchart, that can sort 100 items.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T08:52:24.467Z
@ctrl-alt-delor sometimes the decision tree grows "indefinitely", and when you remark two situations are similar, comes the idea of jumping back to a previous point. Then you recognize a loop. Or a regular infinite tree, if you are more mathematically inclined. PS: I dont teach a notation for finished programs, but an approach. When you recognize a loop, you know what is the condition, and what you want to repeat.
Michel Billaud
CC BY-SA 3.0
2017-09-28T07:49:35.957Z
2017-09-28T07:56:54.660Z
2017-09-28T07:56:54.660Z
Michel Billaud
<p>There are a lot of answers here about flowcharts, and the author's answer seems centered around grade-school students (as that is what his article was about).</p>

<p>However, there are in fact some instances where we professionals <em>do</em> use gotos. We don't like to <strong>talk</strong> about it, because they have such a bad rep. However, if you crack open the code for most of the world's lexical analyzers you will find gotos. Lex itself generates gotos (admittedly, as do many other automated source code generators).</p>

<p>Gotos are in fact <strong>the natural expression of a <a href="https://en.wikipedia.org/wiki/Finite-state_machine" rel="nofollow noreferrer">state machine</a></strong>. It is meet and right to try to train students to put more structure into their programs than a simple state machine. However, there are a few tasks that in fact do not have more structure to them than a state machine. A lexical analyzer is one of these tasks.</p>

<p>The typical goto-less method to work around this is to create a variable to hold the state, and write a big honking switch statement embedded in a loop with little or no code between them. That works, and avoids using the g-word, but it doesn't really gain anything. Rather it just hides the unstructured control flow under an artificial layer of structure.</p>

<p>(Note: gotos are also commonly used in languages that don't have exception handling, but that's arguably a separate issue).</p>

<p>The only tweak I'd make to traditional anti-goto training would be to say that if I ever see something like this in your code:</p>

<pre><code>for (;;) {
    switch (state) {
       // multiple screens of code here
    }
}
</code></pre>

<p>Then one of two things are going to happen: Either there was a properly structured way to write the same code, and I'm going to grade you just like you wrote "goto" there, or there isn't, and I might dock you a point or two for the extra obfuscating of <em>not</em> using goto.</p>

<p>Also, courses like Compiler Construction that naturally entail gotos should mention this issue, and not hide from it.</p>

CC BY-SA 3.0
2017-09-29T20:51:58.497Z
Generated programs are a radically different beast from code that humans maintain. Most (I hesitate to say all, but I can't think of a counterexample) state machines I've written in the real world are better written out with an explicit state; conflating program state with program counter location, the way you have to do it if you rely on goto for state change, would have made them very hard to maintain, because the states are not clearly disjoint. Admittedly, goto might be the easiest way to express a state machine which is a toy exercise, designed to keep the states simple.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-29T21:23:25.413Z
@Gilles - There are of course good ways and bad ways to organize state-machine goto code (believe it or not), just like any other kind of code. But you aren't "fixing" that by artificially imposing an unnecessary loop-switch structure on top of it.
T.E.D.
CC BY-SA 3.0
2017-09-29T21:37:21.457Z
My point is that the state machines I usually see are a loop around *something that contains a switch, or at least a bunch of conditionals*. The loop body is hardly ever *just* a switch. It tends to be something like: read and parse a message, run consistency checks, analyze the state, update some data structures, emit a log message, make a state transition, loop. That's hard to express with goto statements, even in the best of cases where “analyze the system state” only comes up once.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-29T22:24:22.277Z
@Gilles -  If there's really a significant amount of "always run" code, yes that's a good reason for a loop. However, I tried that for a while with my first serious manual lexer, and gave it up. The problem is that stuff outside the switch tends to end up only running at the end or beginning of *most* loops, not all of them (practical example: don't bother updating the lexeme in comment state.) After about the 3rd interlocking exception, you end up just making that stuff subroutines and calling them at the end of the states that need it. That's much easier to follow code.
T.E.D.
CC BY-SA 3.0
2017-12-03T19:55:05.863Z
The body of my favorite language parser's main() function was "while ((f=*f()) != null);"  All structured, no gotos, but most people couldn't understand it. Gotos or switch (which is just a hidden goto) would have made it more clear to most people.
pojo-guy
CC BY-SA 3.0
2017-12-03T20:12:11.970Z
@ctrl-alt-delor - I designed and built one as part of my Master's thesis.
T.E.D.
CC BY-SA 3.0
2017-12-06T19:21:44.973Z
@T.E.D. I have no idea on what you disagree on. I have just re-read the answer and comments. I see nothing to disagree on. You are correct that you can not turn gotos-full code to structured-code in any reliably way. However it is better to write structured code in the first place, though this could involve `goto` statements, if the language does not support the control structures. Then if you know the full list of control-structures this code could be translated to have no `goto`s.
ctrl-alt-delor
CC BY-SA 3.0
2017-10-13T13:00:08.253Z
@T.E.D. Create/Use a meta compiler (a compiler compiler). Compilers are allowed to output `goto`s. Any domain specific language should be well structured, but may output code that is not intended to be maintained my humans. Every other compiler outputs `JMP` instructions.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-29T15:26:58.233Z
2017-09-29T15:26:58.233Z
T.E.D.
<p>If you are teaching assembly code or maybe Fortran then probably you need to discuss <code>goto</code> and possibly flow charts. However, if you are teaching a modern high level language, even something as old as Pascal, you should probably avoid them other than as an historic curiosity. This was settled almost 50 years ago, actually. </p>

<p>Along with some other illuminati of CS, David Gries has always used the term "flaw chart" for the classic diagraming technique. It is too easy with such tools to create unmaintainable code. </p>

<p>There is a form of <em>Structured Flow Chart</em>, however, which is not much different from, say, Pascal. It has no arrows, but, basically, only containment and sequencing of structures. But even that is probably just a waste of time as the constructs of modern languages make it unnecessary. </p>

<p>Even if you are programming in a language that requires <code>goto</code> however, you should probably only use structures like <code>if-then</code> and <code>while-do</code> that have been proven to be sufficient and also result in better (maintainable, understandable) code. Just Say No. </p>

<p>On the other hand, there is one reason for teaching <code>goto</code> to students of modern languages. If those languages permit <code>goto</code> then eventually the student will need to read programs that contain them even if they don't write such programs. So, purely as a defensive measure, they should know how to interpret these programs even as they disparage the authors of those programs. </p>

<p>There is a story from the past that is illuminating. In the old days IBM had a company policy that every program had to be documented with flow charts. However, they also had a tool that would create a flow chart from a Fortran program. So, the program was written, then the tool produced its flow chart, often spread over many, many pages. But the policy was satisfied. But, as a design tool, no. </p>

<p>See: <a href="https://en.wikipedia.org/wiki/Considered_harmful" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Considered_harmful</a></p>

CC BY-SA 3.0
2017-09-27T18:29:07.867Z
I have used a tool to automaticaly create UML class diagrams form code. Because we needed them, it was policy.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-27T19:51:16.193Z
Flowcharts work well as a tool to define/describe the desired flow (on a higher level) of a program. They can be important tools when explaining your program to a stakeholder or when attempting to grasp a new subject domain that you are developing for. I would argue they're not a waste of time to learn when used correctly.
Ben.12
CC BY-SA 3.0
2017-09-28T09:01:09.887Z
There are cases where you really *need* goto or labelled break. Example : 

    outer_loop :  for (X x : list_of_X) { 
                          for (Y y: list_of_Y) { 
                             if (some_condition(x,y)) { 
                                do_something_with(x,y); 
                                break outer_loop; 
                          } }
Michel Billaud
CC BY-SA 3.0
2017-09-28T11:13:29.177Z
Well, _need_ is relative. You have set up a case in which a targeted break is really _convenient_ but there are other solutions to such a problem. Otherwise Python programmers would be just _stuck_.
Buffy
CC BY-SA 3.0
2017-09-28T11:24:04.767Z
Nor is a targeted break, precisely speaking, a _goto_, though easy to explain as if it were, assuming your students know about `goto`. But it isn't necessary to explain it as a specialization of a wild _goto_ when they don't.
Buffy
CC BY-SA 3.0
2017-09-28T13:27:31.980Z
@buffy, My best effort, with a boolean, looks like this 
`boolean want_to_leave = false;
for (int i = 0; ! want_to_leave && i < list1.size(); i++) {
  String w1 = list1.get(i);
  for (int j = 0; ! want_to_leave && j < list2.size(); j++) {
    String w2 = list2.get(j);
    if (w1.length() == w2.length()) {
      println(w1, " ", w2);
      want_to_leave = true;
    }
  }
}`  and doesnt seem much clearer than `outer: 
for (String w1 : list1) {
  for (String w2 : list2) {
    if (w1.length() == w2.length()) {
      println(w1, " ", w2);
      break outer;
    }
  }
}`.
Michel Billaud
CC BY-SA 3.0
2017-09-29T03:03:12.743Z
@Buffy have you actually USED Fortran in the 20 years or so? You do realize it now even has classes? - plus a whole range of other "structured" features of course. Sure, there are one or two things that still *need* the concept of gotos and statement labels (like low-level error handling in I/O statements) but those are very much a minority - and of course you can (and should!) encapsulate the low-level I/O in its own classes and/or modules, so the implementation is invisible to the rest of the program! Teaching people Fortran IV is about half a century out of date now.
alephzero
CC BY-SA 3.0
2017-09-27T17:06:07.897Z
2017-09-27T19:47:36.440Z
2017-09-27T19:47:36.440Z
Buffy
<p>I am the author of the article. The point is to simplify the model of computation, not to match flow charts.</p>

<p>This is for mixed-ability 12 year olds, and when I say mixed, I mean some still add single digit numbers using their fingers.</p>

<p>Flow charts work because you can easily jump to another point in the program. This is not software engineering. I want them to create software where they understand how it works. </p>

<p>Goto also more closely mirrors the processor: it's easier to describe how programs are translated. After all, there is no such thing as structured programming at machine code level.</p>

<p>Dijkstra's article is a polemic from a purist. There were dissenting views at the time, which gave a more nuanced picture. The Wikipedia page on the article has good links on this.</p>

<p>Most new programmers shun goto because they have been warned it is evil, bad, and wrong rather than a more considered opinion.</p>

<p>My GCSE students learn structured C++. I myself am a CS grad and was a professional programmer a number of years ago.</p>

CC BY-SA 3.0
2017-12-03T15:33:12.633Z
I still need to be convinced of the value of teaching `goto`, even to low ability kids (How low ability are they? Are they brain damaged, or just farther behind than others?) I can see that `goto 1` is an easy place to start, it is easier that using `for` or `while`, but what next. Can you show some evidence (anecdotal is ok) of how it helped you.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T07:20:29.873Z
People should actually read Dijkstra's letter. He states the less gotos, the better. The context at the time was "goto's for everything", including decision and repetitions. Dijsktra advocated that programming languages should include constructs (like while/repeat until, if-then-else) helping to avoid the use of goto. Didn't say that loops/if-then-else were sufficient constructs to get clear code without gotos (talks about Jacopini's theoretical way to eliminate all gotos, where euphemistically "the resulting flow diagram cannot be expected to be more transparent than the original one").
Michel Billaud
CC BY-SA 3.0
2017-09-28T13:40:40.073Z
Actually, D. Knuth _agreed_ with E. Dijsktra. He just provided a more detailed view, with good examples of "no-so-easy to remove gotos" (with arguments on clarity and optimization: error management, n+1/2 loops, etc.), and honestly explained he had lot of difficulties to change his programming  habits. Anyway, it doesnt hurt to explain that what happens in a program actually turns into ridiculously small things like moving data, comparing it, and jumping elsewhere.
Michel Billaud
CC BY-SA 3.0
2017-09-28T15:51:20.237Z
Yes, Dijkstra was a _purist_. He was also extremely arrogant. But he wasn't wrong as I think you are trying to imply. Yes, there was controversy about his claims at the time, but the paper influenced the development of _every_ later language. It has taken a while to eliminate goto altogether, of course, but the trend is now nearly complete.
Buffy
CC BY-SA 3.0
2017-09-28T16:35:42.530Z
@Buffy Dijkstra's paper protects (in part) against [these practices](https://softwareengineering.stackexchange.com/a/118793/239446).The thing is, those practices aren't supported by higher level languages. It was absolutely correct when he wrote it, but technology has changed. It's like us sticking with QWERTY. Back when it was designed, it made sense. Now, it doesn't at all. Obviously, I'm not switching to DVORAK anytime soon, but can we at least agree that advice from 50 years ago using different technology might not be the gold standard for the technology we have today?
Lord Farquaad
CC BY-SA 3.0
2017-09-28T17:19:59.407Z
Dijkstra was right for most cases and purposes. Can I just ask if people criticising the approach have any experience of trying to teach low ability 12 year old children? When I trained to teach my biggest problem is I thought I could just explain things and children would understand. In reality I had been hanging out with the top 10% of the ability range (even in school I had no idea about the struggle of bottom sets.) I also teach year 11 maths and pupils struggle with place and value along with adding negative numbers. It is a different world.
Paul Powell
CC BY-SA 3.0
2017-09-28T17:38:29.853Z
@PaulPowell I have taught exactly one 12 year old to code (although to be fair, it was me). In support of what you're saying, I was learning TI-BASIC, so I learned what a goto was before a for-loop, and it made perfect sense. "Computers always read the next line of code unless you tell it to jump to a different line instead." Can't get much easier than that. When I got to loops and method calls which implicitly jump around, the first thing I'd do was mentally stick the `goto`s in and then they made sense too. I couldn't imagine learning loops first (or, god forbid, how a stack pointer works).
Lord Farquaad
CC BY-SA 3.0
2017-09-28T18:50:12.570Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/66358/discussion-on-answer-by-paul-powell-is-there-any-value-in-teaching-goto-or-flowc).
Ben I.
CC BY-SA 3.0
2017-09-29T09:38:12.450Z
I want to downvote this because I completely disagree with it, but you have direct experience with 12 year olds and I don't so I won't.
Jack Aidley
CC BY-SA 3.0
2017-09-27T18:57:52.820Z
2017-09-28T07:15:06.100Z
2017-09-28T07:15:06.100Z
Paul Powell
<p>I teach them within assembly code.  Otherwise, I mention them within my Java class when I teach their modern-day analogues, <code>break</code> and <code>continue</code>.  This is late in my AP course, after the AP test is over.  I present the two statements as restricted versions of <code>JMP</code> (that's the <strong>6502 Assembly</strong> syntax for <code>goto</code>), and I then follow up with two questions.  They get to discuss it out in small groups before we rejoin as a class and go over it together.  This gives them a chance to discover through peer discussion how language <em>restrictions</em> can really ultimately <em>help us</em>.</p>

<ol>
<li><p>There are several more <code>JMP</code> statements that break program flow in Java. Can you find any?  <em>(<code>return</code>, <code>throw</code>, <code>System.exit()</code></em>)</p></li>
<li><p>Why, do they suppose, does Java restrict our <code>JMP</code> capabilities to very specific situations?  What would be the problem with giving us an unhindered <code>jump</code> command in Java?</p></li>
</ol>

CC BY-SA 3.0
2017-09-27T21:10:45.993Z
There is a fourth one: `throw`.
Paŭlo Ebermann
CC BY-SA 3.0
2017-09-27T22:25:33.260Z
@PaŭloEbermann And `System.exit()`.
Peter - Reinstate Monica
CC BY-SA 3.0
2017-09-27T22:33:33.467Z
Also note that the Java virtual machine bytecode has unconditional jumps (of course). It could be instructive to show the bytecode for loops and conditional expressions (instead of comparing unrelated 6502 assembler).
Peter - Reinstate Monica
CC BY-SA 3.0
2017-09-28T01:51:54.580Z
@PeterA.Schneider 6502 is useful for me because it is what they have studied, so it's a good point of reference. It's also a beautifully clean and simple assembly language
Ben I.
CC BY-SA 3.0
2017-09-28T08:57:07.523Z
And a fifth one: `switch`
Manngo
CC BY-SA 3.0
2017-09-28T10:11:02.103Z
@Manngo `switch` would involve conditional jumps, not particularly unconditional ones (unless you are referring to the `default` at the end?) But in any case, there is a philosophical dissimilarity here. By that measure, so do `if` statements. The purpose isn't to find every jump that a compiler would generate, but rather, to find the ones that pull a program out of the narrative flow of the program (which is the use-case that so readily creates spaghetti code)
Ben I.
CC BY-SA 3.0
2017-09-27T19:21:46.330Z
2017-09-28T10:10:24.990Z
2017-09-28T10:10:24.990Z
Ben I.
<p>I think the <code>goto</code> is sorely maligned. When Edsger Dijkstra wrote his famous letter in 1968, high level languages were not the same as they are today, and the <code>goto</code> could easily be abused.</p>

<p>In my early days learning FORTRAN IV, the <code>goto</code> was an important part of the language and many of the important modern structures were not yet universally mainstream. The resulting code could indeed lead to a degree of complexity which would be hard to analyse.</p>

<p>High level languages were meant to be more abstracted than machine languages, and you would have thought manually encoding the structure this way was a failure in this regard. If that sounds like a strong argument against <code>goto</code>, then, well, it is.</p>

<p>However, things have moved on since then, and the alternatives are not always better. In fact the <code>goto</code> is still there in spirit every time we use the <code>switch</code> statement in c-type languages, as it is all but a specialised <code>goto</code>. This explains why you then need to end each part with a <code>break</code> statement.</p>

<p>Modern languages tend to restrict the use of <code>goto</code> to minimise the damage it could do in the past. In particular, you can’t just arbitrarily <code>goto</code> anywhere, but it must be within the limits of the current block, and only to labelled, not numbered, locations.</p>

<p>If you add further self-imposed restrictions such as only going forward, or only using it in certain circumstances, it can certainly be used in an orderly manner.</p>

<p>For example:</p>

<ul>
<li><p>You can exit a function early with a <code>return</code> statement or a loop early with either <code>continue</code> or <code>break</code>. There is no standard early exit for an <code>if</code> block, but a <code>goto</code> to a label after the block will do nicely.</p></li>
<li><p>For testing and trouble-shooting, it may be useful to skip earlier parts of the code and go straight to the section in question. Wrapping these earlier parts inside an <code>if</code> block simply to skip them is counter-intuitive and unnecessary.</p></li>
</ul>

<p>The point is, every programming structure has its pitfalls and can be abused. <code>goto</code> has possibly been more abused than the others. However, there is still a case for using it in well-controlled circumstances, as it can help make the code <em>easier</em> to follow.</p>

<p>So yes, there is value in teaching <code>goto</code>.</p>

<p>As regards flow charts, I think that they remain the most obvious way of visualising a process. The fact that they are used so often in non-technical contexts attests to this. When teaching programming I often end up drawing arrows all over the structures.</p>

<p>I’m not sure that I would take flow charts too formally, though. They are useful in visualising, but I certainly don’t think they’re necessarily the best way to plan a program.</p>

CC BY-SA 3.0
2017-10-11T15:37:58.863Z
@immibis it is a code maintainability problem in, say, business programming when you have a lot of things to check before doing something. And the list of tests has to change over time. In this case a flat list of tests + break if they fail is much easier to maintain over time.
Michel Billaud
CC BY-SA 3.0
2017-09-28T08:37:03.250Z
I agree that flow charts in non-programming contexts is often good. For example, to describe a manual procedure. Flowcharts are an abstraction of unstructured code, such as assembler. If your machine is a human, then this is appropriate.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T22:18:40.823Z
A former colleague of mine used GOTO as "elegant recovery from inelegant situations" --- dealing with catastrophic error conditions.
Peter K.
CC BY-SA 3.0
2017-09-29T14:11:30.847Z
@PeterK.: A specific example: error handling in a C function that took a lock.  [`linux/mm/msync.c`](https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/mm/msync.c#L103) uses `goto out_unlock;` inside many error-check `if()` clauses.  It implements a system call, so all its args are untrusted, and there are many return-error cases that are only detected after taking a lock.  It's C, so RAII to release the lock isn't an option.  Obviously this applies to any other cleanup task that you don't / can't use RAII for in whatever language.
Peter Cordes
CC BY-SA 3.0
2017-09-29T14:14:14.297Z
Can also be used for breaking out of a double-nested loop, although that's getting into spaghetti territory if done too much.  Some languages have a `break label` for this.  e.g. PERL has [`next LABEL`](https://perldoc.perl.org/functions/next.html) for outer loops.  Still possible to abuse, though.
Peter Cordes
CC BY-SA 3.0
2017-10-01T04:46:26.913Z
@PeterCordes actually you can use deeply-nested `if`s to do the same thing. A real anti-goto purist would make you do that. It's not as much of a readibility problem on modern wide monitors...
Criticize SE actions means ban
CC BY-SA 3.0
2017-09-28T03:11:29.200Z
2017-09-28T03:11:29.200Z
Manngo
<p>Why do you learn about bits and bytes if modern languages, with good reason, abstract from it? Why do we learn to program in assembler if modern languages, for good reason, abstract from it? Why do we learn bare-metal imperative programming if object oriented languages, with good reason, encapsulate it? Why do we learn C even though C++ offers much better ways to express ourselves? Why do we learn naked pointer semantics if smart pointers are the way to go?</p>

<p>The reason is that the less abstract concepts are the building blocks for the more abstract ones. (And, I might add, there are times when it is appropriate to be less abstract. There are times to use assembler, and goto, and pointers.) It helps to know assembler when you try to understand C. It also helps <em>appreciating</em> what the language does for you.  Knowing C, in turn, makes you understand C++ better (both its rationale and its limitations!).<sup>1</sup></p>

<p>It helps to know goto when you learn about loops, and what they do for you. </p>

<p>The same way it helps to know molecules if you try to understand a cell.</p>

<p><hr>
<sup>1</sup> It is also important to understand that machine independence and structured programming and object orientation are essentially <em>concepts</em> which are just more or less supported by the different languages. You certainly can write well-structured assembler. OO crept into my C after I grokked C++.</p>

CC BY-SA 3.0
2017-09-28T14:42:14.290Z
I think one of the best reasons to teach `goto` is so that people understand why it's problematic.  Often old bad ideas are recycled in software and it's the people that don't know the old ways that get suckered.  While your at it build an app in VB where all the code is buried in button events.  Then change the requirements.  Same goes for [doodleware](http://www.enterpriseintegrationpatterns.com/ramblings/02_doodleware.html).
JimmyJames
CC BY-SA 3.0
2017-10-02T12:33:15.667Z
reminiscent of the Law of Leaky Abstractions https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
Jodrell
CC BY-SA 3.0
2017-09-27T20:17:07.063Z
2017-09-29T23:59:43.317Z
2017-09-29T23:59:43.317Z
Peter - Reinstate Monica
<p><b>Don't teach it if you want Programmers </b>(know what they're doing)<b>. Do teach it if you want Computer Scientists </b>(know why they're doing it)<b>.</b></p>
<p>Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore <code>goto</code>; they'll never need to know it.</p>
<p>If you do want them to understand the why, then you have to teach it. If their code uses any sort of control flow, then at a lower level something somewhere is calling a <code>goto</code> (or something close), and CS students need to understand how that works.</p>
<p><strong>EDIT</strong>: I just reread <a href="http://www.u.arizona.edu/%7Erubinson/copyright_violations/Go_To_Considered_Harmful.html" rel="noreferrer">GOTO Statement Considered Harmful</a> and it actually ends with:</p>
<blockquote>
<p>The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.</p>
</blockquote>
<p>I know most of us have focused on the <code>goto</code> side of this question, hopefully this sheds some light on the flowchart side as well.</p>
<p>This line also reads to me as a confirmation that <code>goto</code> should be learned as a concept, since describing a control flow is nearly impossible without it, but Dijkstra still advocates avoiding it in code.</p>

CC BY-SA 3.0
2017-09-27T20:59:13.017Z
Hey LordFarquaad! Welcome to [cseducators.se]!
thesecretmaster
CC BY-SA 3.0
2017-09-28T01:57:33.837Z
Don't forget that COBOL is still the most prolific language out there, and all of the flow control in COBOL is through equivalents to GOTO
pojo-guy
CC BY-SA 3.0
2017-09-28T07:23:45.927Z
Although this makes sense as an answer, I'm not sure it will help the subset of teachers most at risk of incorrectly introducing GOTO to their cohort.
Sean Houlihane
CC BY-SA 3.0
2017-09-28T14:07:01.660Z
Well, @pojo-guy, you really should update to COBOL 85 or more recent. 

Cobol 74 really was a pain in the ***, but since 1985 it has all you need for structured programming : loops, if then else, and even a very interesting EVALUATE verb, much more powerful than the rudimentary switch of C/C++/Java etc :-)
Michel Billaud
CC BY-SA 3.0
2017-09-28T17:33:22.080Z
I agree that Evaluate is much more powerful than "switch", but COBOL is crippled in other ways. Problems that take three lines of java code can take hundreds of lines of COBOL code - for example finding the intersection set of two sets.  Each language expresses different thoughts easily, so they are all valuable.
pojo-guy
CC BY-SA 3.0
2017-09-28T19:01:54.543Z
This is a very good point, and one that maybe I should have thought of (given the name of the forum!) before posting my comment!
VisualMelon
CC BY-SA 3.0
2017-09-29T11:55:05.350Z
@pojo-guy COBOL has never been intended as a general purpose language, it has some dark spots, but ir does rather well in its category for a 60y old language. 
Remark that COBOLS's `add A to B C D` is much shorter than `B += A; C+= A; D += A;` :-).  Back to the point, it allows structured programming.
Michel Billaud
CC BY-SA 3.0
2017-09-29T12:24:50.843Z
@MichelBillaud Structured programming is a way of thinking, as is object oriented programming. I have done both in BASIC (olde style, not what is called BASIC today). COBOL expresses some thoughts more elegantly than other languages, and it is still far from dead. Now that it runs on a JVM, it will live another 60 years.
pojo-guy
CC BY-SA 3.0
2017-09-29T12:38:35.943Z
and it officially has objects since 2002, if you're desperate enough to use it (a lot of my students earn their life in Cobol code maintenance for banks - where the money is- but AFAIK everybody sticks to Cobol 85, no objects).
Michel Billaud
CC BY-SA 3.0
2017-09-29T13:58:17.350Z
@MichelBillaud it has objects, but they are skewed from what OO programemrs from other backgrounds think of as objects.  As one language junkie and COBOL guru friend of mine says, "Object Oriented COBOL is neither Object Oriented nor COBOL, but it makes a lot of sense for the right problems"
pojo-guy
CC BY-SA 3.0
2017-10-01T03:51:56.857Z
Except you'll never actually be good at it if you don't understand the why.  Thus everyone who is serious about it should learn the why.
Loren Pechtel
CC BY-SA 3.0
2017-09-27T20:42:39.510Z
2017-09-28T16:41:49.273Z
2020-06-18T08:36:57.023Z
Lord Farquaad
<p><strong>Flowcharts</strong> are a useful tool to understand programs that perform moderately complex sequences of interactions. They aren't always a good way to describe an algorithm, but they are a good way to describe the behavior of a system that reacts to external events in different ways depending on its state, with a non-linear control flow. Note that by <em>flowchart</em>, I'm not referring to a specific formalism — at this level of detail, I might as well call it a <em>state diagram</em> (although a proper <em>state diagram</em> requires a more precise understanding of what the different system states are before you can draw it). Flowcharts have their place in an imperative programming course, but only at a fairly advanced stage, <em>after</em> the students are familiar with basic control structures such as conditionals, loops and subroutines. They're a visual aid to understand complex control or data flow, in the same way that decision diagrams are a visual aid for complex series of conditionals.</p>

<p>The only good reason I can think of to introduce flowcharts early on is if the students started with a style of visual programming that resembles flowcharts. Otherwise, teach while loops first.</p>

<p><strong>Goto</strong> is an instruction that's hard to <em>really</em> understand. (If you think it's just a jump, you don't understand goto.) It's perfectly fine to teach imperative programming without goto, if you're doing it at any level that's higher than assembly (in which case what you'd teach is jumps). Goto is very rarely useful in the real world and is rarely used. Its place in a basic or intermediate imperative programming course is as an incidental mention, as something that exists, that you mention for the students' interest but isn't part of the curriculum and won't be on the exam.</p>

<p>I work in industry. I write software for embedded systems in C. Think I should be insisting on the importance of goto? Wrong. In my world, <code>goto</code> is almost exclusively used for one thing: a forward-only goto, a generalization of <code>break</code> that allows breaking to the end of any block. The single common idiomatic use of <code>goto</code> is to jump to a common cleanup code before returning from a function in C:</p>

<pre><code>int myfunction () {
    foo_t resource1;
    bar_t resource2;
    resource1 = allocate1();
    if (!resource1) goto cleanup;
    resource2 = allocate2();
    if (!resource2) goto cleanup;
    if (!do_stuff()) goto cleanup;
    …
    return 1;
  cleanup:
    free2(resource2);
    free1(resource1);
    return 0;
}
</code></pre>

<p>Many coding standards for embedded programming forbid using goto for anything else. In languages that have a better clean-up mechanism, such as try/finally or C++ destructors, goto is useless.</p>

<p>Understanding goto is a secondary skill for programmers, part of understanding how a program's code relates to the way the machine executes the program. A <em>good</em> programmer understands goto, but a <em>decent</em> programmer understands how to program without goto. The primary skill for a programmer is <strong>understanding how a program works</strong>, not understanding how a machine works. (There are exceptions, obviously — I write OS code, doing things like memory management and context switching and accessing peripherals, and that obviously requires a precise understanding of how the machine works. But that's a highly specialized field.)</p>

<p>The real difficulty with goto is, as I mentioned before, that it isn't just a jump. It's a jump <em>to a different context</em>. The invariants that hold at the location of the jump may not hold at the target location. A goto introduces a non-local connection between two points in a program that makes it hard to figure out how the program state evolves and what invariants hold. </p>

<p>Paul Powell's statement that “GOTO (…) is easy to understand” is just wrong. What's easy to understand is <em>how a machine executes a goto statement</em>. But the most important part, understanding <em>how a program that uses goto works</em>, is difficult. The statement that “it can be used to explain what loops and other items of structured programming actually are” also completely misses the point. Goto can explain <em>how structured programming items are implemented on a processor</em>. It explains an implementation, not the concept. Goto is an advanced step after structured imperative programming, not a step before.</p>

<p>Using goto to encode flowcharts is also very misguided. With goto, “we can code directly from a flow chart” — this is true: goto makes it easier to write a program from a flowchart without understanding how the program works, without figuring out the structure in the flow of events. But when you do that, you end up with a write-only program. Sure, you've been able to write it, but you won't be able to explain its behavior when a parameter that isn't reflected in the flowchart turns out to be important, or to modify it in a way that isn't easy to draw on the chart. Write-only programming is the mark of a mediocre programmer, capable only to fumble in the dark until they somehow manage to pass the tests.</p>

<p>Goto has its place when you teach how a machine executes code. It's what's happening under the hood. It has little to no place in teaching how to program, and Dijkstra would be quite right to complain about its use in this context.</p>

CC BY-SA 3.0
2017-09-29T07:18:32.633Z
And your experience of delivering this knowledge to 28 mixed ability 11 year olds is?
Paul Powell
CC BY-SA 3.0
2017-09-29T08:05:46.113Z
@PaulPowell  Teaching goto is not the problem. It may even be easier that teaching structured programming. But then you have a class full of pupils that need to be un-taught. I have been in gilles position, and have had people on my team that have been taught these bad habits. It can take longer to un-teach them, than it took you to teach them. Use scratch as a basis (this is taught to 7 year olds), then have them translate scratch programs into python (see https://cseducators.stackexchange.com/a/178/204 ). Both languages do not have `goto`.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-29T10:22:13.860Z
I am an experienced Head of Department with a degree in Computer Science and 12 years in industry. Do you really think I have not tried this or thought about it?
Paul Powell
CC BY-SA 3.0
2017-09-29T14:23:03.093Z
Real-world example of `goto` for cleanup: [`linux/mm/msync.c`](https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/mm/msync.c#L103) uses `goto out_unlock;` inside many error-check `if()` clauses.  It implements a system call, so all its args are untrusted, and there are many return-error cases that are only detected after taking a lock.  It's C, so RAII to release the lock isn't an option.  (There are 12,987 hits for `goto` in the Linux kernel tree; all like this or `asm goto` as a way of optimizing `if (asm_statement)` to avoid producing an actual boolean.)
Peter Cordes
CC BY-SA 3.0
2017-09-29T16:36:29.190Z
@PaulPowell I don't have any experience teaching this to 11 year olds, but I have as much industry experience, and I'm telling you that your teaching will neither make them better programmers nor make it easier for them to learn. The example you cite from the Linux kernel is an example of the pattern I state as being the only common use case for goto in my world.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-29T17:12:18.330Z
Firstly, the Linux comment wasn't made by me. Secondly, If you have no experience of KS3 education then what, apart from the height of arrogance, compels you to presume it works how you think it does?
Paul Powell
CC BY-SA 3.0
2017-09-29T20:36:15.693Z
"If you think it's just a jump, you don't understand goto"  Wow, well aren't you a gate keeper?  We don't need this kind of language on any Stack Exchange site, especially not a site for educators with the explicit purpose of making CS education better.    Always, *always* explain after statements "if you think X, your are wrong".  If you don't, all you've said is "I think I know something you don't, and I just wanted to let you know that", and I really hope I don't have to explain what is wrong with that statement.
Krupip
CC BY-SA 3.0
2017-09-29T20:44:29.980Z
@snb I recommend that you read my answer, not just one sentence. I *do* explain why goto isn't just a jump.
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-29T20:55:20.737Z
@PaulPowell By the way, your authority argument might conceivably carry some weight if you at any point explained why goto is better suited for 11 year olds than for adults (undergrads and up).
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-29T20:59:14.263Z
@Gilles No you don't explain why it isn't a jump, you state " It's a jump to a different context ", and no, underneath it would still be a jump regardless, with semantic rule control in the compiler if you're in a language like C++, goto is a jump.   You seemed to want to find a way to display arrogance when what you actually should have said is "Goto isn't dangerous because you jump to another point in a program, its dangerous because that jump to a completely different context in the program. The invariants that ...."  with out your gate keeping statement.
Krupip
CC BY-SA 3.0
2017-09-29T22:01:12.347Z
@Gilles, if you teach undergrads then you are looking, at worst, at the brightest 50% of the population. Imagine your brightest undergrad and your absolute dimmest. Now imagine someone who is that much less able again. Now imagine all of them have six or seven fewer years of being educated. To put you in the picture, I spent 5 minutes today with a Y11 student exploring different ways he could attempt the sum 21/3. He is at the bottom of the range and although he eventually could do it today, he will have the same problem tomorrow, the day after and probably for the rest of his life.
Paul Powell
CC BY-SA 3.0
2017-09-29T22:01:36.903Z
Difference enough for you?
Paul Powell
CC BY-SA 3.0
2017-09-29T22:19:42.027Z
@PaulPowell I'm well aware that teaching to Y11 is vastly different from teaching to undergrads. What I fail to see is why goto would be more appropriate to Y11. It's a very complicated concept. Why on earth would you teach the more complicated concept to middle schoolers?
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-30T08:00:55.030Z
First I said year KS3 is where I am doing this, not Y11. I gave a Y11 example it illustrate where the bottom of the ability range is, although if I were required to teach this child CS I may well use GOTO. You might be theretically aware, but try going to a local non-selective comprehensive and teaching a class (not a selected group) of year 7s. Then try the same thing in London.
Paul Powell
CC BY-SA 3.0
2017-09-30T08:02:11.823Z
The whole article and everything else says that this is an experiment, so I don't know if they will find it easier yet as we are just getting started.
Paul Powell
CC BY-SA 3.0
2017-09-30T08:20:41.233Z
You are asking me to say what is simple about goto (which is always harder than saying why it is complicated). Two things, first: one line one sttatement, one action for all statements. Secondly, context is pretty much irrelevant at this stage - about the worst you could do is reference a variable before it has been defined. Thirdly, they don't have to think about what is in and outside the loop - just what happens next. We are using BASIC 256 as our language. Now you tell me what is so complicated about this.
Paul Powell
CC BY-SA 3.0
2017-10-02T02:07:37.470Z
I upvoted. I am a retired software engineer who learned programming using BASIC in 1981. Basic's `GOTO` was the *most confusing* part of trying to learn how to program, and I had real trouble with control flow in more complex programs until I encountered structured control flow in Pascal, ca. 1985. I later programmed quite a bit in assembly language, even microcode, where understanding the concept of GOTO is useful. My programming teaching experience is limited to being a TA at university. Based on that: GOTO is an *advanced* concept that should be kept away from beginners learning a HLL
njuffa
CC BY-SA 3.0
2017-09-28T22:56:33.063Z
2017-09-28T22:56:33.063Z
Gilles 'SO- stop being evil'
<p>The real question here seems more like <strong>when</strong> should you teach <code>goto</code> rather than <strong>if</strong> you should teach it.</p>

<p>The first example programs should certainly not be looking like those we wrote on the machines in <a href="https://www.whsmith.co.uk" rel="nofollow noreferrer">WH Smith</a> on the way home from school:</p>

<pre><code>10 PRINT "HELLO WORLD!"  
20 GOTO 10
</code></pre>

<p>A <code>while true</code> construct is more sensible here. However, if you introduce your students to programming by demonstrating the low-level operation of the CPU (fetch/decode/execute) then it's more likely that you'll need a force-pc (although typically it also needs to be conditional).</p>

<p>The assembly language constructs typically don't quite match high-level languages exactly (e.g. count down rather than up, in a loop to allow compare-and-branch-if-zero), but at some point your course will probably link high level languages to machine operations.</p>

<p>To clarify, I'm not suggesting that it is sensible to start by introducing the full scope of:  </p>

<pre><code> while (expression == TRUE) {stuff, including maybe break};
</code></pre>

<p>rather keep the templates simple and expand the linguistic elements progressively. <code>while (TRUE)</code> is just a compound keyword when it's first needed, just like <code>GOTO &lt;LABEL&gt;</code>.</p>

<p>It should be easy to explain that modern high level languages are designed so that humans can understand the code. That is why there are usually several different ways of expressing control flow even though to a beginner they all look interchangeable. In the absence of any more specific reason, <code>goto</code> is likely to come at the end of your list of 'possible control flow changes' and probably needs to be introduced as an instruction which has been mostly replaced in modern programming, <em>because other constructs are better</em>, not simply because <em>goto is bad</em>.</p>

<p>The best reason I can think of for introducing <code>goto</code> is that the concept might help when it comes to explaining hardware interrupts (being the most important part of CPU architecture which isn't even mentioned in far too many courses).</p>

CC BY-SA 3.0
2017-09-28T08:06:07.093Z
I agree, except the last paragraph, interrupts cause subroutine calls, not `goto`.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T09:05:10.490Z
@ctrl-alt-delor That's just a force-pc with some side effects. Where goto fits as a better analogy is that exceptions are less structured. SVC can be considered a subroutine because it is planned, IRQ less so (although it uses an identical mechanism).
Sean Houlihane
CC BY-SA 3.0
2017-09-28T13:42:01.190Z
Why is while(true): in any way more sensible? Write down a full explanation of how the two bits of code work. Which is simpler to understand?
Paul Powell
CC BY-SA 3.0
2017-09-28T13:56:54.617Z
@PaulPowell `While (true)` captures the intent, not the mechanics of how the code operates. If you look at [tag:coding-style] there are several questions about readability and intent. Professionally, readability is the critical thing students need, so I think this has to come first. Generally, when you start to teach coding, the 'how it works' involves a lot of abstraction, so using 1980's style doesn't make sense. This question has slightly missed the point in your article that the 'how it works' really is important. To explain how it works, `BEQ`, `CBZ` are preferable to `GOTO` IMO.
Sean Houlihane
CC BY-SA 3.0
2017-09-28T13:59:29.023Z
@PaulPowell It might be interesting if you ask your question about how control flow teaching is leaving gaps - particularly if you have specific student groups in mind.
Sean Houlihane
CC BY-SA 3.0
2017-09-28T14:15:14.283Z
@sean I think it is simpler than leaving gaps. It is about a student being able to express themselves in code. Did you try writing down a full explanation of while true?
Paul Powell
CC BY-SA 3.0
2017-09-28T14:16:32.567Z
Really awkward leaving comments here as I can only access it on mobile at the moment.
Paul Powell
CC BY-SA 3.0
2017-09-29T12:45:35.833Z
I'd take a guess and say that it might be easier for some coders to grasp programming when there is one action per line (where each line has text), maybe it's easier for them to understand `JMP wherever` instead of `while(condition) {}` (where the brace at the end means "go back up to the beginning". When I first started I remember a C `for` loop seemed very daunting and I had a hard time remembering it (e.g.: "When do each of these things in the parentheses even run? Once? After the loop? Before it? Both?").
jrh
CC BY-SA 3.0
2017-09-29T13:04:26.707Z
@jrh - See edit.
Sean Houlihane
CC BY-SA 3.0
2017-09-28T07:50:05.670Z
2017-09-29T13:03:10.573Z
2017-09-29T13:03:10.573Z
Sean Houlihane
<p>Binary digital computers (and the execution of most programming languages) are just big state machines at their very heart.  State machines usually require non-sequential state changes.  e.g. <code>goto</code>s</p>

<p>A flow chart is a form of state machine.  (superset or subset?)</p>

<p>You need goto's to learn jump statements in assembly language, asm to learn machine code, and machine code to understand CPU architecture and design.  Understanding computer hardware logic and state machines seems important to any CS degree.  As for difficulty of learning machine code, many thousands of student-aged kids learned to poke 6502 and Z80 op codes back in the day...</p>

CC BY-SA 3.0
2017-09-28T16:47:28.670Z
2017-10-13T12:49:36.847Z
2017-10-13T12:49:36.847Z
hotpaw2
<p>I teach a college level introductory computer science course, where the primary goal is to learn programming in Java with no assumed prior programming experience.</p>

<p>I do teach flow charting when I cover decision making &amp; looping. Flowcharts aren't a great tool for an entire non-trivial program. They are a reasonable tool for high level algorithm design and for code level representation of methods. Furthermore, most students have seen a flowchart of some type before &amp; I find that any degree of familiarity is helpful to those who find programming to be an otherwise foreign concept. I need to reach as many of my students as  possible &amp; find flowcharts to be worth leveraging in that regard.</p>

<p>I do not cover use of <code>goto</code> beyond stating that it exists, it's easy to misuse and typically by the time they might encounter it in a production environment, they should have accumulated enough programming acumen to deal with it as needed. It's not a core piece of the language &amp; there's plenty of other material that sees more routine usage that could use its time.</p>

CC BY-SA 3.0
2017-09-27T21:41:38.463Z
2017-09-28T00:25:14.193Z
2017-09-28T00:25:14.193Z
Pikalek
<p>I will concern myself mostly with <code>goto</code>, but first a little on flow charts.</p>

<h1>On Flow charts</h1>

<p>I see flow charts as just a ways to visually represent goto-ful low-level algorithms/code.</p>

<h2>What flow charts are not</h2>

<p>Some other answers have mixed up their use with state-machines, or decision trees. Doing this could result in coding each code path separately, this would result in an undesirable increased program-size. For example for a sorting algorithm, of we could get a code size complexity of $O(n!)$. This does not scale, much beyond sorting 3 items, and you will use all of you computers memory (just for the program to sort 16 items). </p>

<h3>Good uses of flow charts</h3>

<p>The low-level nature of flowcharts can be of great value, when creating a procedure to be carried out by humans. I.e. A first aid flowchart.</p>

<h1>On <code>goto</code> statement and goto</h1>

<p>In the paper “Go To Statement Considered Harmful”, Dijkstra is concerned with the <code>goto</code> statement, not with goto. He points out that all higher order structures will use <code>goto</code> in their implementation. According to Dijkstra, this implementation is not the problem, only the direct use of <code>goto</code>. 
In the time since his paper the structure he mentions, <code>if</code>, <code>else</code>, <code>while</code>, <code>for</code>, <code>until</code>, <code>repeat</code>, and sub-routines have been part of our high-level languages. For his call was not for us to stop using it in programs, but to create languages that did not require it, and then to stop using it. And in the meantime to use it only in a structured way, to simulate the structures. Therefore only use it if your language does not provide the high-level structure that you need, and know which structure you are simulating (don't ad-hok it).</p>

<blockquote>
  <p>For a number of years I have been familiar with the observation that the quality of programmers is a
  decreasing function of the density of go to statements in the programs they produce. More recently I
  discovered why the use of the go to statement has such disastrous effects, and I became convinced that
  the go to statement should be abolished from all "higher level" programming languages (i.e. everything
  except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I
  now submit my considerations for publication because in very recent discussions in which the subject
  turned up, I have been urged to do so. (Edsger Dijkstra)</p>
</blockquote>

<h3>Good uses of <code>goto</code> statement</h3>

<ul>
<li>Programming in assembler, though you should not have much assembler language in your project.</li>
<li>Compilers/generators: These will use <code>goto</code> to create higher-level structures.</li>
<li>To over come limitations of the language, but consider changing language: In <code>C</code> you may use <code>goto</code> to implement exception handling. However ensure that you have a clear idea of the structures that you are implementing. Do not use <code>goto</code> in an ad-hoc way.</li>
</ul>

<h3>When <code>goto</code> can seem like a good idea.</h3>

<p><code>goto</code> is easy to understand, how it does it. However the code that you create (beyond the most trivial) is not easy to understand what it does.</p>

<blockquote>
  <p>My second remark is that our intellectual powers are rather geared to master static relations and that our
  powers to visualize processes evolving in time are relatively poorly developed. For that reason we should
  do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the
  static program and the dynamic process, to make the correspondence between the program (spread out in
  text space) and the process (spread out in time) as trivial as possible.</p>
</blockquote>

<p>That is our attempts to understand a large system, in terms of how it works in a dynamic way, are going to be very limited. However it is possible to view the system in a static way, and thus make it easier for our brains to comprehend. To do this we must let go of a little of the how. We do not seem to have a problem with this in most cases: we care not how <code>print</code> is implemented.  </p>

<h3>On assembler code and machines</h3>

<p>So our CPUs use goto (<code>jmp</code> instructions). So what, unless you are teaching assembler language and CPUs.</p>

<p>But do all CPUs use goto? Possibly not, I am not an expert on this. However here is a discussion on what modern CPUs think of goto/jmp.</p>

<p>That happens when a modern (instruction pipelined cpu), fetches a conditional jump instruction?</p>

<p>All is not well, first it tries to guess which way the branch will go, then it goes that way. If it get it wrong it hits the brakes, backs up and tries again. The circuitry in the x86 for making this guess, is huge. The x86 does not like goto. What about the ARM, its branch prediction circuit is tiny (if it is a branch back, then assume that the branch will be taken, else assume that it will not), The ARM is better at predicting branches than the x86, but how? The arm has more conditional instructions, that is, it has selection built in. This allows it to avoid goto a lot of the time. Its simplistic algorithm then assumes that a jump backward is a loop, and a jump forward is a selection. So though iteration is not explicitly encoded, and selection is only sometimes explicitly encoded. This shows that knowledge of the programs structure is not just a high level thing, it can help the CPU's performance.</p>

<h2>The paper cited by @Miles on CAS</h2>

<p>As Miles says it showed no benefit of flowcharts. But also not it was year 1977, and they were fortran programmers (goto users). It may be that if the experiment was repeated with the control group using structured programming, that the effect may be negative.</p>

<h2>Conclusion</h2>

<p>While it will be quicker to teach</p>

<pre><code>10 print "Hello, World"
20 goto 10
</code></pre>

<p>than</p>

<pre><code>forever:
    print "Hello, World"
</code></pre>

<p>However making the first step easier will make all subsequent steps harder.
Someone once said, “Never hire any one that knows basic. They will have been so irreparably damaged by the experience of <code>goto</code>s, that no amount of re-rehabilitation can save them.”, while I do not agree with this statement, there is some truth in it.</p>

<p>Could it be used when teaching for, while, if, etc. As opposed to as a way to program.</p>

<p>Therefore,
only teach <code>goto</code>, when teaching assembler language, or at a late stage in high-level programming. However first teach the higher level structures, and make it clear that <code>goto</code> is only a work around for lack of higher-level structures in the language. And consider its use in teaching structured programming.</p>

<p><strong>HOWEVER</strong> the article opened a very important question. We need to keep exploring ideas for teaching. Well done @PaulPowell </p>

CC BY-SA 3.0
2017-10-01T12:58:45.960Z
2017-12-03T15:14:31.647Z
2017-12-03T15:14:31.647Z
ctrl-alt-delor
<p>I was recently reading a new, and mostly excellent, magazine <a href="https://helloworld.raspberrypi.org/issues/3" rel="nofollow noreferrer">Hello, World</a>. There is an article on teaching <code>goto</code>. The author states that there is value in teaching <code>goto</code>, as it helps to translate flowcharts into code.</p>

<p>I have always considered <code>goto</code> to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper “Go To Statement Considered Harmful“ — Edsger W. Dijkstra, but because it is self evident (once you have tried structured-programming).</p>

<p>I have always considered flow-charts the same way. They are just the pictorial form of unstructured code (The UML of assembly language).</p>

<p>So the question:</p>

<p>Does the author have a point? Is there some value in <code>goto</code> or flow-charts?</p>

<p>I accept that:</p>

<ul>
<li>Flowcharts are visual, but there are visual structured representations that are better.</li>
<li><code>goto</code> can/has-to be used in teaching assembly language/machine code.</li>
</ul>

<hr>

<p>One of many links to the paper “<a href="http://www.dcs.gla.ac.uk/~pat/cpM/choco3/cpM/nqueens/Goto-Harmful-Dijkstra.pdf" rel="nofollow noreferrer">Go To Statement Considered Harmful</a>”</p>

CC BY-SA 3.0
2017-10-09T01:43:52.803Z
I never teach this statement. It is a guaranteed creator of congealed spaghetti code.  Do things in a structured way.
ncmathsadist
CC BY-SA 3.0
2017-10-11T10:14:58.033Z
structured-programming control structures are not always the clearest way to express the variety of "structures" you have in mind when programming. An easy example : business application where you have to do a dozen of tests (like field contents is numeric or blank, value doesnt exceed something etc.) before doing the real job.  You probably dont have a 12-level intrication in mind.
Michel Billaud
CC BY-SA 3.0
2017-10-11T13:37:14.513Z
@MichelBillaud I have worked on very complex systems. I write highly structured code, and never go beyond 4 levels of indentation, and rarely more than 3. I have heard all the excuses before. You can not untangle spaghetti; If you think spaghetti, it is too late. You can not convert it in to structured.
ctrl-alt-delor
CC BY-SA 3.0
2017-10-11T16:20:48.400Z
@ctrl-alt-delor I'm impressed by the argument of authority :-) I'm not advocating for spaghetti code. If you have ten things to check before doing some thing, better write is as "action 1 ; if test1 fails return; action 2, if test2 fails return; .... if test10 fails return; you_can_do_it_now()" the code is easier to maintain than multi level imbrication.  That's not unstructured code, but structured ideas expressed in a language lacking the proper control structures. Talking about authorities in SP, even Disjkstra had his "skip" and "abort" statements...
Michel Billaud
CC BY-SA 3.0
2017-10-11T18:01:33.213Z
@MichelBillaud I have just noticed in your fist comment: “control structures are not always the clearest way to express the variety of "[control] structures"”. I think you are saying that sometimes even modern languages, lack the needed control structures, so sometimes we still need to synthesise them with a jump/goto. (see my answer, I think I covered this.)
ctrl-alt-delor
CC BY-SA 3.0
2017-09-27T18:29:27.560Z
I disagree that `goto` has no place; I would agree that there is little value in teaching it to new programmers: it can be mentioned (and discouraged) and they can work it out for themselves when (if) they need it. There is nothing to it if you can already 'read' code, and one is more likely to understand why it is generally inadvisable with an existing understanding of higher-level flow-control techniques (as opposed to "Here is `goto`! NEVER USE IT")
VisualMelon
CC BY-SA 3.0
2017-09-27T20:32:15.670Z
As an old programmer (learned on a TRS-80 in 1980), I think that teaching GOTO **is** a good idea, because it teaches the students that at the bottom of all that fancy flow control and OO stuff are nothing but jumps (both conditional and unconditional) and pointers.
RonJohn
CC BY-SA 3.0
2017-09-27T23:31:10.190Z
You'd be surprised how many people don't seem to get "the computer does things in the order they're written" - flowcharts *might* help explain that.
Criticize SE actions means ban
CC BY-SA 3.0
2017-09-28T06:59:45.107Z
@immibis "computer doing things in order" : a typical misunderstanding is thinking that during a `while ( x != 0) { statements; }`, the `x` variable is monitored  during the statements execution, and the loop break as soon as `x` gets the value 0.
Michel Billaud
CC BY-SA 3.0
2017-09-28T07:50:58.210Z
If you don't teach the kids about `goto`, they will learn it on the streets.
Simon Richter
CC BY-SA 3.0
2017-09-28T16:14:12.063Z
You are confusing the "goto concept" with the "goto keyword" - the latter of which is generally considered bad, but that's actually more of a religious objection than a practical one. Every loop, every recursion, every function call, is a GOTO/GOSUB conceptually. We can't program anything without that concept.
Jasmine
CC BY-SA 3.0
2017-09-28T16:28:47.097Z
@Jasmine the article is advocating direct use of goto, that is by using the `goto` keyword. I have said that goto is useful in teaching assembler language (they have branch/jump instructions).
ctrl-alt-delor
CC BY-SA 3.0
2017-09-28T18:35:33.570Z
[Relevant xkcd](http://xkcd.com/292/)
SIGSTACKFAULT
CC BY-SA 3.0
2017-09-28T21:42:32.977Z
Flow charts show up again in intermediate computer science in the form of finite state machines, which are basically flowcharts with set theory thrown at them in order to be mathematically precise.
Kevin
CC BY-SA 3.0
2017-09-29T02:42:32.390Z
Look at it from the other end of the telescope:: Language features like if-then-else, while loops, break and continue keywords in loops, case constructs, catch-throw exceptions, function calls, recursion, etc, etc are just syntactic sugar to avoid using that nasty G-word (and in some instances, to avoid explicitly using a stack as well). Of course you can use the G-word for other programming purposes as well as the ones where the language designers gave you a sugar-coated alternative - and some of them are perfectly good ways to write code in real life, but others are not!
alephzero
CC BY-SA 3.0
2017-09-29T17:40:03.237Z
There is always value in teaching flow charts, at least in my opinion. (Disclosure: I am not an educator, just a programmer :) )
Restioson
CC BY-SA 3.0
2017-09-29T18:48:10.410Z
@Restioson your comment has no information, except that you have an opinion. Can you elaborate?
ctrl-alt-delor
CC BY-SA 3.0
2017-09-30T09:11:25.650Z
@ctrl-alt-deor oh, I'm sorry, I accidentally left that out I guess. Essentially, I see great value in being able to reconcile code with the flow of your program, and being able to visualise it like that. It's an exceptionally useful debugging tool too - whenever I have mangled or wrong output, I mentally step through my program, like a flowchart, to see what's gone wrong
Restioson
CC BY-SA 3.0
2017-09-30T13:15:41.947Z
@ctrl-alt-delor Not to be flippant, (well, a little) but what is `IF THEN ELSE` but a giant Go-To? As in: **Step-Skipper**?
But please show us the 1960 article, so we can judgje for our selves.     
For now, it seems that your own biases have led you to a hasty judgment.
GwenKillerby
CC BY-SA 3.0
2017-09-30T16:53:06.347Z
@GwenKillerby I have added a link to one of the copies of the paper. You are correct `if` `then` `else` `while` `for` etc all use `goto`, however Dijkstra's argument was that these are some safe ways to use `goto`. We call it structured programming. I and others would argue that this is not enough, that conditionals, and mutation are also a problem, but like `goto` they can be tamed with appropriate structures. I use conditionals and mutation very little, and have an intuition an how to use them well. As a consequence my code have very few bugs.
ctrl-alt-delor
CC BY-SA 3.0
2017-10-02T04:22:14.843Z
goto *can* be helpful in languages such as C to avoid repeating oneself in error handling code, where its scope handling provides a legitimate advantage, as well as in escaping multiple nested loops.
Yet Another User
CC BY-SA 3.0
2017-10-03T09:38:20.533Z
Last flowchart I did was in 1979, and I never had much faith in them even when I was taught them in 1971. For a start they reduce every non-trivial and trivial action or decision to the same sized box. For another thing, they draw on graphic skills that CS students tend not to have: at least I didn't. There is no harm and indeed a considerable necessity in teaching `JMP`, but `goto` as a language construct has certainly seen its last hurrah.
user207421
<flowcharts><goto>
Is there any value in teaching goto statement or flowcharts?
# Is there any value in teaching goto statement or flowcharts?

(Asked by: username_0 on 2017-09-27)

I was recently reading a new, and mostly excellent, magazine [Hello, World](https://helloworld.raspberrypi.org/issues/3). There is an article on teaching `goto`. The author states that there is value in teaching `goto`, as it helps to translate flowcharts into code.

I have always considered `goto` to be harmful. It results in code that is buggy and hard to read. Not just because I read it in a 1960 paper “Go To Statement Considered Harmful“ — Edsger W. Dijkstra, but because it is self evident (once you have tried structured-programming).

I have always considered flow-charts the same way. They are just the pictorial form of unstructured code (The UML of assembly language).

So the question:

Does the author have a point? Is there some value in `goto` or flow-charts?

I accept that:

* Flowcharts are visual, but there are visual structured representations that are better.
* `goto` can/has-to be used in teaching assembly language/machine code.

---

One of many links to the paper “[Go To Statement Considered Harmful](http://www.dcs.gla.ac.uk/~pat/cpM/choco3/cpM/nqueens/Goto-Harmful-Dijkstra.pdf)”

**Tags:** flowcharts, goto

> **Comments:**
> **username_3**: I disagree that `goto` has no place; I would agree that there is little value in teaching it to new programmers: it can be mentioned (and discouraged) and they can work it out for themselves when (if) they need it. There is nothing to it if you can already 'read' code, and one is more likely to understand why it is generally inadvisable with an existing understanding of higher-level flow-control techniques (as opposed to "Here is `goto`! NEVER USE IT")  
> **username_4**: As an old programmer (learned on a TRS-80 in 1980), I think that teaching GOTO **is** a good idea, because it teaches the students that at the bottom of all that fancy flow control and OO stuff are nothing but jumps (both conditional and unconditional) and pointers.  
> **username_5**: You'd be surprised how many people don't seem to get "the computer does things in the order they're written" - flowcharts *might* help explain that.  
> **username_2**: @immibis "computer doing things in order" : a typical misunderstanding is thinking that during a `while ( x != 0) { statements; }`, the `x` variable is monitored  during the statements execution, and the loop break as soon as `x` gets the value 0.  
> **username_6**: If you don't teach the kids about `goto`, they will learn it on the streets.  
> **username_7**: You are confusing the "goto concept" with the "goto keyword" - the latter of which is generally considered bad, but that's actually more of a religious objection than a practical one. Every loop, every recursion, every function call, is a GOTO/GOSUB conceptually. We can't program anything without that concept.  
> **username_0**: @username_7 the article is advocating direct use of goto, that is by using the `goto` keyword. I have said that goto is useful in teaching assembler language (they have branch/jump instructions).  
> **username_8**: [Relevant xkcd](http://xkcd.com/292/)  
> **username_9**: Flow charts show up again in intermediate computer science in the form of finite state machines, which are basically flowcharts with set theory thrown at them in order to be mathematically precise.  
> **username_10**: Look at it from the other end of the telescope:: Language features like if-then-else, while loops, break and continue keywords in loops, case constructs, catch-throw exceptions, function calls, recursion, etc, etc are just syntactic sugar to avoid using that nasty G-word (and in some instances, to avoid explicitly using a stack as well). Of course you can use the G-word for other programming purposes as well as the ones where the language designers gave you a sugar-coated alternative - and some of them are perfectly good ways to write code in real life, but others are not!  
> **username_11**: There is always value in teaching flow charts, at least in my opinion. (Disclosure: I am not an educator, just a programmer :) )  
> **username_0**: @username_11 your comment has no information, except that you have an opinion. Can you elaborate?  
> **username_11**: @ctrl-alt-deor oh, I'm sorry, I accidentally left that out I guess. Essentially, I see great value in being able to reconcile code with the flow of your program, and being able to visualise it like that. It's an exceptionally useful debugging tool too - whenever I have mangled or wrong output, I mentally step through my program, like a flowchart, to see what's gone wrong  
> **username_12**: @username_0 Not to be flippant, (well, a little) but what is `IF THEN ELSE` but a giant Go-To? As in: **Step-Skipper**? But please show us the 1960 article, so we can judgje for our selves.      For now, it seems that your own biases have led you to a hasty judgment.  
> **username_0**: @username_12 I have added a link to one of the copies of the paper. You are correct `if` `then` `else` `while` `for` etc all use `goto`, however Dijkstra's argument was that these are some safe ways to use `goto`. We call it structured programming. I and others would argue that this is not enough, that conditionals, and mutation are also a problem, but like `goto` they can be tamed with appropriate structures. I use conditionals and mutation very little, and have an intuition an how to use them well. As a consequence my code have very few bugs.  
> **username_13**: goto *can* be helpful in languages such as C to avoid repeating oneself in error handling code, where its scope handling provides a legitimate advantage, as well as in escaping multiple nested loops.  
> **username_14**: Last flowchart I did was in 1979, and I never had much faith in them even when I was taught them in 1971. For a start they reduce every non-trivial and trivial action or decision to the same sized box. For another thing, they draw on graphic skills that CS students tend not to have: at least I didn't. There is no harm and indeed a considerable necessity in teaching `JMP`, but `goto` as a language construct has certainly seen its last hurrah.  
> **username_1**: I never teach this statement. It is a guaranteed creator of congealed spaghetti code.  Do things in a structured way.  
> **username_2**: structured-programming control structures are not always the clearest way to express the variety of "structures" you have in mind when programming. An easy example : business application where you have to do a dozen of tests (like field contents is numeric or blank, value doesnt exceed something etc.) before doing the real job.  You probably dont have a 12-level intrication in mind.  
> **username_0**: @MichelBillaud I have worked on very complex systems. I write highly structured code, and never go beyond 4 levels of indentation, and rarely more than 3. I have heard all the excuses before. You can not untangle spaghetti; If you think spaghetti, it is too late. You can not convert it in to structured.  
> **username_2**: @username_0 I'm impressed by the argument of authority :-) I'm not advocating for spaghetti code. If you have ten things to check before doing some thing, better write is as "action 1 ; if test1 fails return; action 2, if test2 fails return; .... if test10 fails return; you_can_do_it_now()" the code is easier to maintain than multi level imbrication.  That's not unstructured code, but structured ideas expressed in a language lacking the proper control structures. Talking about authorities in SP, even Disjkstra had his "skip" and "abort" statements...  
> **username_0**: @MichelBillaud I have just noticed in your fist comment: “control structures are not always the clearest way to express the variety of "[control] structures"”. I think you are saying that sometimes even modern languages, lack the needed control structures, so sometimes we still need to synthesise them with a jump/goto. (see my answer, I think I covered this.)  

---

## 16 answers

### Answer by username_18 on 2017-09-27. Score: 5 | Accepted answer

If you are teaching assembly code or maybe Fortran then probably you need to discuss `goto` and possibly flow charts. However, if you are teaching a modern high level language, even something as old as Pascal, you should probably avoid them other than as an historic curiosity. This was settled almost 50 years ago, actually.

Along with some other illuminati of CS, David Gries has always used the term "flaw chart" for the classic diagraming technique. It is too easy with such tools to create unmaintainable code.

There is a form of *Structured Flow Chart*, however, which is not much different from, say, Pascal. It has no arrows, but, basically, only containment and sequencing of structures. But even that is probably just a waste of time as the constructs of modern languages make it unnecessary.

Even if you are programming in a language that requires `goto` however, you should probably only use structures like `if-then` and `while-do` that have been proven to be sufficient and also result in better (maintainable, understandable) code. Just Say No.

On the other hand, there is one reason for teaching `goto` to students of modern languages. If those languages permit `goto` then eventually the student will need to read programs that contain them even if they don't write such programs. So, purely as a defensive measure, they should know how to interpret these programs even as they disparage the authors of those programs.

There is a story from the past that is illuminating. In the old days IBM had a company policy that every program had to be documented with flow charts. However, they also had a tool that would create a flow chart from a Fortran program. So, the program was written, then the tool produced its flow chart, often spread over many, many pages. But the policy was satisfied. But, as a design tool, no.

See: <https://en.wikipedia.org/wiki/Considered_harmful>

> **Comments:**
> **username_0**: I have used a tool to automaticaly create UML class diagrams form code. Because we needed them, it was policy.  
> **username_23**: Flowcharts work well as a tool to define/describe the desired flow (on a higher level) of a program. They can be important tools when explaining your program to a stakeholder or when attempting to grasp a new subject domain that you are developing for. I would argue they're not a waste of time to learn when used correctly.  
> **username_2**: There are cases where you really *need* goto or labelled break. Example :       outer_loop :  for (X x : list_of_X) {                            for (Y y: list_of_Y) {                               if (some_condition(x,y)) {                                  do_something_with(x,y);                                  break outer_loop;                            } }  
> **username_18**: Well, _need_ is relative. You have set up a case in which a targeted break is really _convenient_ but there are other solutions to such a problem. Otherwise Python programmers would be just _stuck_.  
> **username_18**: Nor is a targeted break, precisely speaking, a _goto_, though easy to explain as if it were, assuming your students know about `goto`. But it isn't necessary to explain it as a specialization of a wild _goto_ when they don't.  
> **username_2**: @buffy, My best effort, with a boolean, looks like this  `boolean want_to_leave = false; for (int i = 0; ! want_to_leave && i < list1.size(); i++) {   String w1 = list1.get(i);   for (int j = 0; ! want_to_leave && j < list2.size(); j++) {     String w2 = list2.get(j);     if (w1.length() == w2.length()) {       println(w1, " ", w2);       want_to_leave = true;     }   } }`  and doesnt seem much clearer than `outer:  for (String w1 : list1) {   for (String w2 : list2) {     if (w1.length() == w2.length()) {       println(w1, " ", w2);       break outer;     }   } }`.  
> **username_10**: @username_18 have you actually USED Fortran in the 20 years or so? You do realize it now even has classes? - plus a whole range of other "structured" features of course. Sure, there are one or two things that still *need* the concept of gotos and statement labels (like low-level error handling in I/O statements) but those are very much a minority - and of course you can (and should!) encapsulate the low-level I/O in its own classes and/or modules, so the implementation is invisible to the rest of the program! Teaching people Fortran IV is about half a century out of date now.  

---

### Answer by username_24 on 2017-09-27. Score: 61

I am the author of the article. The point is to simplify the model of computation, not to match flow charts.

This is for mixed-ability 12 year olds, and when I say mixed, I mean some still add single digit numbers using their fingers.

Flow charts work because you can easily jump to another point in the program. This is not software engineering. I want them to create software where they understand how it works.

Goto also more closely mirrors the processor: it's easier to describe how programs are translated. After all, there is no such thing as structured programming at machine code level.

Dijkstra's article is a polemic from a purist. There were dissenting views at the time, which gave a more nuanced picture. The Wikipedia page on the article has good links on this.

Most new programmers shun goto because they have been warned it is evil, bad, and wrong rather than a more considered opinion.

My GCSE students learn structured C++. I myself am a CS grad and was a professional programmer a number of years ago.

> **Comments:**
> **username_2**: People should actually read Dijkstra's letter. He states the less gotos, the better. The context at the time was "goto's for everything", including decision and repetitions. Dijsktra advocated that programming languages should include constructs (like while/repeat until, if-then-else) helping to avoid the use of goto. Didn't say that loops/if-then-else were sufficient constructs to get clear code without gotos (talks about Jacopini's theoretical way to eliminate all gotos, where euphemistically "the resulting flow diagram cannot be expected to be more transparent than the original one").  
> **username_2**: Actually, D. Knuth _agreed_ with E. Dijsktra. He just provided a more detailed view, with good examples of "no-so-easy to remove gotos" (with arguments on clarity and optimization: error management, n+1/2 loops, etc.), and honestly explained he had lot of difficulties to change his programming  habits. Anyway, it doesnt hurt to explain that what happens in a program actually turns into ridiculously small things like moving data, comparing it, and jumping elsewhere.  
> **username_18**: Yes, Dijkstra was a _purist_. He was also extremely arrogant. But he wasn't wrong as I think you are trying to imply. Yes, there was controversy about his claims at the time, but the paper influenced the development of _every_ later language. It has taken a while to eliminate goto altogether, of course, but the trend is now nearly complete.  
> **username_25**: @username_18 Dijkstra's paper protects (in part) against [these practices](https://softwareengineering.stackexchange.com/a/118793/239446).The thing is, those practices aren't supported by higher level languages. It was absolutely correct when he wrote it, but technology has changed. It's like us sticking with QWERTY. Back when it was designed, it made sense. Now, it doesn't at all. Obviously, I'm not switching to DVORAK anytime soon, but can we at least agree that advice from 50 years ago using different technology might not be the gold standard for the technology we have today?  
> **username_24**: Dijkstra was right for most cases and purposes. Can I just ask if people criticising the approach have any experience of trying to teach low ability 12 year old children? When I trained to teach my biggest problem is I thought I could just explain things and children would understand. In reality I had been hanging out with the top 10% of the ability range (even in school I had no idea about the struggle of bottom sets.) I also teach year 11 maths and pupils struggle with place and value along with adding negative numbers. It is a different world.  
> **username_25**: @PaulPowell I have taught exactly one 12 year old to code (although to be fair, it was me). In support of what you're saying, I was learning TI-BASIC, so I learned what a goto was before a for-loop, and it made perfect sense. "Computers always read the next line of code unless you tell it to jump to a different line instead." Can't get much easier than that. When I got to loops and method calls which implicitly jump around, the first thing I'd do was mentally stick the `goto`s in and then they made sense too. I couldn't imagine learning loops first (or, god forbid, how a stack pointer works).  
> **username_26**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/66358/discussion-on-answer-by-paul-powell-is-there-any-value-in-teaching-goto-or-flowc).  
> **username_27**: I want to downvote this because I completely disagree with it, but you have direct experience with 12 year olds and I don't so I won't.  
> **username_0**: I still need to be convinced of the value of teaching `goto`, even to low ability kids (How low ability are they? Are they brain damaged, or just farther behind than others?) I can see that `goto 1` is an easy place to start, it is easier that using `for` or `while`, but what next. Can you show some evidence (anecdotal is ok) of how it helped you.  

---

### Answer by username_29 on 2017-09-27. Score: 17

Why do you learn about bits and bytes if modern languages, with good reason, abstract from it? Why do we learn to program in assembler if modern languages, for good reason, abstract from it? Why do we learn bare-metal imperative programming if object oriented languages, with good reason, encapsulate it? Why do we learn C even though C++ offers much better ways to express ourselves? Why do we learn naked pointer semantics if smart pointers are the way to go?

The reason is that the less abstract concepts are the building blocks for the more abstract ones. (And, I might add, there are times when it is appropriate to be less abstract. There are times to use assembler, and goto, and pointers.) It helps to know assembler when you try to understand C. It also helps *appreciating* what the language does for you. Knowing C, in turn, makes you understand C++ better (both its rationale and its limitations!).1

It helps to know goto when you learn about loops, and what they do for you.

The same way it helps to know molecules if you try to understand a cell.

---

1 It is also important to understand that machine independence and structured programming and object orientation are essentially *concepts* which are just more or less supported by the different languages. You certainly can write well-structured assembler. OO crept into my C after I grokked C++.

> **Comments:**
> **username_33**: I think one of the best reasons to teach `goto` is so that people understand why it's problematic.  Often old bad ideas are recycled in software and it's the people that don't know the old ways that get suckered.  While your at it build an app in VB where all the code is buried in button events.  Then change the requirements.  Same goes for [doodleware](http://www.enterpriseintegrationpatterns.com/ramblings/02_doodleware.html).  
> **username_34**: reminiscent of the Law of Leaky Abstractions https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/  

---

### Answer by username_25 on 2017-09-27. Score: 12

**Don't teach it if you want Programmers** (know what they're doing)**. Do teach it if you want Computer Scientists** (know why they're doing it)**.**

Obviously these two aren't mutually exclusive, but plenty of people learn how to code without understanding what they're doing at a lower level, and that's ok. If that's your goal, ignore `goto`; they'll never need to know it.

If you do want them to understand the why, then you have to teach it. If their code uses any sort of control flow, then at a lower level something somewhere is calling a `goto` (or something close), and CS students need to understand how that works.

**EDIT**: I just reread [GOTO Statement Considered Harmful](http://www.u.arizona.edu/%7Erubinson/copyright_violations/Go_To_Considered_Harmful.html) and it actually ends with:

> The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.

I know most of us have focused on the `goto` side of this question, hopefully this sheds some light on the flowchart side as well.

This line also reads to me as a confirmation that `goto` should be learned as a concept, since describing a control flow is nearly impossible without it, but Dijkstra still advocates avoiding it in code.

> **Comments:**
> **username_35**: Hey LordFarquaad! Welcome to [cseducators.se]!  
> **username_22**: Don't forget that COBOL is still the most prolific language out there, and all of the flow control in COBOL is through equivalents to GOTO  
> **username_36**: Although this makes sense as an answer, I'm not sure it will help the subset of teachers most at risk of incorrectly introducing GOTO to their cohort.  
> **username_2**: Well, @username_22, you really should update to COBOL 85 or more recent.   Cobol 74 really was a pain in the ***, but since 1985 it has all you need for structured programming : loops, if then else, and even a very interesting EVALUATE verb, much more powerful than the rudimentary switch of C/C++/Java etc :-)  
> **username_22**: I agree that Evaluate is much more powerful than "switch", but COBOL is crippled in other ways. Problems that take three lines of java code can take hundreds of lines of COBOL code - for example finding the intersection set of two sets.  Each language expresses different thoughts easily, so they are all valuable.  
> **username_3**: This is a very good point, and one that maybe I should have thought of (given the name of the forum!) before posting my comment!  
> **username_2**: @username_22 COBOL has never been intended as a general purpose language, it has some dark spots, but ir does rather well in its category for a 60y old language.  Remark that COBOLS's `add A to B C D` is much shorter than `B += A; C+= A; D += A;` :-).  Back to the point, it allows structured programming.  
> **username_22**: @MichelBillaud Structured programming is a way of thinking, as is object oriented programming. I have done both in BASIC (olde style, not what is called BASIC today). COBOL expresses some thoughts more elegantly than other languages, and it is still far from dead. Now that it runs on a JVM, it will live another 60 years.  
> **username_2**: and it officially has objects since 2002, if you're desperate enough to use it (a lot of my students earn their life in Cobol code maintenance for banks - where the money is- but AFAIK everybody sticks to Cobol 85, no objects).  
> **username_22**: @MichelBillaud it has objects, but they are skewed from what OO programemrs from other backgrounds think of as objects.  As one language junkie and COBOL guru friend of mine says, "Object Oriented COBOL is neither Object Oriented nor COBOL, but it makes a lot of sense for the right problems"  
> **username_37**: Except you'll never actually be good at it if you don't understand the why.  Thus everyone who is serious about it should learn the why.  

---

### Answer by username_26 on 2017-09-27. Score: 9

I teach them within assembly code. Otherwise, I mention them within my Java class when I teach their modern-day analogues, `break` and `continue`. This is late in my AP course, after the AP test is over. I present the two statements as restricted versions of `JMP` (that's the **6502 Assembly** syntax for `goto`), and I then follow up with two questions. They get to discuss it out in small groups before we rejoin as a class and go over it together. This gives them a chance to discover through peer discussion how language *restrictions* can really ultimately *help us*.

1. There are several more `JMP` statements that break program flow in Java. Can you find any? *(`return`, `throw`, `System.exit()`*)
2. Why, do they suppose, does Java restrict our `JMP` capabilities to very specific situations? What would be the problem with giving us an unhindered `jump` command in Java?

> **Comments:**
> **username_28**: There is a fourth one: `throw`.  
> **username_29**: @PaŭloEbermann And `System.exit()`.  
> **username_29**: Also note that the Java virtual machine bytecode has unconditional jumps (of course). It could be instructive to show the bytecode for loops and conditional expressions (instead of comparing unrelated 6502 assembler).  
> **username_26**: @PeterA.Schneider 6502 is useful for me because it is what they have studied, so it's a good point of reference. It's also a beautifully clean and simple assembly language  
> **username_30**: And a fifth one: `switch`  
> **username_26**: @username_30 `switch` would involve conditional jumps, not particularly unconditional ones (unless you are referring to the `default` at the end?) But in any case, there is a philosophical dissimilarity here. By that measure, so do `if` statements. The purpose isn't to find every jump that a compiler would generate, but rather, to find the ones that pull a program out of the narrative flow of the program (which is the use-case that so readily creates spaghetti code)  

---

### Answer by username_30 on 2017-09-28. Score: 9

I think the `goto` is sorely maligned. When Edsger Dijkstra wrote his famous letter in 1968, high level languages were not the same as they are today, and the `goto` could easily be abused.

In my early days learning FORTRAN IV, the `goto` was an important part of the language and many of the important modern structures were not yet universally mainstream. The resulting code could indeed lead to a degree of complexity which would be hard to analyse.

High level languages were meant to be more abstracted than machine languages, and you would have thought manually encoding the structure this way was a failure in this regard. If that sounds like a strong argument against `goto`, then, well, it is.

However, things have moved on since then, and the alternatives are not always better. In fact the `goto` is still there in spirit every time we use the `switch` statement in c-type languages, as it is all but a specialised `goto`. This explains why you then need to end each part with a `break` statement.

Modern languages tend to restrict the use of `goto` to minimise the damage it could do in the past. In particular, you can’t just arbitrarily `goto` anywhere, but it must be within the limits of the current block, and only to labelled, not numbered, locations.

If you add further self-imposed restrictions such as only going forward, or only using it in certain circumstances, it can certainly be used in an orderly manner.

For example:

* You can exit a function early with a `return` statement or a loop early with either `continue` or `break`. There is no standard early exit for an `if` block, but a `goto` to a label after the block will do nicely.
* For testing and trouble-shooting, it may be useful to skip earlier parts of the code and go straight to the section in question. Wrapping these earlier parts inside an `if` block simply to skip them is counter-intuitive and unnecessary.

The point is, every programming structure has its pitfalls and can be abused. `goto` has possibly been more abused than the others. However, there is still a case for using it in well-controlled circumstances, as it can help make the code *easier* to follow.

So yes, there is value in teaching `goto`.

As regards flow charts, I think that they remain the most obvious way of visualising a process. The fact that they are used so often in non-technical contexts attests to this. When teaching programming I often end up drawing arrows all over the structures.

I’m not sure that I would take flow charts too formally, though. They are useful in visualising, but I certainly don’t think they’re necessarily the best way to plan a program.

> **Comments:**
> **username_0**: I agree that flow charts in non-programming contexts is often good. For example, to describe a manual procedure. Flowcharts are an abstraction of unstructured code, such as assembler. If your machine is a human, then this is appropriate.  
> **username_31**: A former colleague of mine used GOTO as "elegant recovery from inelegant situations" --- dealing with catastrophic error conditions.  
> **username_32**: @PeterK.: A specific example: error handling in a C function that took a lock.  [`linux/mm/msync.c`](https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/mm/msync.c#L103) uses `goto out_unlock;` inside many error-check `if()` clauses.  It implements a system call, so all its args are untrusted, and there are many return-error cases that are only detected after taking a lock.  It's C, so RAII to release the lock isn't an option.  Obviously this applies to any other cleanup task that you don't / can't use RAII for in whatever language.  
> **username_32**: Can also be used for breaking out of a double-nested loop, although that's getting into spaghetti territory if done too much.  Some languages have a `break label` for this.  e.g. PERL has [`next LABEL`](https://perldoc.perl.org/functions/next.html) for outer loops.  Still possible to abuse, though.  
> **username_5**: @PeterCordes actually you can use deeply-nested `if`s to do the same thing. A real anti-goto purist would make you do that. It's not as much of a readibility problem on modern wide monitors...  
> **username_2**: @immibis it is a code maintainability problem in, say, business programming when you have a lot of things to check before doing something. And the list of tests has to change over time. In this case a flat list of tests + break if they fail is much easier to maintain over time.  

---

### Answer by username_21 on 2017-09-28. Score: 6

Flowcharts are a useful tool to understand programs that perform moderately complex sequences of interactions. They aren't always a good way to describe an algorithm, but they are a good way to describe the behavior of a system that reacts to external events in different ways depending on its state, with a non-linear control flow. Note that by flowchart, I'm not referring to a specific formalism — at this level of detail, I might as well call it a state diagram (although a proper state diagram requires a more precise understanding of what the different system states are before you can draw it). Flowcharts have their place in an imperative programming course, but only at a fairly advanced stage, after the students are familiar with basic control structures such as conditionals, loops and subroutines. They're a visual aid to understand complex control or data flow, in the same way that decision diagrams are a visual aid for complex series of conditionals.
The only good reason I can think of to introduce flowcharts early on is if the students started with a style of visual programming that resembles flowcharts. Otherwise, teach while loops first.
Goto is an instruction that's hard to really understand. (If you think it's just a jump, you don't understand goto.) It's perfectly fine to teach imperative programming without goto, if you're doing it at any level that's higher than assembly (in which case what you'd teach is jumps). Goto is very rarely useful in the real world and is rarely used. Its place in a basic or intermediate imperative programming course is as an incidental mention, as something that exists, that you mention for the students' interest but isn't part of the curriculum and won't be on the exam.
I work in industry. I write software for embedded systems in C. Think I should be insisting on the importance of goto? Wrong. In my world, goto is almost exclusively used for one thing: a forward-only goto, a generalization of break that allows breaking to the end of any block. The single common idiomatic use of goto is to jump to a common cleanup code before returning from a function in C:
int myfunction () {
    foo_t resource1;
    bar_t resource2;
    resource1 = allocate1();
    if (!resource1) goto cleanup;
    resource2 = allocate2();
    if (!resource2) goto cleanup;
    if (!do_stuff()) goto cleanup;
    …
    return 1;
  cleanup:
    free2(resource2);
    free1(resource1);
    return 0;
}

Many coding standards for embedded programming forbid using goto for anything else. In languages that have a better clean-up mechanism, such as try/finally or C++ destructors, goto is useless.
Understanding goto is a secondary skill for programmers, part of understanding how a program's code relates to the way the machine executes the program. A good programmer understands goto, but a decent programmer understands how to program without goto. The primary skill for a programmer is understanding how a program works, not understanding how a machine works. (There are exceptions, obviously — I write OS code, doing things like memory management and context switching and accessing peripherals, and that obviously requires a precise understanding of how the machine works. But that's a highly specialized field.)
The real difficulty with goto is, as I mentioned before, that it isn't just a jump. It's a jump to a different context. The invariants that hold at the location of the jump may not hold at the target location. A goto introduces a non-local connection between two points in a program that makes it hard to figure out how the program state evolves and what invariants hold. 
username_24's statement that “GOTO (…) is easy to understand” is just wrong. What's easy to understand is how a machine executes a goto statement. But the most important part, understanding how a program that uses goto works, is difficult. The statement that “it can be used to explain what loops and other items of structured programming actually are” also completely misses the point. Goto can explain how structured programming items are implemented on a processor. It explains an implementation, not the concept. Goto is an advanced step after structured imperative programming, not a step before.
Using goto to encode flowcharts is also very misguided. With goto, “we can code directly from a flow chart” — this is true: goto makes it easier to write a program from a flowchart without understanding how the program works, without figuring out the structure in the flow of events. But when you do that, you end up with a write-only program. Sure, you've been able to write it, but you won't be able to explain its behavior when a parameter that isn't reflected in the flowchart turns out to be important, or to modify it in a way that isn't easy to draw on the chart. Write-only programming is the mark of a mediocre programmer, capable only to fumble in the dark until they somehow manage to pass the tests.
Goto has its place when you teach how a machine executes code. It's what's happening under the hood. It has little to no place in teaching how to program, and Dijkstra would be quite right to complain about its use in this context.

> **Comments:**
> **username_24**: And your experience of delivering this knowledge to 28 mixed ability 11 year olds is?  
> **username_0**: @PaulPowell  Teaching goto is not the problem. It may even be easier that teaching structured programming. But then you have a class full of pupils that need to be un-taught. I have been in gilles position, and have had people on my team that have been taught these bad habits. It can take longer to un-teach them, than it took you to teach them. Use scratch as a basis (this is taught to 7 year olds), then have them translate scratch programs into python (see https://cseducators.stackexchange.com/a/178/204 ). Both languages do not have `goto`.  
> **username_24**: I am an experienced Head of Department with a degree in Computer Science and 12 years in industry. Do you really think I have not tried this or thought about it?  
> **username_32**: Real-world example of `goto` for cleanup: [`linux/mm/msync.c`](https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/mm/msync.c#L103) uses `goto out_unlock;` inside many error-check `if()` clauses.  It implements a system call, so all its args are untrusted, and there are many return-error cases that are only detected after taking a lock.  It's C, so RAII to release the lock isn't an option.  (There are 12,987 hits for `goto` in the Linux kernel tree; all like this or `asm goto` as a way of optimizing `if (asm_statement)` to avoid producing an actual boolean.)  
> **username_21**: @PaulPowell I don't have any experience teaching this to 11 year olds, but I have as much industry experience, and I'm telling you that your teaching will neither make them better programmers nor make it easier for them to learn. The example you cite from the Linux kernel is an example of the pattern I state as being the only common use case for goto in my world.  
> **username_24**: Firstly, the Linux comment wasn't made by me. Secondly, If you have no experience of KS3 education then what, apart from the height of arrogance, compels you to presume it works how you think it does?  
> **username_38**: "If you think it's just a jump, you don't understand goto"  Wow, well aren't you a gate keeper?  We don't need this kind of language on any Stack Exchange site, especially not a site for educators with the explicit purpose of making CS education better.    Always, *always* explain after statements "if you think X, your are wrong".  If you don't, all you've said is "I think I know something you don't, and I just wanted to let you know that", and I really hope I don't have to explain what is wrong with that statement.  
> **username_21**: @snb I recommend that you read my answer, not just one sentence. I *do* explain why goto isn't just a jump.  
> **username_21**: @PaulPowell By the way, your authority argument might conceivably carry some weight if you at any point explained why goto is better suited for 11 year olds than for adults (undergrads and up).  
> **username_38**: @Gilles No you don't explain why it isn't a jump, you state " It's a jump to a different context ", and no, underneath it would still be a jump regardless, with semantic rule control in the compiler if you're in a language like C++, goto is a jump.   You seemed to want to find a way to display arrogance when what you actually should have said is "Goto isn't dangerous because you jump to another point in a program, its dangerous because that jump to a completely different context in the program. The invariants that ...."  with out your gate keeping statement.  
> **username_24**: @Gilles, if you teach undergrads then you are looking, at worst, at the brightest 50% of the population. Imagine your brightest undergrad and your absolute dimmest. Now imagine someone who is that much less able again. Now imagine all of them have six or seven fewer years of being educated. To put you in the picture, I spent 5 minutes today with a Y11 student exploring different ways he could attempt the sum 21/3. He is at the bottom of the range and although he eventually could do it today, he will have the same problem tomorrow, the day after and probably for the rest of his life.  
> **username_24**: Difference enough for you?  
> **username_21**: @PaulPowell I'm well aware that teaching to Y11 is vastly different from teaching to undergrads. What I fail to see is why goto would be more appropriate to Y11. It's a very complicated concept. Why on earth would you teach the more complicated concept to middle schoolers?  
> **username_24**: First I said year KS3 is where I am doing this, not Y11. I gave a Y11 example it illustrate where the bottom of the ability range is, although if I were required to teach this child CS I may well use GOTO. You might be theretically aware, but try going to a local non-selective comprehensive and teaching a class (not a selected group) of year 7s. Then try the same thing in London.  
> **username_24**: The whole article and everything else says that this is an experiment, so I don't know if they will find it easier yet as we are just getting started.  
> **username_24**: You are asking me to say what is simple about goto (which is always harder than saying why it is complicated). Two things, first: one line one sttatement, one action for all statements. Secondly, context is pretty much irrelevant at this stage - about the worst you could do is reference a variable before it has been defined. Thirdly, they don't have to think about what is in and outside the loop - just what happens next. We are using BASIC 256 as our language. Now you tell me what is so complicated about this.  
> **username_39**: I upvoted. I am a retired software engineer who learned programming using BASIC in 1981. Basic's `GOTO` was the *most confusing* part of trying to learn how to program, and I had real trouble with control flow in more complex programs until I encountered structured control flow in Pascal, ca. 1985. I later programmed quite a bit in assembly language, even microcode, where understanding the concept of GOTO is useful. My programming teaching experience is limited to being a TA at university. Based on that: GOTO is an *advanced* concept that should be kept away from beginners learning a HLL  

---

### Answer by username_36 on 2017-09-28. Score: 4

The real question here seems more like when should you teach goto rather than if you should teach it.
The first example programs should certainly not be looking like those we wrote on the machines in WH Smith on the way home from school:
10 PRINT "HELLO WORLD!"  
20 GOTO 10

A while true construct is more sensible here. However, if you introduce your students to programming by demonstrating the low-level operation of the CPU (fetch/decode/execute) then it's more likely that you'll need a force-pc (although typically it also needs to be conditional).
The assembly language constructs typically don't quite match high-level languages exactly (e.g. count down rather than up, in a loop to allow compare-and-branch-if-zero), but at some point your course will probably link high level languages to machine operations.
To clarify, I'm not suggesting that it is sensible to start by introducing the full scope of:  
 while (expression == TRUE) {stuff, including maybe break};

rather keep the templates simple and expand the linguistic elements progressively. while (TRUE) is just a compound keyword when it's first needed, just like GOTO .
It should be easy to explain that modern high level languages are designed so that humans can understand the code. That is why there are usually several different ways of expressing control flow even though to a beginner they all look interchangeable. In the absence of any more specific reason, goto is likely to come at the end of your list of 'possible control flow changes' and probably needs to be introduced as an instruction which has been mostly replaced in modern programming, because other constructs are better, not simply because goto is bad.
The best reason I can think of for introducing goto is that the concept might help when it comes to explaining hardware interrupts (being the most important part of CPU architecture which isn't even mentioned in far too many courses).

> **Comments:**
> **username_0**: I agree, except the last paragraph, interrupts cause subroutine calls, not `goto`.  
> **username_36**: @username_0 That's just a force-pc with some side effects. Where goto fits as a better analogy is that exceptions are less structured. SVC can be considered a subroutine because it is planned, IRQ less so (although it uses an identical mechanism).  
> **username_24**: Why is while(true): in any way more sensible? Write down a full explanation of how the two bits of code work. Which is simpler to understand?  
> **username_36**: @PaulPowell `While (true)` captures the intent, not the mechanics of how the code operates. If you look at [tag:coding-style] there are several questions about readability and intent. Professionally, readability is the critical thing students need, so I think this has to come first. Generally, when you start to teach coding, the 'how it works' involves a lot of abstraction, so using 1980's style doesn't make sense. This question has slightly missed the point in your article that the 'how it works' really is important. To explain how it works, `BEQ`, `CBZ` are preferable to `GOTO` IMO.  
> **username_36**: @PaulPowell It might be interesting if you ask your question about how control flow teaching is leaving gaps - particularly if you have specific student groups in mind.  
> **username_24**: @sean I think it is simpler than leaving gaps. It is about a student being able to express themselves in code. Did you try writing down a full explanation of while true?  
> **username_24**: Really awkward leaving comments here as I can only access it on mobile at the moment.  
> **username_40**: I'd take a guess and say that it might be easier for some coders to grasp programming when there is one action per line (where each line has text), maybe it's easier for them to understand `JMP wherever` instead of `while(condition) {}` (where the brace at the end means "go back up to the beginning". When I first started I remember a C `for` loop seemed very daunting and I had a hard time remembering it (e.g.: "When do each of these things in the parentheses even run? Once? After the loop? Before it? Both?").  
> **username_36**: @username_40 - See edit.  

---

### Answer by username_42 on 2017-09-27. Score: 4

I teach a college level introductory computer science course, where the primary goal is to learn programming in Java with no assumed prior programming experience.

I do teach flow charting when I cover decision making & looping. Flowcharts aren't a great tool for an entire non-trivial program. They are a reasonable tool for high level algorithm design and for code level representation of methods. Furthermore, most students have seen a flowchart of some type before & I find that any degree of familiarity is helpful to those who find programming to be an otherwise foreign concept. I need to reach as many of my students as possible & find flowcharts to be worth leveraging in that regard.

I do not cover use of `goto` beyond stating that it exists, it's easy to misuse and typically by the time they might encounter it in a production environment, they should have accumulated enough programming acumen to deal with it as needed. It's not a core piece of the language & there's plenty of other material that sees more routine usage that could use its time.


---

### Answer by username_41 on 2017-09-28. Score: 3

Binary digital computers (and the execution of most programming languages) are just big state machines at their very heart. State machines usually require non-sequential state changes. e.g. `goto`s

A flow chart is a form of state machine. (superset or subset?)

You need goto's to learn jump statements in assembly language, asm to learn machine code, and machine code to understand CPU architecture and design. Understanding computer hardware logic and state machines seems important to any CS degree. As for difficulty of learning machine code, many thousands of student-aged kids learned to poke 6502 and Z80 op codes back in the day...


---

### Answer by username_0 on 2017-10-01. Score: 2

I will concern myself mostly with goto, but first a little on flow charts.
On Flow charts
I see flow charts as just a ways to visually represent goto-ful low-level algorithms/code.
What flow charts are not
Some other answers have mixed up their use with state-machines, or decision trees. Doing this could result in coding each code path separately, this would result in an undesirable increased program-size. For example for a sorting algorithm, of we could get a code size complexity of $O(n!)$. This does not scale, much beyond sorting 3 items, and you will use all of you computers memory (just for the program to sort 16 items). 
Good uses of flow charts
The low-level nature of flowcharts can be of great value, when creating a procedure to be carried out by humans. I.e. A first aid flowchart.
On goto statement and goto
In the paper “Go To Statement Considered Harmful”, Dijkstra is concerned with the goto statement, not with goto. He points out that all higher order structures will use goto in their implementation. According to Dijkstra, this implementation is not the problem, only the direct use of goto. 
In the time since his paper the structure he mentions, if, else, while, for, until, repeat, and sub-routines have been part of our high-level languages. For his call was not for us to stop using it in programs, but to create languages that did not require it, and then to stop using it. And in the meantime to use it only in a structured way, to simulate the structures. Therefore only use it if your language does not provide the high-level structure that you need, and know which structure you are simulating (don't ad-hok it).

For a number of years I have been familiar with the observation that the quality of programmers is a
  decreasing function of the density of go to statements in the programs they produce. More recently I
  discovered why the use of the go to statement has such disastrous effects, and I became convinced that
  the go to statement should be abolished from all "higher level" programming languages (i.e. everything
  except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I
  now submit my considerations for publication because in very recent discussions in which the subject
  turned up, I have been urged to do so. (Edsger Dijkstra)

Good uses of goto statement

Programming in assembler, though you should not have much assembler language in your project.
Compilers/generators: These will use goto to create higher-level structures.
To over come limitations of the language, but consider changing language: In C you may use goto to implement exception handling. However ensure that you have a clear idea of the structures that you are implementing. Do not use goto in an ad-hoc way.

When goto can seem like a good idea.
goto is easy to understand, how it does it. However the code that you create (beyond the most trivial) is not easy to understand what it does.

My second remark is that our intellectual powers are rather geared to master static relations and that our
  powers to visualize processes evolving in time are relatively poorly developed. For that reason we should
  do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the
  static program and the dynamic process, to make the correspondence between the program (spread out in
  text space) and the process (spread out in time) as trivial as possible.

That is our attempts to understand a large system, in terms of how it works in a dynamic way, are going to be very limited. However it is possible to view the system in a static way, and thus make it easier for our brains to comprehend. To do this we must let go of a little of the how. We do not seem to have a problem with this in most cases: we care not how print is implemented.  
On assembler code and machines
So our CPUs use goto (jmp instructions). So what, unless you are teaching assembler language and CPUs.
But do all CPUs use goto? Possibly not, I am not an expert on this. However here is a discussion on what modern CPUs think of goto/jmp.
That happens when a modern (instruction pipelined cpu), fetches a conditional jump instruction?
All is not well, first it tries to guess which way the branch will go, then it goes that way. If it get it wrong it hits the brakes, backs up and tries again. The circuitry in the x86 for making this guess, is huge. The x86 does not like goto. What about the ARM, its branch prediction circuit is tiny (if it is a branch back, then assume that the branch will be taken, else assume that it will not), The ARM is better at predicting branches than the x86, but how? The arm has more conditional instructions, that is, it has selection built in. This allows it to avoid goto a lot of the time. Its simplistic algorithm then assumes that a jump backward is a loop, and a jump forward is a selection. So though iteration is not explicitly encoded, and selection is only sometimes explicitly encoded. This shows that knowledge of the programs structure is not just a high level thing, it can help the CPU's performance.
The paper cited by @Miles on CAS
As Miles says it showed no benefit of flowcharts. But also not it was year 1977, and they were fortran programmers (goto users). It may be that if the experiment was repeated with the control group using structured programming, that the effect may be negative.
Conclusion
While it will be quicker to teach
10 print "Hello, World"
20 goto 10

than
forever:
    print "Hello, World"

However making the first step easier will make all subsequent steps harder.
Someone once said, “Never hire any one that knows basic. They will have been so irreparably damaged by the experience of gotos, that no amount of re-rehabilitation can save them.”, while I do not agree with this statement, there is some truth in it.
Could it be used when teaching for, while, if, etc. As opposed to as a way to program.
Therefore,
only teach goto, when teaching assembler language, or at a late stage in high-level programming. However first teach the higher level structures, and make it clear that goto is only a work around for lack of higher-level structures in the language. And consider its use in teaching structured programming.
HOWEVER the article opened a very important question. We need to keep exploring ideas for teaching. Well done @PaulPowell


---

### Answer by username_15 on 2017-09-29. Score: 1

goto is not bad per se, it depends the way you use it, that's the way Dijkstra and other papers should be read. It can be very useful to simply get out from inner loops without creating weird boolean conditions. Of course if you use it to produce spaghetti code, that is bad.
For example, Java banned goto but gives a break to label statement which is exactly a kind of good goto. On the converse, C lacks of this useful extend break so you need to write thing like:
for (...) {
  for (...) {
      for (...) {
          ....deep inside...
          if (...) goto end;
  }
}
end:

which is much much better than using boolean condition to exit from the loops one-by-one. I doubt anyone would consider such usage as bad, in really helps reading the code which would be much more difficult with a mess of strange combinations of conditions.
Naturally flowcharts illustrate the jumps in between portions of code and this can be simply implemented with jumps. After all an if necessitate a unconditional jump. Beginners have sometimes difficulties to understand what exactly happens in construct like if, while, etc and ask "what code is executed after that", saying that a jump exists from the end of a block to the beginning of another one is a good way to explain, much more than a purely syntactic explanation.

> **Comments:**
> **username_16**: Every control structure in any language can be described as "a kind of goto".  
> **username_0**: @username_16 Every high-level program is compiled to machine code. The only flow control instructions in machine code, are `jump` (goto), and `jump_to_subroutine` (gosub / call, this one is almost structured). The point is not that it gets converted to a goto, the point is that all gotos should be used to implement control structures, and preferably these structures should be baked into the language, and add-hock goto removed from the language. `break` in a `for` look is a control structure, but break in a `case` may not be. You have to make your own structure with `case` in the `C` languages.  

---

### Answer by username_17 on 2017-09-28. Score: 0

Here is a generic flowchart of a specific type of control flow:

![](https://i.sstatic.net/4mcK1.png)

This control flow cannot be implemented with only control flow structures (`if`, `switch`, `while`, `for`, `do while`). You *have* to either use a `goto` after one of the conditions, or bend up another structure to simulate it. The latter naturally results in code ranging from slightly weird to awful (loops that don't actually loop, infinite loops with `if+break` conditions in the middle, artificial flag variables which form some kind of state machine, one-off functions that don't actually represent a stand-alone operation...).

The truth is that control flow structures do *not* cover all possible cases. `goto` should always be the last ever tool you try to solve a problem, but you shouldn't throw it away from your toolbox lest you want to end up driving a screw in with a hammer.

> **Comments:**
> **username_18**: Good to know your history, of course: https://en.wikipedia.org/wiki/Structured_program_theorem. You have something nice and tricky, but not essential.  
> **username_17**: @username_18 I guess nothing is "essential" if you give up on readability. I really like the "Single-while-loop, folk version of the theorem" section from the page you linked, even if it addresses an extreme form of what you have to do with control flags (`p` is completely artificial, and is only needed because of the shortcomings of the structured flow). I especially like the last quote before the block of code, which neatly sums up my PoV.  
> **username_18**: I worry about "readability". Suppose that your "simple" flowchart results in code that is spread over about 5 pages. Is it still "readable". The history of computing languages seems to imply that go-to should just go. Python, Scala, etc, don't include it and there are other ways to think than with low level structures. These result in cleaner and more maintainable code. One problem with go-to is that it often results in "write-once" or even "write-only" software that is impossible to maintain in the face of changing requirements.  
> **username_18**: For Ruby's support of goto see: http://patshaughnessy.net/2012/2/29/the-joke-is-on-us-how-ruby-1-9-supports-the-goto-statement  
> **username_17**: A five-page nested loop won't do you any good either, so that's a job for another structuring tool (namely, functions). Anyway, there's no doubt that structured control flow is a benefit in the overwhelming majority of cases. But wanting, in the tiny number of cases when it isn't enough, to simulate a goto by misusing a control structure is just a bad idea. The tell-tale symptom is the apparition of infinite or do-once loops with `breaks`, or the proliferation of control flags. That's not "more maintainable" code in the slightest compared to a simple labeled `goto`.  
> **username_18**: Hmmm. No one is suggesting misusing other control structures. And yes, functions are one of the classic ways to solve many such control issues. Could you imagine suggesting such a control structure to a Scheme programmer? You seem to be insisting that such things are _needed_. They are not. Finding out why and how will expand your horizons, I think.  
> **username_18**: For a little more perspective. For "replacements" of some of these poor control structures a small local change may not do the job, resulting in even poorer code and misuse of structures. Sometimes you want to step back and re-think the algorithm. There is likely a clearer, simpler, more readable, more maintainable way to do it. I'd suggest the Gries book mentioned elsewhere here (The Science of Programming) as a good place to learn such things. https://www.amazon.com/Science-Programming-Monographs-Computer/dp/038790641X  
> **username_17**: @username_18 you can implement it in a functional language by wrapping it in a function, and tail-recursing from the first condition. That's not ideal in imperative languages though. As for misusing control structures, ending up with loops that don't actually loop, or depend on some phantom flag unrelated to the data you're processing, or have their condition in a weird place (granted, that one is pretty tame) seems definitely off.  
> **username_0**: Procedural languages can do tail recursion as well: The C and C++ specifications allow it, but do not mandate it. `gcc` implements it. But tail recursion is no more `goto` than `if` is. It is a `while` with out mutation.  
> **username_17**: @username_0 it still isn't that idiomatic, and might not fit the meaning of the algorithm. Not sure about your comparison with `goto`: tail recursion is equivalent to just jumping back to the beginning of the function, while wiping the stackframe.  
> **username_17**: @username_18 I do make this answer on the premise that this flow *is* the best you can do to model your requirements. I also didn't design it, but actually stumbled upon it while writing actual C++ code. I've also been bitten by another case in Java, which doesn't have `goto` and left me needing to write a degenerate `do`-loop with `break`s so I could skip to the end.  
> **username_0**: @I can accept that tail recursion is goto, when I accept that while and if are goto. Depends how you look at them. I prefer mainly to look at there structure not their implementation. I too have sometimes had to do weird things with goto and flags. I have come to realise that it because the languages we use don't have the higher order structures. Same as in the 1960s we used goto because we did not have the basic structures (while,for,if). There are still other higher order structures. If our languages did them, then we would not need to do weird stuff.  
> **username_17**: @username_0 yes, maybe some new structures would be the solution, so we can avoid falling back to `goto` and its caveats. I'm purposefully avoiding the "but a `while` is just a `if+goto` in disguise" argument because it's moot, for the reason you stated. I do invite you, though, to try implementing that flowchart, and then verify that each abstraction and structure you used is actually meaningful -- loops actually loop, conditions are about the (imaginary) data you're processing, and there's no weird flags floating around. Maybe you'll get a great idea for the missing structure :)  
> **username_0**: @username_17 I took up this challenge once before, when it was a concrete problem. So I could re-write it. But I agree that this abstract problem is not elegantly solved.  
> **username_2**: Use the Jacopini method:  1. Give different a block-number to each block. 2. Define a `next_block` variable with initial value 1.  3. replace first action by `if (next_block == 1) { instructions for action 1; next_block = 2 }`. 3. Replace first test (block 3) by `if (next_block == 3) { if (condition1) next_block = 1; else next_block = 4;`. Do the same for all, use number 0 for exit. 5. Put it all in a `while(next_block != 0)` loop. 6. Done: structured flowchart where all the logic disapeared and nobody can understand anymore.  That what Dijkstra was referring to.  
> **username_2**: Seems your flowchart can be written as `action1; aux; action3; while(condition2) { aux; action3;}, action4`, where `aux` is `action2; while(condition1) { action1; action2} ;`.    (obtained by loop unfolding)  
> **username_17**: @MichelBillaud but then you have duplicated code.  
> **username_2**: @username_17 If it is a problem to have the same code, change the names. Well, no, better idea, put the repeated code in a function, and call it where it is needed.  Joke aside, It is probably a theorem "given a finite set of 'flowchart schemes' there are flow charts where gotos cannot be be removed without code duplication or use of extra variable." Should check. So the the point would be : what are the schemes needed for most practical use ?  
> **username_17**: @MichelBillaud as an anecdote, this very scheme popped up while I was implementing a turn scheduler similar to that of HoMM5, which handled a list of actors and had to work with turn skipping, reordering, etc.  
> **username_2**: @username_17 It means that a specific structure is needed to express clearly what you need to do, which seems to be retrying previous steps.  `#define retry(label) goto label`  

---

### Answer by username_19 on 2017-09-28. Score: 0

Three quick answers:

* flowcharts are useful to *communicate and document the logic of a process*. Not knowing how they work may well be a problem in some kinds of work.
* `goto` has value in many situations where some programmers (not all) will work. Not everything is done in high level or modern languages. At a low level on most processors there are no loops, only conditional and unconditional `goto`s (branches). Older non structured languages also remain in use.
* `goto` also has considerable importance in security/vulnerability. That's because hacking and vulnerability work (and therefore security) can involve understanding stack manipulation techniques and disassembly (machine code to assembler) which are completely based on jumps not loops. If you look at an infosec analysis of malware you'll see the need to comprehend code that doesn't have high level classes and objects.

> **Comments:**
> **username_20**: I can't tell what "[hacking... is] completely based on jumps not loops" is trying to get at.  I would suggest removing your third bullet point, or trying to provide evidence for it.  That doesn't match my experience of security.  Are you perhaps trying to hint at ROP attacks?  But that's something entirely different; ROP has to do with CALL/RET instructions, and I don't see what the difference between jumps vs loops has to do with it.  
> **username_19**: Anyone analysing malware, or looking at vulnerability testing that requires analysis of compiles software, will need to dip into assembler. Which means understanding assembler, CPU address (+other) stacks (and perhaps interrupts) and so on. Which means understanding code that exclusively uses jumps and branches, such as JMP/JEQ/JL/JNE (or whatever the equivalent is on your CPU/SCAD). AKA understanding goto. Crucial for infosec work.  
> **username_20**: That's an argument for eventually teaching students assembly language, at least if they want to do infosec reverse engeering.  That's not the same as an argument for teaching goto.  And it has nothing to do with "jumps vs loops".  
> **username_21**: @username_20 I think that by “goto also has considerable importance in security/vulnerability”, username_19 means “goto is important to write native exploits”. Which is true, as part of the more general fact that writing native exploits requires a very good understanding of how a machine executes a program. But teaching how to write exploits is not relevant to  the context of the question, which is teaching to fairly novice students (the author of the article seems to insist that it's especially relevant for middle school students).  
> **username_21**: By the way, the statement “at a low level there are no loops, only conditional and unconditional gotos” is partly wrong (some processors do more than that for you, e.g. they manipulate the stack, and conversely a jump can actually be *more* than a goto if it involves changing processor modes). It's also misleading, because even in microcontroller programming, very little code is written in assembly and goto is rarely used in C, let alone higher-level languages.  
> **username_19**: This isn't hard to understand. C wont help you, nor is it about writing exploits. Example paper: malware analysis of stuxnet: https://www.codeproject.com/KB/web-security/StuxnetMalware/Stuxnet_Malware_Analysis_Paper.pdf . Among the earliest pages (bottom of p.6) is _" at the place of the entrypoint of the unloaded module, stuxnet writes a "jmp" instruction"_. `jmp`. That's effectively `goto`. Is there any value in "teaching goto"? Evidently yes, if analysing malware, or you won't be able to do so.  

---

### Answer by username_2 on 2017-09-28. Score: 0

Flowchart like drawings are a great help when trying to solve problems with multiple cases. A simple example

> Exercise: given three numbers a, b and c, print them in ascending
> order.

The student is expected to articulate a lot of comparisons, and quickly gets lost because his/her brain can't handle 6 cases and the necessary tests at the same time.

So some intermediary representation is needed to work on it. Say, I obviously have to compare things. Let's start with a comparison of a and b. On one side, I know a is bigger. On the other side b is bigger. What else ?

A graphical representation helps to work on the decision tree, much more than a textual representation if embedded if-then-else.

Image of work in progress. 1 of 6 cases solved. Extending the diagram can be done on any order.

[![enter image description here](https://i.sstatic.net/xW3Oj.png)](https://i.sstatic.net/xW3Oj.png)

Yellow boxes show what I know about the order in some case. `c?` means : "`c` could be there".

> Question : What is obviously wrong? :-)

> **Comments:**
> **username_0**: You have used a flowchart to model a program flow tree, to model a decision tree. Just use a decision tree. This is basically the same as what you have draws, but minor notation change. And more importantly, no suggestion that this is what the program looks like. Imagine writing a program from this flowchart, that can sort 100 items.  
> **username_2**: @username_0 sometimes the decision tree grows "indefinitely", and when you remark two situations are similar, comes the idea of jumping back to a previous point. Then you recognize a loop. Or a regular infinite tree, if you are more mathematically inclined. PS: I dont teach a notation for finished programs, but an approach. When you recognize a loop, you know what is the condition, and what you want to repeat.  

---

### Answer by username_16 on 2017-09-29. Score: 0

There are a lot of answers here about flowcharts, and the author's answer seems centered around grade-school students (as that is what his article was about).
However, there are in fact some instances where we professionals do use gotos. We don't like to talk about it, because they have such a bad rep. However, if you crack open the code for most of the world's lexical analyzers you will find gotos. Lex itself generates gotos (admittedly, as do many other automated source code generators).
Gotos are in fact the natural expression of a state machine. It is meet and right to try to train students to put more structure into their programs than a simple state machine. However, there are a few tasks that in fact do not have more structure to them than a state machine. A lexical analyzer is one of these tasks.
The typical goto-less method to work around this is to create a variable to hold the state, and write a big honking switch statement embedded in a loop with little or no code between them. That works, and avoids using the g-word, but it doesn't really gain anything. Rather it just hides the unstructured control flow under an artificial layer of structure.
(Note: gotos are also commonly used in languages that don't have exception handling, but that's arguably a separate issue).
The only tweak I'd make to traditional anti-goto training would be to say that if I ever see something like this in your code:
for (;;) {
    switch (state) {
       // multiple screens of code here
    }
}

Then one of two things are going to happen: Either there was a properly structured way to write the same code, and I'm going to grade you just like you wrote "goto" there, or there isn't, and I might dock you a point or two for the extra obfuscating of not using goto.
Also, courses like Compiler Construction that naturally entail gotos should mention this issue, and not hide from it.

> **Comments:**
> **username_21**: Generated programs are a radically different beast from code that humans maintain. Most (I hesitate to say all, but I can't think of a counterexample) state machines I've written in the real world are better written out with an explicit state; conflating program state with program counter location, the way you have to do it if you rely on goto for state change, would have made them very hard to maintain, because the states are not clearly disjoint. Admittedly, goto might be the easiest way to express a state machine which is a toy exercise, designed to keep the states simple.  
> **username_16**: @Gilles - There are of course good ways and bad ways to organize state-machine goto code (believe it or not), just like any other kind of code. But you aren't "fixing" that by artificially imposing an unnecessary loop-switch structure on top of it.  
> **username_21**: My point is that the state machines I usually see are a loop around *something that contains a switch, or at least a bunch of conditionals*. The loop body is hardly ever *just* a switch. It tends to be something like: read and parse a message, run consistency checks, analyze the state, update some data structures, emit a log message, make a state transition, loop. That's hard to express with goto statements, even in the best of cases where “analyze the system state” only comes up once.  
> **username_16**: @Gilles -  If there's really a significant amount of "always run" code, yes that's a good reason for a loop. However, I tried that for a while with my first serious manual lexer, and gave it up. The problem is that stuff outside the switch tends to end up only running at the end or beginning of *most* loops, not all of them (practical example: don't bother updating the lexeme in comment state.) After about the 3rd interlocking exception, you end up just making that stuff subroutines and calling them at the end of the states that need it. That's much easier to follow code.  
> **username_0**: @username_16 Create/Use a meta compiler (a compiler compiler). Compilers are allowed to output `goto`s. Any domain specific language should be well structured, but may output code that is not intended to be maintained my humans. Every other compiler outputs `JMP` instructions.  
> **username_22**: The body of my favorite language parser's main() function was "while ((f=*f()) != null);"  All structured, no gotos, but most people couldn't understand it. Gotos or switch (which is just a hidden goto) would have made it more clear to most people.  
> **username_16**: @username_0 - I designed and built one as part of my Master's thesis.  
> **username_0**: @username_16 I have no idea on what you disagree on. I have just re-read the answer and comments. I see nothing to disagree on. You are correct that you can not turn gotos-full code to structured-code in any reliably way. However it is better to write structured code in the first place, though this could involve `goto` statements, if the language does not support the control structures. Then if you know the full list of control-structures this code could be translated to have no `goto`s.  

---

