This is the common view of programming most people have. Most compilers will produce code which is imperative. Imperative languages run instructions in a well specified sequence, one after the other. They also have control statements and jump statements to allow more flexibility.
They also have iterative statements which allows sections of code to be repeated. This is the FOR loops etc. Finally they will also have some method of calling procedures. Now that we have an overview we can look at the proper definition of an imperative language.
We have already had a brief look at what statements are but what is the state? This is something which is very much implicit when you first learn about programming but is vital to creating good code. You would of already written code which will alter the state. Consider the following simple assignment statement
This is changing the state of the program. The state is all the variables in the program which have not dropped out of scope. As such global variables will always be part of the state while local variables will drop in and out of the state. When you change a variable through an assignment then you are changing the state of the system. There are ways of graphically representing the state, however they can get overly complicated very quickly. Consider an integer value of 2 bytes. It can store 65536 different values. As such a single integer value can have a possible 65536 different state changes. Drawing that on a diagram would be a pointless exercise.
Consider two Boolean values A and B. A has 2 possible values and B has 2 possible values. As such there are 4 possible states. If we add another Boolean variable we will have double the number of possible states. Most simple programs will have so many possible states that it would be infeasible to consider them all.
So if it is infeasible to consider all states why should we care so much about the state. The answer is to do with a notion called code correctness. Testing code can only test a small number of possible states. As such it is likely we shall miss some bugs. Our code can not be considered correct. If we use incorrect code for safety critical systems, such as airplane flight managers, we can straight away see how this situation would be unacceptable. There is ways of deciding if code is correct, known as automatic verification. What it tries to do is consider all possible states and try and prove that certain properties of the system are true. As the number of states increase the job of proving the code becomes exponentially more difficult. What we really are interested in is showing that our code can not put itself into a incorrect or dangerous state.