Programming Languages

What is Programming?

I tell people I am a "Software Engineer".

Programming is a black art. It is the kind of thing that you grudgingly admit to doing, at night, with the blinds drawn and nobody watching. Tell people that you program computers and you will get one of the following responses:

• A blank stare.
• "That's interesting", followed by a long description of the double glazing that they have just had fitted.
• "My younger brother has a Sinclair Spectrum. He's a programmer as well."
• A look which indicates that you can't be a very good one as they all drive Ferraris and tap into the Bank of England at will.

Programming is defined by most people as earning huge sums of money doing something which nobody can understand.

Programming is defined by me as deriving and expressing a solution to a given problem in a form which a computer system can understand and execute.

One or two things fall out of this definition:

• You need to be able to solve the problem yourself before you can write a program to do it.
• The computer has to be made to understand what you are trying to tell it to do.

We are back to the term "Software Engineer" again!

I like to think of a programmer as a bit like a plumber! A plumber will arrive at a job with a big bag of tools and spare parts. Having looked at it for a while, tut tutting, he will open his bag and produce various tools and parts, fit them all together and solve your problem. Programming is just like this. You are given a problem to solve. You have at your disposal a big bag of tricks, in this case a programming language. You look at the problem for a while and work out how to solve it and then fit the bits of the language together to solve the problem you have got. The art of programming is knowing which bits you need to take out of your bag of tricks to solve each part of the problem.

From Problem to Program

Programming is not about mathematics, it is about organisation.

The art of taking a problem and breaking it down into a set of instructions you can give a computer is the interesting part of programming. Unfortunately it is also the most difficult part of programming as well. If you think that learning to program is simply a matter of learning a programming language you are very wrong. In fact if you think that programming is simply a matter of coming up with a program which solves a problem you are equally wrong!

There are many things you must consider when writing a program; not all of them are directly related to the problem in hand. I am going to start on the basis that you are writing your programs for a customer. He or she has problem and would like you to write a program to solve it. We shall assume that the customer knows even less about computers than we do!

Initially we are not even going to talk about the programming language, type of computer or anything like that, we are simply going to make sure that we know what the customer wants. Coming up with a perfect solution to a problem the customer has not got is something which happens surprisingly often in the real world.

The worst thing you can say to a customer is "I can do that". Instead you should think "Is that what the customer wants?".

This is almost a kind of self discipline. Programmers pride themselves on their ability to come up with solutions, so as soon as they are given a problem they immediately start thinking of ways to solve it, this almost a reflex action. What you should do is think "Do I really understand what the problem is?". Before you solve a problem you should make sure that you have a watertight definition of what the problem is, which both you and the customer agree on. In the real world this is often called a Functional Design Specification or FDS. This tells you exactly what the customer wants. Both you and the customer sign it, and the bottom line is that if you provide a system which behaves according to the design specification the customer must pay you. Once you have got your design specification, then you can think about ways of solving the problem.

You might think that this is not necessary if you are writing a program for yourself; there is no customer to satisfy. This is not true. Writing an FDS forces you to think about your problem at a very detailed level.

A Simple Problem

Consider the scenario; You are sitting in your favourite chair in the pub contemplating the universe when you are interrupted in your reverie by a friend of yours who sells double glazing for a living. He knows you are a programmer of sorts and would like your help in solving a problem which he has:

He has just started making his own window units and is looking for a program which will do the costing of the materials for him. He wants to just enter the dimensions of the window and then get a print out of the cost to make the window, in terms of the amount of wood and glass required.

"This looks like a nice little earner" you think, and once you have agreed a price you start work. The first thing you need to do is find out exactly what the customer wants you to do...

Specifying the Problem

When considering how to write the specification of a system there are three important things :

• What information flows into the system.
• What flows out of the system.
• What the system does with the information.

There are lots of ways of representing this information in the form of diagrams, for now we will stick with written text when specifying each of the stages:

Information going in

In the case of our immortal double glazing problem we can describe the information as:

• The width of a window.
• The height of the window.

Information coming out

The information that our customer wants to see is :

• the area of glass required for the window
• the length of wood required to build a frame.

What the program actually does

The program can derive the two values according to the following equations :

glass area = width of window * height of window
wood length = (width of window + height of window) * 2

Putting in more detail

We now have a fairly good understanding of what our program is going to do for us. Being sensible and far thinking people we do not stop here, we now have to worry about how our program will decide when the information coming in is actually valid.

This must be done in conjunction with the customer, he or she must understand that if information is given which fits within the range specified, your program will regard the data as valid and act accordingly.

In the case of the above we could therefore expand the definition of data coming in as :

