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.
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
In the time since his paper the structure he mentions,
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
- 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.
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.
While it will be quicker to teach
10 print "Hello, World"
20 goto 10
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.
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