1. Definition
  2. Example Imperative Languages
  3. Features of Imperative Languages
  4. Structured and Modular Programming.


QUESTION: What is an imperative language?

ANSWER: We can define such languages according to the characteristics that they display:

QUESTION: Out of the five principal programming language paradigms the imperative is the most popular, why?

However, on the downside there is a tendency for programmers to get "bogged down" with control issues.

QUESTION: Compiled or non-compiled?


All modern imperative languages can trace their origins back to three imperative languages: FORTRAN, ALGOL 60 and COBOL. Consequently these influential languages are often described as foundation languages.

FORTRAN The IBM Mathematical FORmula TRANslating system.

ALGOL 60 ALGOrithmic Language 1960.

COBOL COmmon Business Oriented Language.

Relationships between a number of common imperative (and other) programming languages are shown in the "wiring diagram" presented in Figure 1.


Figure 1: Relationship between a number of common imperative programming languages.

A large number of modern imperative languages follow the style orginated in Algol 60. These lanaguages include Ada and Pascal, and can thus be described as Algol style langauges. There is also a significant group of languages that can be described as C style languages, these include the Object Oriented language C++ and Java. The most widely used imperative language found in industry is currently (the year 2000) C, which tends to dominate the market (with C++ and Java catching up!). This is thus one of the languages that will feature in the following pages. So that we can compare C style langauges (and in particularly C) with other imperativeclanguages we will also feature Ada and Pascal which belong to the Algol style of programming language. Pascal is still a popular teaching language, while Ada was for many years the language of choice for U.S. ministry of defence (arguably the world's largest procurer of software) contracts.




The 1960s saw remarkable developments in the field of electronics with the result that more and more powerful hardware components could be produced more and more cheaply. In parallel it was assumed that it would similarly be possible to construct ever larger and more complex software. This assumption proved to be quite wrong - programs failed to be ready on time, greatly exceeded their budget, contained many errors and did not fulfil customer expectations. This phenomenon became known as the software crisis. Among the reasons for this crisis was poor project management, and the fact that many programmers considered their programs to be their property. Thus many individual and curious programming styles developed, and it proved difficult to create error-free programs. In order to remedy this, the concept of structured programming was devised in the late 1960s (by Dijkstra and others). The aim of structured programming is to create programs that are:

Structured programming can be said to be a set of rules and recommendations for how "good" programs should be written. It emphasises programming using sequences, conditions and repetition (not jumps and goto statements). These are all constructs which have a predictable logic, i.e. they are entered at the top and exited at the bottom.

The introduction of the concept of structured programming quickly indicated the need for the support of suitable programming languages. It was this need that initiated the development of what became known as structured languages such as Pascal.


During the 1970s it became clear that even well-structured programs were not enough for mastering the complexity involved in developing a large program system. It was also recognised that it was necessary to support the division of the program into well-defined parts or modules, that could be developed and tested independently of one another, so that several people could work together within one large programming project. Modular programming is thus concerned with the subdivision of programs into manageable "chunks". The concept encompasses ideas about levels of abstraction - modules are usually arranged in a hierarchy of abstraction. It also espouses information hiding - modules should be designed so that information contained within a module is not accessible to other modules that have no need for such information.

Grant Malcolm (Based on notes by Frans Coenen)
Last modified: Fri Oct 5 11:20:56 BST 2001