Programming is like this but it is active and dynamic rather than fixed. In programming x can usually be replaced by whatever you like and this is a huge difference. A repeating idea is that mathematics is static and programming is dynamic, but don’t take this too literally as mathematics has ways of dealing with dynamic by converting it to static.

If you follow this idea you will be wondering why so much time is being spent on explaining the obvious. However, if you don’t understand then nothing is obvious. The big problem with this simple idea is that it is very difficult to explain it because it is meta-linguistic, i.e. language being used to explain language.

For example, beginners are often subjected to explanations like:

Programmer: “So when I write

fd n

I don’t mean forward n. I mean forward whatever n is at the time.”

Student: “So what is n?”

Programmer: “It is whatever it is when you use the command.”

Student: “So what is n?”

Programmer: “Look it doesn’t have to be n, don’t get so hung up on the fact that it is n”.

Student: “Oh…”

Programmer: “For example it could be m.”

Student: “So what is m?”

Programmer: “It is whatever it is when you use the command….”

You can see that speaking about language is always difficult and in this case it can put a beginner off forever.

This particular problem gets even worse as we move on to more complex situations. Later, when we introduce the idea of a variable, you will discover that n can sometimes actually be n – or any other letter or word you care to think up. Yes, this gets complicated to explain, but then seems easy and obvious when you do understand it.

Some people seem to come to the table with a predisposition to accept such substitutions and the use of placeholders and take to it at once. Something that confirms to the programmer that it is an obvious idea and needs little explanation. Others don’t take to it at all easily and the unpracticed explanations only seem to confuse even more.

Given the idea of parameters, we can see that Fd n and Rt a are whole sets of instructions we can write programs that are much more interesting. For example, what does:

Fd 100
Rt 120
Fd 100
Rt 120
Fd 100

draw? 

Again, if you can't do it in your head try it on a piece of paper.

The answer is a triangle:

When run on Turtle Academy it produces:

Is Programming The Same As Giving Instructions?

Some more philosophy.

So programming is about writing down what to do. Isn't this the same as simply giving instructions to someone to achieve a goal?

Imagine that we have a drill sergeant on the parade ground shouting out orders to a single soldier. Suppose he shouts, forward march, right face, forward march, right face, forward march, right face, forward march. It is clear the result is that the soldier draws a square.

Is the drill sergeant programming? Sort of, but not quite. Programming isn't about giving instructions as they are needed, but about writing down the complete set in some form or another. It is about creating the whole thing not producing the commands as required.

Why is this different? The reason is that the drill sergeant isn't provably planning ahead. He is just reacting to the current state of the system and issuing an appropriate command. It might even be that the sergeant isn't aware that there is a program at all.

If you create a program you have to think your way into each of the positions that the program entails. You have to know that when the soldier has done Fd 100 Rt 90 he is at the first corner of the square facing in the direction of the next side. You do not see this fact as physical reality, you have to see it in your mind’s eye. When you construct a program, you get to drill the soldier without needing to put a soldier through any paces at all. It is not only that you have to put yourself into the soldier’s position you have to put yourself into future positions that are the result of your instructions.

Yes this is the Robert Burns situation all over again, but not just putting yourself into an other’s place but into their future.

Programming isn’t just working out what instruction to give to move the system on from its current state to a new state, it is about inferring what future state the system will be in as the result of lots of instructions and then working out the instruction needed.

Just as a clock maker assembles a set of cogs and gears to make a clock, the programmer puts together instructions which mesh together to create a mechanism. Both the clock mechanism and the program are static when created – neither ticks. The clock maker trusts that the arrangement of cogs will move in the way intended, but it is only when the mechanism is started can there be any certainty that this is correct. The programmer similarly gives birth to something static, only in this case we need the help of a computer - something that obeys, or runs, the program to bring it to life. 

A computer is something that obeys a program so converting it from static text to a dynamic mechanism. 

The program is like the clock before it is started and the ticking clock is the program when it is being obeyed by a computer.