Return to Answer

##On Flow charts I see flow charts as just a ways to visually represent goto-ful low-level algorithms/code. Some other answers have mixed up their use with state-machines, or decision trees. Doing this could result in program-size complexity, for a sorting algorithm, of $O(n!)$ where the execution complexity could be only $O(n\log{n})$.

##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).

#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).

#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).

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.

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

##Conclusion While it will be quicker to teach

##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