Imperative or procedural languages are command-driven or statement oriented language. The basic concept is the machine state, the set of all values for all memory locations in the computer. A program consists of a sequence of statements and the execution of each statement causes the computer to change the value of one or more locations in its memory. i.e. to enter a new state.
The syntax of such languages generally has the form:
Imperative languages are defined according to the characteristics that they display.
- By default, statements (commands) are executed in a step-wise, sequential, manner.
- As a result order of execution is crucial.
- Destructive assignment - the effect of allocating a value to a variable has the effect of destroying any value that the variable might have held previously.
- Control is the responsibility of the programmer - programmers must explicitly concern themselves with issues such as memory allocation and declaration of variables.
- The imperative paradigm is the most established paradigm.
- It is much more in tune with the computer community's way of thinking.
- Imperative programs tend to run much faster than many other types of program.
- Programmers are prepared to sacrifice some of the advanced features and programming convenience generally associated with higher level languages in exchange for speed of execution.
- Most modern imperative languages are designed explicitly for compilation.
- Older imperative languages (e.g. BASIC and APL), and some very high level imperative-languages (e.g. ICON) are interpreted.
C, C++, FORTRAN, Algol, PL/I, Pascal,
, Smalltalk and COBOL are supported by this model. This model follows from the hardware of the conventional computer that executes instructions sequentially. Ada
An alternative view of the computation performed by a programming language is to look at the function that the program represents rather than just the state changes as the program executes, statement by statement. We can achieve this by looking at the desired result rather than at the available data. Languages that emphasize this view are called applicative or functional language.
Rather than looking at the successive machine states of a computation, we consider the successive functional transformations that we must make on data to arrive at our answer. The syntax of such languages generally is similar to:
functionn (…function2 (function1 (data))…)
LISP and ML are two functional languages in this book that support this model.
Rule Based Languages:
Rule based languages execute by checking for the presence of a certain enabling condition and when present executing an appropriate action. The most common rule-based language is Prolog, also called a logic programming language, because the basic enabling conditions are certain classes of predicate logic expressions.
Execution if a rule-based language is similar to an imperative language except that statements are not sequential. Enabling conditions determine the order of execution. The syntax of such languages generally is similar to the following:
enabling condition1 action1
enabling condition2 action2
enabling conditionn actionn
The common business application of decision tables is a form of rule-based programming. In this case, enabling conditions on data are governed by the presence or absence of enabling data values in a data record. BNF parsing techniques and tools like YACC to parse programs are rule-based techniques that use the formal syntax of the program as the enabling condition.
Object oriented programming is becoming an increasingly important computational model. In this case, complex data objects are built, then a limited set of functions are designed to operate on those data. Complex objects are designed as extensions of simpler objects, inheriting properties of the simpler object. By building concrete data objects an object-oriented program gains the efficiency of imperative languages. By building classes of functions that use a restricted set of data objects, we build the flexibility and reliability of the applicative model.
Spaghetti code is a pejorative term for source code which has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow tends to look like a bowl of spaghetti, i.e. twisted and tangled. Spaghetti code can be caused by several factors, including inexperienced programmers and a complex program which has been continuously modified over a long life cycle. Structured programming greatly decreased the incidence of spaghetti code.
10 i = 0
20 i = i + 1
30 PRINT i; " squared = "; i * i
40 IF i >= 10 THEN GOTO 60
50 GOTO 20
60 PRINT "Program Completed."
Structured code is code stored in a data structure instead of in typical text files. Text file source code must follow restrictive syntax rules in order for the source code to be parsed by a compiler into a structure called the abstract syntax tree (AST). Structured source code, however, has much less restrictive syntax rules because it is created and edited by structured editors directly on the abstract syntax tree and the parsing step is bypassed. This also separates the notation from the software content, which in turn increases substantially the variety of possible notations available for domain experts and programmers to express their intentions.
Example: (same as above example).
FOR i = 1 TO 10
PRINT i; " squared = "; i * i
PRINT "Program Completed."
i. Pratt, Terrence and Zelkowitz, Programming Languages Design and Implementation, Pearson Education, 4th edition.