Back to BASICs

Computer Programming is the art of making a computer do what you want it to do.

At the very simplest level it consists of issuing a sequence of commands to a computer to achieve an objective. In the Microsoft world MS DOS users used to create text files with lists of commands called BAT files. These simply executed the sequence of commands as a BATCH, hence the name. You can still produce these in Windows environments today but in practice they are rarely seen.

For example you might be producing a document (such as this tutorial) which comprises lots of separate files. Your word processor may produce backup copies of each file as it saves a new version. At the end of the day you may want to put the current version of the document (all the latest files) into a 'backup' directory/folder. Finally, to tidy up, delete all the backup files ready to start work the next day. A simple BAT file to do this would be:

COPY *.HTM BACKUP
DEL *.BAK

If the file were called SAVE.BAT then at the end of each day I could simply type SAVE at a DOS prompt and the files would be saved and backups deleted. This is a program.

Note: Users of Linux or other operating systems have their own versions of these files often known as shell scripts. Unix shell scripts are much more powerful than DOS BAT files, and support most of the programming techniques that we will be discussing in this course.

Let me say that again

If you were a little daunted by that, please don't be. A computer program is simply a set of instructions to tell a computer how to perform a particular task. It's rather like a recipe: a set of instructions to tell a cook how to make a particular dish. It describes the ingredients (the data) and the sequence of steps (the process) needed to convert the ingredients into the cake or whatever. Programs are very similar in concept.

A little history

Just as you speak to a friend in a language so you 'speak' to the computer in a language. The only language that the computer understands is called binary and there are several different dialects of it - which is why that cool iMac program won't run on your PC and vice versa. Binary is unfortunately very difficult for humans to read or write so we have to use an intermediate language and get it translated into binary for us. This is rather like watching Clinton and Yeltsin talking at a summit meeting - Clinton speaks, then an interpreter repeats what has been said in Russian. Yeltsin replies and the interpreter again repeats the sentence, this time in English.

Surprisingly enough the thing that translates our intermediate language into binary is also called an interpreter. And just as you usually need a different interpreter to translate English into Russian than you do to translate Arabic into Russian so you need a different computer interpreter to translate Python into binary from the one that translates BASIC into binary.

The very first programmers actually had to enter the binary codes themselves, this is known as machine code programming and is incredibly difficult. The next stage was to create a translator that simply converted English equivalents of the binary codes into binary so that instead of having to remember that the code 001273 05 04 meant add 5 to 4 programmers could now write ADD 5 4. This very simple improvement made life much simpler and these systems of codes were really the first programming languages, one for each type of computer. They were known as assembler languages and Assembler programming is still used for a few specialized programming tasks today.

Even this was very primitive and still told the computer what to do at the hardware level - move bytes from this memory location to that memory location, add this byte to that byte etc. It was still very difficult and took a lot of programming effort to achieve even simple tasks.

Gradually computer scientists developed higher level computer languages to make the job easier. This was just as well because at the same time users were inventing ever more complex jobs for computers to solve! This competition between the computer scientists and the users is still going on and new languages keep on appearing. This makes programming interesting but also makes it important that as a programmer you understand the concepts of programming as well as the pragmatics of doing it in one particular language.

I'll discuss some of those common concepts next, but we will keep coming back to them as we go through the course.

The common features of all programs

A long time ago a man called Edsgar Dijkstra came up with a concept called structured programming. This said that all programs could be structured in the following four ways:

• Sequences of instructions
• Loops
• Branches
• Modules

Along with these structures programs also need a few more features to make them useful:

• Data
• Operations (add, subtract, compare etc)
• Input/Output capability (e.g. to display results)

Once you understand those concepts and how a particular programming language implements them then you can write a program in that language.

Let's clear up some terminology

We already said that programming was the art of making a computer do what you want, but what is a program?

In fact there are two distinct concepts of a program. The first is the one perceived by the user - an executable file that is installed and can be run repeatedly to perform a task. For example users speak of running their Word processor program. The other concept is the program as seen by the programmer, this is the text file of instructions to the computer, written in some programming language, that can be translated into an executable file. So when you talk about a program always be clear about which concept you mean.

Basically a programmer writes a program in a high level language which is interpreted into the bytes that the computer understands. In technical speak the programmer generates source code and the interpreter generates object code. Sometimes object code has other names like: P-Code, binary code or machine code.

The interpreter has a couple of names, one being the interpreter and the other being the compiler. These terms actually refer to two different techniques of generating object code from source code. It used to be the case that compilers produced object code that could be run on its own (an executable file - another term) whereas an interpreter had to be present to run its program as it went along. The difference between these terms is now blurring however since some compilers now require interpreters to be present to do a final conversion and some interpreters simply compile their source code into temporary object code and then execute it.

From our perspective it makes no real difference, we write source code and use a tool to allow the computer to read and execute it.

The structure of a program

The exact structure of a program depends on the programming language and the environment that you run it on. However there are some general principles:

• A loader - every program needs to be loaded into memory by the operating system. The loader does this and is usually created by the interpreter for you.
• Data definitions - most programs operate on data and somewhere in the source code we need to define exactly what type of data we will be working with. Different languages do this very differently. All of the languages we will use allow us to create a new data definition just by using the data, we'll see what I mean in the next section!
• Statements - these are the core of your program. The statements actually manipulate the data we define and do the calculations, print the output etc.

Most programs follow one of two structures:

Batch programs

These are typically started from a command line (or automatically via a scheduler utility) and tend to follow a pattern of:

• Initialize internal data
• Read input data
• Process that data
• Print or store results

Event driven programs

Most GUI systems (and embedded control systems - like your Microwave, camera etc) are event driven. That is the operating system sends events to the program and the program responds to these as they arrive. Events can include things a user does - like clicking the mouse or pressing a key - or things that the system itself does like updating the clock or refreshing the screen.

Event driven programs generally look like:

• Initialize the internal data
• Wait for events to arrive
• Identify an incoming event and react accordingly