Beginning to program

Now that we have studied how to think through a problem, and have an idea how we might go about solving it, it is time to consider translating our solution into a real program. Well, almost!

Programming Languages

What is a programming language? For that matter, what is a language in general? If we restrict our discussion to written languages here, then a language is just a series of symbols strung together according to rules that dictate what goes where. If we string together the symbols in the right order, we might be able to make sense of the things we write. Groups of people set up these rules so they can communicate with each other. Everyone agrees on how to interpret the symbols.

Confused? The symbols we use in English are the words (correctly spelled, of course), and the punctuation marks we add in at the right spots. We string symbols together to form sentences, sentences combine to form paragraphs, and paragraphs combine to form lots of bigger things like books (or course notes!)

A programming language is very similar. We will have a bunch of rules on how we form various symbols and where we put punctuation, and rules that say how we combine things into larger and larger forms. Just like in your English classes in schools, we will need to learn the rules, and learn what various things mean in our new language. What you will go through is much like learning any foreign language!

Syntax rules

The rules that dictate in what order things appear are called Syntax Rules. You have run into these before. We know that the subject of a sentence comes before the verb and so on. If we form sentences in the wrong order, nothing makes sense:

• Go lake in the jump

(Even if you can figure out what this sentence means - it is not an acceptable sentence! And no, you are not supposed to do that anyway!)

In programming, we form sequences of symbols into something called statements (not sentences). If the statement is syntactically correct, the computer will be able to do one specific task defined by that statement.

So, our first order of business is figuring out how we will learn these syntax rules. Over the years, programmers have come up with a number of ways to show folks how to put programs together. The one way I like the most is something called a Railroad Diagram.

Railroad Diagrams

The basic idea here assumes you played with toy trains at some point in your life. You know how they work. You start them up and they follow the tracks. We might have switches along our tracks, and once they are set, the train just moves along to the right track and keeps chugging along. The train only goes where the tracks tell it to go.

Pretend you are driving the train and you have a program with you. The program will direct how the train travels. You will look at each symbol in the program and only proceed if you can verify that that symbol is legal at the point where you are. Hmmm.

The clever designers of the tracks have placed legal symbols along the tracks that you can see as you move along. Your job is to follow the tracks, checking that you can match up symbols in your program with symbols along the tracks as you move. If you ever get to a place where the symbol in your program cannot be matched to a symbol along the tracks, you have to stop - your program cannot work! You have syntax errors!

Hang in there, it gets a bit more complicated before we can continue with this idea.

Now, every once in a while, we will come to a switch in the tracks. Each possible path we can move along will have a different symbol along it. We will need to follow the track with the symbol we have in our program. Each of the other tracks represent paths some program could have followed, but not ours!

There is one more wrinkle in all of this. The tracks are laid out in short chunks - called diagrams. Each diagram has a name. We will enter the chunk at one point and leave at another point. In the middle, we might enter a station with a particular name. That name might be the name of another diagram. If this happens, you are supposed to move the train from the current diagram to the new diagram and stay there until you reach the end of that diagram, then come back to where you started and continue. Yikes! This sounds hard, but just visualize that happening, and remember where you were before you moved the train.

Wow, all of this sounds complicated, but once we walk an example through, it should become clear.

An example for a simple robot

Let’s start off by considering a simple language designed to control a small robot which has two independent motors controlling wheels that move the robot. (These is a caster wheel on the botton so it does not fall over). Our language needs to provide simple commands to make it move. We need to include commands that account for the passing of time so the robot mover in a reasonable manner.

Note

In this lecture, the robot language is not really that important, we are looking at how things are expressed in a computer language. Very precisely!

Here is an example of a simple Railroad Diagram. This one defines a PAUSE statement in our robot language. This one should make the robot program delay a bit without changing anything. If it is moving, it will continue to move;

