In this chapter from my recent book we learn about the strange case of the goto instruction and why it caused such a storm - and perhaps still does.

The Trick Of The Mind - Programming & ComputationalThought

Buy Now From Amazon

Chapter List

1. The Trick Of The Mind

2. Little Languages
      Extract: Little Languages Arithmetic

3. Big Languages Are Turing Complete

4. The Strange Incident of The Goto Considered Harmful
      Extract: The Goto Considered Harmful

5. On Being Variable  

6. Representation

7. The Loop Zoo
      Extract The Loop Zoo
      Extract Advanced Loops
   

8. Modules, Subroutines, Procedures and Functions
      Extract Modular Programming

9. Top-Down Programming 

10. Algorithms
       Extract: Binary Search 
       Extract: Recursion ***NEW!!

11. The Scientific Method As Debugging 

12. The Object Of It All
       Extract Why Objects 

 <ASIN:1871962722>

<ASIN:B09MDL5J1S>

In the previous chapter we stated that all you need for a completely general programming language is the ability to make decisions and to repeat things. This might seem obvious now, but it was far from obvious to the early programmers and in fact they just didn’t think in this way at all.

Early programs were written in a chaotic style that was partly due to the need to make maximum use of the low-powered computers of the time and partly due to an ignorance that there was a better way. The basic elements of programs and general algorithmic thought are made up of just three atoms, but the road to find and to make this common knowledge was a surprisingly difficult struggle. Now things seem so much simpler that it is difficult to comprehend that there was ever any doubt about how things should be done.

The Flow of Control

Once you realize that programming is about compiling lists of instructions, you can see that there are various ways of creating such lists. As we discovered in the previous chapter, the simplest possible list is just one that you start reading at the top and carry on down one instruction at a time. This is usually referred to as the default flow of control. Only the simplest forms of instructions have just a default flow of control. There is usually a need to execute some other part of the instructions depending on what you want to achieve or on some condition. Sometimes parts of the instructions have to be repeated, perhaps with simple variations. When you try to analyze it you start to see that the possibilities are seemingly endless.

One way that makes it easier to think about it is to imagine a line drawn through the program that represents a possible order that the instructions are obeyed in. If you collect together all of the possible paths through a program then what you have is its flow of control graph or chart. This is a very important idea and it is something that beginners have a great deal of trouble with. Abstracting from the list of instructions to a theoretical flow of control graph is a big step and many early programmers had little deep understanding of what they were doing, even when what they did was done effectively.

The Goto

The natural way to read and obey a list of instructions is just one after another, i.e. the default flow of control. How do we change this to something different? The answer is to make the reader obey an instruction that is somewhere else in the list. As it isn’t the next instruction, you need to use an instruction that refers to the list.

This is another one of those “big ideas” that is so obvious when you encounter it that it hardly seems to need consideration. Lists of instructions naturally refer to things other than the list itself and these are the instructions that get the work done. Instructions that refer to other instructions in the list are often called control instructions because they control what will happen next.

I suppose you could say that the security-oriented instruction of “eat this message once you have read it” qualifies as the first control instruction, but not one that generally turns up in programs – that would be the Goto.

If you are writing a list of instructions and suddenly notice that you are about to write some instructions that you have already written earlier in the list then the temptation is to simply write something like “Go to instruction 4” where 4 specifies the instruction precisely. This is the Goto control instruction and it is all you really need to create any flow of control graph. In this sense Goto is the universal control instruction – you don’t need anything else. Well, you do need a conditional that you can combine with the Goto, for example:

If the game is over Then Goto 10

but notice that the actual transfer of control to another instruction is still via the Goto.

Of Numbers and Labels

The Goto is a wonderful and magical instruction that conveys so much power to the programmer. You can literally Goto anywhere! But where is anywhere? How can you identify the instruction you want to Goto?

The simplest way is to use a line number. If every instruction is numbered from 1 to the last instruction you can simply Goto any line number.

1 instruction 
2 instruction
3 Goto 1
4 instruction

This is simple, but it has a huge flaw.

If you need add an instruction in the middle of your list then all of the numbers change! Now all of your Gotos go to the wrong places! The only option is to edit the entire program changing every Goto to the new correct line number. This is tedious and, more importantly, error-prone – miss just one Goto and your program no longer works.

It was realized that the solution was to just number the lines you wanted to Goto and not make the numbers anything to do with the position in the list. Once an instruction was given a number it kept it no matter how much you added to the program. For example:

5 instruction 
  instruction
  Goto 5
  instruction

You can see that the 5 isn’t a line number, it doesn’t relate to the position in the program, it is a line label.

This is fine and it works, but why label an instruction as 5, or any other number for that matter? A slightly better idea was to allow any word or text to act as a label and this allowed programmers to give “meaningful” labels to instructions:

start instruction 
      instruction
      Goto start
      instruction

This is the scheme, with slight variations, that most computer languages adopted, and still do even to this day. The only problem it poses is what to use to label an instruction in a meaningful way. This is more difficult than you might imagine and many programmers just gave up and went back to meaningless arbitrary labels. This is the first example of a general problem in programming – naming things.