|The Trick Of The Mind - Programming & Algorithmic Thought|
|Written by Mike James|
|Thursday, 14 May 2015|
Page 1 of 2
This introductory chapter of our new ebook on the nature of programming is aimed at programmers and non-programmers alike. If you can't program then find out why you should learn. If you can program then find out why what you do is special and how it is a generally applicable thinking style.
The Trick Of The Mind - Programming & Algorithmic Thought
Programing is a strange activity in the modern world.
It isn't quite high science like mathematics; it isn't high art like poetry; and it isn't purely an artisanal craft. Because it is so involved with computers and computer language, you can make the mistake of thinking that programming is just the ability to write programs for computers. It is more than this, but you can also learn to program just by mastering a programming language. While does qualify you as a programmer,it doesn't necessarily confer understanding of the deeper ideas and techniques that the real foundations of what you are doing.
This is very strange and there are no obvious parallels in any other sphere or endeavor.
It is as if you could learn to solve quadratic equations by learning the language of algebra, but without having any understanding of math. Some people are of the opinion that our current education system does actually achieve this. To sum this up:
You can learn to program by just doing it, but this doesn't mean you have any insight into what you are doing.
Programming involves a well-developed type of thinking that we all use to some extent or another. Being able to do this well and going beyond the basics is the key distinction between the programmer and the non-programmer and not any facility with technology or familiarity with any particular programming language.
To paraphrase a perhaps misattributed quote of Edsger W. Dijkstra:
Programming is no more about computers than astronomy is about telescopes.
But to start at the beginning...
Descriptions To Prescriptions
Language is where programming and algorithmic thought starts out and language is naturally descriptive.
Consider this scene from a novel:
"She was agitated and paced the room. First she walked forward, turned sharply right and walked again, then right again and finally a last turn before she returned to the spot she had started from."
Clearly our heroine walked in something like a square, or perhaps a rectangle.
We humans seem to be very good at this sort of description and can deduce things from it that are quite complicated. For example, did she walk around the room clockwise or anticlockwise?
It is as if we took the description and imagined what occurred. We take the static text and turn it into something dynamic in our mind's eye. This is the trick of the mind that the title refers to and it is how programming comes about - all we need is a simple change.
Suppose that, instead of regarding the text as a description we consider it to be a prescription for what is to happen:
"First walk forward, turn sharp right and walk again, then turn right again and walk, finally turn right again and walk back to the spot you started from."
Notice that we have had to rephrase the English into an imperative form to give commands rather than a description but the structure is the same. If you read this you can project forward to see what would happen if you actually obeyed the instructions.
Again the mind's eye lets you see what is to happen in the same way it allowed you to see what had happened.
This is all there is to programming and algorithm thought. You simply have to write down a prescription for what is to happen rather than a description of what has happened.
There really is little difference at this level between description and prescription, but what difference there is, is important.
It turns out that there are a number of very general ways of writing what you want to happen and the example given above is in imperative form because it tells you what to do as a set of commands.
Notice that this is more amazing than you might think.
The imperative program is just a static piece of text yet give it to a human and something dynamic happens. The static text gives rise to a changing behaviour and it is this idea that results in computers doing things and responding to you even thought their programs are just static text.
The idea that something static can give rise to a controlled dynamic process is very general and very fundamental. For example consider the sequences of bases in a strand of DNA. This is a static sequence of symbols and yet when "obeyed" the result is a protein and in the limit an entire animal.
This is an idea we need to return to after gathering more examples.
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 imagination. You could say that being vague is part of the art of creative writing, but it isn't so much 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 or 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.
walk forward 10 units, turn 90 degrees right, walk forward 10 units , turn 90 degrees right, walk forward 10 units, turn 90 degrees right, walk forward 10 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:
FW10 = Forward 10 Units
Once you have one abbreviation why not keep inventing them. For turn 90 degrees right you could just use RT90. Now you can write the instruction as:
It means the same thing and this is your first program in our programming language giving the instruction to go forward 10, right turn, forward 10, right turn, forward 10, right turn, forward 10.
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
if it had been presented to you at the start of the chapter without any explanation and the question posed - what does this do?
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 FW and RT mean then it all becomes simple again.
In case you think that this example is a bit contrived then it is worth mentioning that these commands are part of a full computer language called Logo - i.e. this is not a particularly contrived example.
|Last Updated ( Tuesday, 06 December 2016 )|