• The width of the window, in metres and being a value between 0.5 Metres and 3.5 metres inclusive.
• The height of the window, in metres and being a value between 0.5 metres and 2.0 metres inclusive.

Note that we have also added units to our description, this is very important - perhaps our customer buys wood from a supplier who sells by the foot, in which case our output description should read :

• The area of glass required for the window, in square metres.
• The length of wood required for the frame, given in feet using the conversion factor of 3.25 feet per metre.

Note that both you and the customer must understand the document!

Having written this all up in a form that both you and the customer can understand, we must then both sign the completed specification, and work can commence. In a real world you would now create a procedure which will allow you to prove that the program works, you could for example say :

If I give the above program the inputs 2 metres high and 1 metre wide the program should print out : 2 square metres of glass and 9.75 feet of wood.

The test procedure which is designed for a proper project should test out all possible states within the program, including the all important error conditions. In a large system the person writing the program may have to create a test harness which is fitted around the program and will allow it to be tested. Both the customer and the supplier should agree on the number and type of the tests to be performed and then sign a document describing these.

Better yet, set up a phased payment system so that you get some money as the system is developed.

At this point the supplier knows that if a system is created which will pass all the tests the customer has no option but to pay him for the work! Note also that because the design and test procedures have been frozen, there is no ambiguity which can lead to the customer requesting changes to the work although of course this can still happen!

Note also in a "proper" system the customer will expect to be consulted as to how the program will interact with the user, sometimes even down to the colour of the letters on the display! Remember that one of the most dangerous things that a programmer can think is "This is what he wants"! The precise interaction with the user - what the program does when an error is encountered, how the information is presented etc., is something which the customer is guaranteed to have strong opinions about. Ideally all this information should be put into the specification, which should include layouts of the screens and details of which keys should be pressed at each stage.

Fact: If you expect to derive the specification as the project goes on either you will fail to do the job, or you will end up performing five times the work!

If this seems that you are getting the customer to help you write the program then you are exactly right! Your customer may have expected you to take the description of the problem and go into your back room - to emerge later with the perfect solution to the problem. This is not going to happen. What will happen is that you will come up with something which is about 60% right. The customer will tell you which bits look OK and which bits need to be changed. You then go back into your back room, muttering under your breath, and emerge with another system to be approved. Again, Robert's law says that 60% of the duff 40% will now be OK, so you accept changes for the last little bit and again retreat to your keyboard....

The customer thinks that this is great, reminiscent of a Saville Row tailor who produces the perfect fit after numerous alterations. All the customer does is look at something, suggests changes and then wait for the next version to find something wrong with.....

Fact: More implementations fail because of inadequate specification than for any other reason!

If your insisting on a cast iron specification forces the customer to think about exactly what the system is supposed to do and how it will work, all to the better. The customer may well say "But I am paying you to be the computer expert, I know nothing about these machines". This is no excuse. Explain the benefits of "Right First Time" technology and if that doesn't work produce a revolver and force the issue!

Again, if I could underline in red I would : All the above apply if you are writing the program for yourself. You are your own worst customer!

You may think that I am labouring a point here, the kind of simple systems we are going to create as we learn to program are going to be so trivial that the above techniques are far too long winded. You are wrong. One very good reason for doing this kind of thing is that it gets most of the program written for you - often with the help of the customer. When we start with our double glazing program we now know that we have to :

read in the width
verify the value
read in the height
verify the value
calculate width times height and print it
calculate ( width + height ) * 2 * 3.35 and print it

The programming portion of the job is now simply converting the above description into a language which can be used in a computer.......

Programming Languages

You might ask the question "Why do we need programming languages, why can we not use something like English?" There are two answers to this one:

• Computers are too stupid to understand English.
• English would make a lousy programming language.

Please note that this does not imply that tape worms would make good programmers!

To take the first point. We cannot make very clever computers at the moment. Computers are made clever by putting software into them, and there are limits to the size of program that we can create and the speed at which it can talk to us. At the moment, by using the most advanced software and hardware, we can make computers which are about as clever as a tape worm. Tape worms do not speak very good English, therefore we cannot make a computer which can understand English. The best we can do is get a computer to make sense of a very limited language which we use to tell it what to do.

Time Files like an Arrow. - Fruit Flies like a Banana!

To take the second point. English as a language is packed full of ambiguities. It is very hard to express something in an unambiguous way using English, if you do not believe me, ask any lawyer!

Programming languages get around both of these problems. They are simple enough to be made sense of by computer programs and they reduce ambiguity. There are very many different programming languages around, you will need to know more than one if you are to be a good programmer.