# Lecture 1: What are Programming Paradigms?

The Functional Paradigm

The Imperative Paradigm

The Logic Paradigm

The Object-Oriented Paradigm

The Scheme Language

This course is concerned with the study of programming language paradigms , that is the various systems of ideas that have been used to guide the design of programming languages. These paradigms are realised to a greater or lesser extent in various computer languages, although the design of a given language may reflect the influence of more than one paradigm.

Imperative: The language provides statements, such as assignment statements , which explicitly change the state of the memory of the computer.

Functional: In this paradigm we express computations as the evaluation of mathematical functions.

Logic: In this paradigm we express computation in exclusively in terms of mathematical logic

Object-Oriented: In this paradigm we associate behaviour with data-structures called " objects " which belong to classes which are usually structured into a hierarchy.

The paradigms are not exclusive, but reflect the different emphasis of language designers. Most practical imperative, functional and object-oriented languages embody features of more than one paradigm.

## The Functional Paradigm

In this we emphasise the idea of computation as being about evaluating mathematical functions combined in expressions . While all languages try to provide a representation of basic functions like addition, functional languages support a functional way of expressing computations on large and complex structures, although some such as Scheme also have imperative features. In a pure functional language a mathematical identity like:

```         fred(x) + fred(x) = 2*fred(x)
```
should hold. This is not necessarily the case for a non-functional language, for example in Pascal or C fred might be a procedure which had a side-effect, so that calling it twice has a different effect from calling it once. For example fred might contain the assignment g:=g+1 where g is a global variable. The primary motivation of writing functionally is to develop programs whose behaviour can easily be analysed mathematically, and in any case is easy to predict and understand.

The same non-functional aspect holds also for Java. A method call fred(x) will commonly have a side-effect.

However it has been difficult to design languages under the functional paradigm which produce programs which run as fast as under the imperative paradigm. With the high performance of modern computers, this matters less for many applications than the ability to write correct programs. The functional paradigm is hard to implement efficiently because if a storage location is once used to hold a value it is not obvious when it can be re-used - a computer running a program using the functional paradigm can spend a lot of effort determining the reusability of store.

Another way to think of the functional paradigm is to regard it as a way of taking to its limit the advice to avoid harmful side-effects in a program.

## The Imperative Paradigm

Languages which reflect this paradigm recognise the fact computers have re-usable memory that can change state. So they are characterised by statements, which affect the state of the machine, for example.
` x := x+1 `

This can only be understood mathematically by associating a sequence of values with x let us say x1, x2,..., where xt denotes the value the variable x has at some time t. Thus the above statement can be translated into mathematics as

xt+1 = xt + 1

This kind of reasoning is discussed in CS250. It gets increasingly hard to do as the state-changes get ever more complex (e.g. by assigning to data-structure components). However imperative languages can relatively easily be translated into efficient machine-code, and so are usually considered to be highly efficient. Many people also find the imperative paradigm to be a more natural way of expressing themselves.

Languages which use the imperative paradigm commonly have functional features - for example the basic functions of arithmetic (addition, subtraction...) are provided.

## The Logic Paradigm

While the functional paradigm emphasises the idea of a mathematical function, the logic paradigm focusses on predicate logic, in which the basic concept is a relation. Logic languages are useful for expressing problems where it is not obvious what the functions should be. Thus, for example where people are concerned, it is natural to use relations.

For example consider the uncle relationship: a given person can have many uncles, and a another person can be uncle to many nieces and nephews.

Let us consider now how we can define the brother relation in terms of simpler relations and properties father, mother, male. Using the Prolog logic language one can say:

```
brother(X,Y)      /* X is the brother of Y                    */
:-            /* if there are two people F and M for which*/
father(F,X),  /*          F is the father of X            */
father(F,Y),  /*    and   F is the father of Y            */
mother(M,X),  /*    and   M is the mother of X            */
mother(M,Y),  /*    and   M is the mother of Y            */
male(X).      /*    and   X is male                       */
```

That is X is the brother of Y if they have the same father and mother and X is male. Here ":-" stands for logical implication (written right to left).

Mathematical logic has always had an important role in computation, since boolean logic is the basis of the design of the logic circuits which form the basis of any computer. In the logic paradigm we make use of a more advanced construct, namely predicate logic, to give us languages of enhanced expressive power.

## The Object-Oriented Paradigm

The Object Oriented paradigm (often written O-O) focusses on the objects that a program is representing, and on allowing them to exhibit "behaviour". This is contrasted with the typical approach in the imperative paradigm, in which one typically thinks of operating on data with procedures. In the imperative paradigm typically the data are passive, the procedures are active. In the O-O paradigm, data is combined with procedures to give objects, which are thereby rendered active. For example in the imperative paradigm, one would write a procedure which prints the various kinds of object in the program. In the O-O paradigm, each object has a print-method, and you "tell" an object to print itself.

It is however possible to use certain non object-oriented languages to write object-oriented programs. What is required is the ability to create data-structures that contain machine code, or pointers to machine code. This is possible in the C language and in most functional languages (where functions are represented as as code).

Objects belong to classes. Typically, all the objects in a given class will have the same kinds of behaviour.

Classes are usually arranged in some kind of class hierarchy. This hierarchy can be thought of as representing a "kind of" relation. For example, a computational model of the University might need a class person to represent the various people who make up the University. A sub-class of person might be a student; students are a kind of person. Another sub-class might be professor. Both students and professors can exhibit the same kinds of behaviour, since they are both people. They both eat drink and sleep, for example. But there are kinds of behaviour that are distinctive: professors pontificate for example.

## The Scheme Language

This course is taught using the language Scheme which provides good support of the functional paradigm, since it contains a functional subset. However it also contains imperative features, which mean that we can look at the imperative paradigm within Scheme. It is a simple language but powerful enough to let us easily implement extensions which illustrate both the logic paradigm and the object-oriented paradigm.

In particular, it is quite easy to implement the object-oriented paradigm in Scheme because the functions available in Scheme can easily be attached to Scheme data-structures providing in effect objects that have behaviour arising from the attached functions.