Your First Programming Language

English, or any other natural language, is great for descriptions but when you start to use any such language prescriptively you quickly see problems of imprecision.

When you are writing a poem describing the sea, does it matter if the description is vague? In poetry, keeping descriptions vague is often a good idea because it allows the reader to exercise their imagination. You could say that being vague is part of the art of creative writing, but it isn't so much a part of creative programming.

Take the first part of our example:

First walk forward, turn sharp right and...

What does "sharp right" mean? Clearly the intention is that it is a right angle, 90 degrees, but it isn't 100% clear and different people might choose different interpretations producing different results. 

This isn't good if you want to be sure that the person doing the walking ends up back at the same spot. 

What we need is a precise statement of what is to be done and for this we need to spend more effort setting down exactly what is to happen. 

For example:

Walk forward 100 units, turn 90 degrees right, walk forward 100 units, turn 90 degrees right, walk forward 100 units, turn 90 degrees right, walk forward 100 units. 

is an unambiguous set of instructions. It can be difficult sometimes to know when a set of instruction is precise and this is something else we need to come back to. You could say, for example, that it isn't clear what 10 units are and what if the person doesn't know what 90 degrees is? For the moment we have to insist that the person does know what a 90-degree turn means, or if not they need to go and find out. 

This form of expression may be precise but it is tedious – so much writing!

Anyone finding themselves in the position of having to write "walk forward n units" over and over again would probably resort to an abbreviation:

Fd 100 = Forward 100 Units

Once you have one abbreviation why not keep inventing them. For turn 90 degrees right you could just use Rt 90.  Now you can write the instruction as:

Fd 100 Rt 90 Fd 100 Rt 90 Fd 100 Rt 90 Fd 100

It means the same thing and this is your first program in our programming language giving the instruction to go forward 100, right turn, forward 100, right turn, forward 100, right turn, forward 100.

Yes, it is that easy. 

However, don't fall into the trap of thinking that it really is trivial. This is a sophisticated thing to do. It only seems easy because of the trick of the mind that makes it easy.

Later you will see how this simple idea gets increasingly elaborate. If you follow its development step by step then it is always easy, but if you are thrown into its later stages without preparation it is a frightening mess. After all what would you make of the program: 

Fd 100
Rt 90
Fd 100
Rt 90
Fd 100
Rt 90 
Fd 100

if it had been presented to you at the start of the chapter without any explanation and you have been asked, “What does this do?”. Now we not only know that it draws a square, we also know exactly how and why it draws a square.

This understanding is an important part of the programming skill. Programmers don’t just run programs on computers they run them in their heads as part of understanding them.

The abbreviated form of the list of instructions is a program and the formalized way of writing the instructions is a programming language. The instructions written in this abbreviated form are often referred to as code and the act of constructing a program is known as coding. This isn’t a particularly meaningful or appropriate terminology because a code is intended to hide meaning and programming languages should strive to be understandable. There is no intent in coding of covering up the meaning of the instructions, in fact as will become clear the opposite, i.e. to be clear, is the main intent. It is almost a cruel joke that programming is so often called coding.

Codes and languages that you make up yourself are very easy to understand. Codes and languages that other people make up are much harder!

Of course, once you know what Fd and Rt mean then it all becomes simple again. This is not to say that people aren’t sometimes motivated to make their invented language deliberately difficult to understand. Sometimes for fun or for academic advancement someone will create a language intended to be difficult to understand, but this is rare.

This is not to say that inventing programming codes is easy. The problem is that there is a tension between choosing short abbreviations and meaningful abbreviations. For example, you could use F for forward or MoveForward in place of Fd. Which is better? Clearly the long winded MoveForward is easier to understand, but this advantage would soon wear off after you had to type it in 1000 times. There is also the issue of what is meaningful to the creator of the language might not be meaningful to the user. For example, in the programming language Lisp the instruction car extracts the first item in a list. Is “car” a reasonable abbreviation for “extract the first item”? The original inventor of the language thought so because it stands for “Contents of the Address Register” which was the very low-level machine language instruction needed to find the first element. It made sense to the creator of the language, but many programmers working in Lisp have learned to pronounce “car” as “first” to make what they are doing easier to understand!

Compared to car, the use of Fd seems positively easy and it is easy to find abbreviations for movements that are easy to remember once you have seen them.

In case you think that this example for drawing shapes is a bit contrived then it is worth mentioning that these commands are part of a full computer language called Logo –and so this is not at all a contrived example.