What is it about the Goto that attracts velociraptors? Once you know, dino attack is the least thing on your mind!

More cartoon fun at xkcd a webcomic of romance,sarcasm, math, and language.

This article was prompted by an xkcd cartoon. It raised the question:

    "What is so bad about the Goto - apart from being
     attacked by a velociraptor?"

So here is the standard and undisputed story of the Goto, Spaghetti and the quest for clean, pure, code.

The flow of control graph

When you first learn to program the big breakthrough is when you realise that there is such a thing as "the flow of control" and you begin to master it.

Well perhaps master is too strong a word but you do get comfortable with the idea and eventually it seems natural.

Acquiring the concept of "flow of control" is what makes the difference between a programmer and a non-programmer and if you think it's trivial and obvious then this is simply because you made the transition some time ago.

If you want a demonstration that it is far from obvious just try to teach programming to someone who hasn't encountered the idea before in any other shape or form.

You can't help but pity their undeveloped sense of what follows what and how they ever manage to follow or give any coherent instructions is a mystery. But they do, nearly always, make the transition and acquire the core concept of programming.

The flow of control is simply the order that instructions can be executed in.

It normally follows a simple top to bottom and occasionally left to right flow in a simple list of instructions but it also splits into two or more paths in the case of conditionals and it goes round in small circles for loops of all kinds. However even this description presupposes a lot of knowledge and it took time to work out.

If you think all of the paths through a program then you have in your mind the "flow of control graph". Think of it as a set of connected lines showing the possible routes through a program.

Spaghetti

In the early days of computing we wrote in machine code or assembler and you can't have complex instructions in machine code. Machines run programs using the default one-after another flow of control until they hit a branch or jump instruction when they are directed to start the default flow of control at some other instruction somewhere else in the program.

In machine code this is all there is. You use the jump instruction to create conditional and iterated code.

The conditional either takes the jump or doesn't depending on the value in some register and iteration builds a loop by jumping back to an earlier point in the program's flow of control.

Notice that we already have a sort of rule - jump "backs" make loops, jump "forwards" make conditionals.

Now we come to the problem.

Early programmers didn't have a clue what they were doing. It was hard enough to get your program and data to fit into the tiny amounts of memory - they simply didn't have the luxury to step back and philosophise about how best to program. In other words methodology came low on the list. The early programmers were clever, very clever but they struggled with just getting things to work and making use of the very limited resources they had. 

What the environment encouraged was economy of expression. If you could see a way of reusing a bit of code then you jumped to it. Programs in general were full of jumps all over the place with no particular structure or design.

As a result the flow of control graph looked like spaghetti.

To boldly Goto...

But - this generally didn't matter because code was handcrafted and used and modified by the person who wrote it. spaghetti code was ok - not good but ok. 

Then high-level languages were invented - Fortran introduced the Goto. In fact at that time high level languages tended to use the underlying machine code as their model for there instructions and many of the control statements in Fortran were simply machine code instructions renamed - the jump became a Goto. And a particular type of conditional branch instruction in the machine became Fortran's computed goto. Fortran made programming easier but it was still very much a reflection of what the machine actually did. This was partly because we hadn't worked out what an abstract programming language should look like and partly because it helped with efficiency. Even though you were programming in Fortran your programs translated to very similar machine code. 

The problem is that high-level languages were used by lots of people and teams of programmers started to work on projects for the first time. Programs also got much bigger and hence their flow of control graphs grew in size.

The Goto was used in the way that it was in the machine code days. High level programmers generally Goto-ed all over the code and created huge blobs of spaghetti code.

Working in teams and having to come back to work on their old programs the spaghetti flow of control graphs made the code difficult to understand and difficult to debug. 

Block structure

Other languages that followed Fortran, notably Basic, used the Goto but academic languages like Algol took a different approach.

Instead of copying the machine code they introduced control statements that gave the programmer the ability to write If statements and loops with not a Goto or a jump to be found.

To many programmers at the time this was either a revelation or a mystery. Languages like Algol were hard to understand for programmers brought up on the free use of the Goto.

At the time a programmer would look at the block structured statements that a language offered and would not be able to see how to use them to create a program. They were accustom to thinking in terms of where they needed to go next in the program and not in terms of bigger block - loops and conditional and nesting and sequencing. It really was doubtful in some programmers opinion that you could use a block structured language to write any program you wanted to - but it was clear that the total freedom offered by Goto implied that you could do anything.

Why make things difficult when a simple jump to the code you want to execute next is all it takes?

The answer is of course that the free use of the Goto creates spaghetti and block structure produces a simpler flow of control graph.

Notice that you could use the Goto to create simple and neat flow of control graphs but this needed discipline and understanding. So it is not so much the Goto that is harmful but its uneducated use. 

The structured programming revolution

We were heading towards a crisis.

The majority of programmers were producing spaghetti and there was a growing need for more and better quality code. Dijkstra then wrote his famous paper about the Goto being a bad thing and people started to think about the problem.

The idea was that if you reduced programming to a simple set of building blocks then programmers would have to produce neat and simple flow of control graphs.

The era of "de-skilling" had started.

The idea was to make programming so easy that you didn't need spaghetti experts to create programs.  Languages like Algol and Pascal only provided block structured statements the if..else and three loops the for, the while and the until loop.

This was all you needed to write any program.

You could prove that it was all you need - any flow of control graph could  be constructed using just these few constructs. In fact you could prove (to be more accurate Dijkstra proved) that you only needed the if and either the while or the until loop and some extreme theorists proved you only need one of the loops as they gave you a conditional execution facility.

A pioneering book - programming as logical poetry.

So the Goto was out and structured modular programming was in. You wrote programs that consisted of tiny little bits of code - procedures - and each procedure had a small number of conditionals and loops. They had to be small enough to understand in a single quick look.

Modular structured programming was the only programming method in town and it was enforced  almost brutally. Programmers were dragged kicking and screaming way from the freedom of the Goto and into the straitjacket of structured modular programming. Of course it was for their own good.

The programs that resulted were better.

Dijkstra even thought that the free use of the Goto was so bad that exposure to it damaged the mind of a programmer for life. It certainly caused many a programmer to slip in a Goto into an otherwise fully structured program just because it seemed the easy way out.

In reality a velociraptor probably didn't appear and eat them - but the spaghetti monster probably did.

<ASIN:013215871X>

<ASIN:0138544719>

<ASIN:0201175363>

<ASIN:0387972994>

<ASIN:0201172372>