The train starts at the left side of the diagram. The symbols with rounded ends represent legal symbols that we should see in our program. Those with square ends are those stations we talked about earlier. They should be the names of other diagrams we have somewhere.

In this example, the word PAUSE is required, and we should see it in our program if our train is on this particular track moving along.

Immediately after that word, we must find an open parenthesis. Most programming languages allow white space like tabs or spaces (or end of line marks, which we cannot see) between symbols. As long as it is obvious where one word or mark ends and another starts, we can usually ignore white space in our program and just consider the obvious symbols. So these two PAUSE statements are OK according to our rules:

PAUSE ( 10 )
PAUSE    (10)

Most modern programming languages are pretty easy-going when it comes to white space and where you place your marks. However, professional programmers usually expect (or require) that you follow style rules as you design your programs. So, watch out. And, you will occasionally run into languages (like Python) where white space rules are part of the language and failure to use those rules will give you a program that will not compile or even work!

More complex diagrams

Now, we did not say anything about that number box in the above diagram. We need another rule (diagram) that tells us how to form that thing in the box (number in this case). When the train enters this station, it is magically transported to the tracks that describe a number, and we stay there until we reach the end of the line! At that point, we are magically returned to the station where we left, and continue on as though nothing had happened. Here is the diagram for a number:

Notice that this diagram also has a rectangular box, but it should be clear what we need to see at this point, so we do not need another diagram. A digit is just one of the simple symbols 0,1,...9.

This diagram has a switch in it! When we reach the switch, we need to consult our program and see what is there. If we have just processed a digit, and we immediately see another digit, we are to take the switch that leads back around so we go through the digit station again. Only when the next thing in our program is not a digit will we escape this particular diagram!

According to this rule, we can have as many digits in a row as we like. Real programming languages will limit us to some big number, since computers cannot just compute any old number we like, there are limits in every language.

How many digits must we provide to have a good number? At least one, but possibly a large number of them. Can we place white space between the digits? In this case, that is not allowed. A space in the middle of one number would break it into two successive numbers, and the tool that processes our program - called a compiler will not know what to do (unless there is a rule somewhere that allows two consecutive numbers in the language!

More than one diagram - yikes!

When we have a number of diagrams, we need to be told which one of the diagrams we are to start with. Guess what, we call this special rule the Start Rule. Let’s build a start rule for our robot language:

This one is too simple! Let’s look at the diagram for statements.

Now we see that a full program in our language is just a sequence of one or more statement things. Here is what a statement can be:

This one is interesting, we can choose between any one of seven different statement types. We only get to choose one in this rule, but since we are allowed to loop back and get another statement as part of our program, we see that a full program can be a sequence of one or more statements, each of which is one of these seven possibilities.

Finishing off our robot language

We need diagrams for each of our statement types to fully define this toy language. Here are the simple ones:

These two just require that we see these symbols in our program. The next two handle turning left and right.

The last two are a bit more complex.

The FOR statement

This is our looping statement. We will have a counter that starts off set to some initial value and will count up to some final value. As it counts, it will do a bunch of things. What things? The things inside the curly braces! We are allowed to have as many statements as we like inside these braces, and when we are done, we should see the closing brace in our program.

The IF statement

This statement is our basic decision statement. We will be allowed to examine something called a condition and decide which way we want our train to go.

So all we need now is to see what conditions we are allowed to have.

I am not going to show a diagram for this now. You should go back to the original definition of our robot language and see if you can come up with one yourself.

Phew, that is a lot to study. If this all seems too complicated, remember we are trying to learn how to control a pretty dumb gadget called a computer. We want to have clearly defined programming languages to work with, and it is vital that we be precise in defining how those languages are structured. Once you learn the syntax rules and understand what each statement will make the computer do, your job is to creatively put together a string of these statements and make the computer do neat things.

The point of showing you all these diagrams is to introduce you to the concept of a formal definition of a language. Each language you encounter has its own set of rules, and was designed by some folks to help you program a computer to do something useful.