Programming paradigms and procedural programming

Procedural, object-oriented, declarative and low-level paradigms, the structured approach, and hierarchy charts.

A1.6Programming techniques and object-oriented programmingA level20 min

Do this lesson in the simulator

Everything you have written so far has been a list of instructions, grouped into subroutines. That is one style of programming, and the most common one to learn first, but it is not the only one. A programming paradigm is a style or approach to programming: a way of organising a program, and the ideas a language is built around. Languages are designed for one paradigm or support several; Python supports procedural, object-oriented and functional styles.

The main paradigms

Paradigm The program is Examples On the robot
Procedural (imperative) A sequence of instructions that change the program's state, grouped into procedures and functions Python, C, Pascal forward, then turn_right, in the order written
Object-oriented (imperative) Objects that bundle data with the methods that act on it, sending each other messages Python, Java, C# A Robot object with its own position and a drive method
Functional (declarative) Functions applied to values, with no changing state Haskell, and parts of Python A route's length computed as sum of a mapped list
Logic (declarative) Facts and rules; the language searches for answers Prolog "there is a route from A to C if there is a route from A to B and from B to C"
Low-level Instructions for one processor, in machine code or assembly Assembly, OCR's Little Man Computer LDA, ADD, STA for the Little Man Computer
Event-driven Handlers that run when something happens JavaScript in a web page A subroutine that runs when a bump sensor fires

The biggest split is between imperative paradigms, where you say how to get the answer step by step, and declarative ones, where you say what the answer is and the language works out how. SQL, which you used at GCSE, is declarative: SELECT name FROM runs WHERE time < 20 never says how to search the table.

The same job, three ways:

readings = [31.0, 51.0, 15.0, 44.0]

# procedural: step by step, changing a total
total = 0
for cm in readings:
    if cm > 40:
        total = total + cm
print(total)

# functional: a value built from functions, nothing changes
print(sum(filter(lambda cm: cm > 40, readings)))

# object-oriented: the data looks after itself
class Survey:
    def __init__(self, readings):
        self.readings = readings
    def clear_total(self, limit):
        return sum(cm for cm in self.readings if cm > limit)

print(Survey(readings).clear_total(40))

Run this in the simulator

All three print 95.0. Module A13 covers functional programming, low-level languages come in the computer architecture module, and the rest of this module is procedural and object-oriented.

Procedural programming

In procedural programming the program is a sequence of instructions, organised into procedures and functions that the main program calls. Data is kept in variables and passed between subroutines as parameters and return values. The code you wrote in lessons A1.1 to A1.5 is procedural.

Procedural programs are written with a structured approach:

  • Only three control structures are used: sequence, selection and iteration. There are no jumps from one part of the code to another, like the GOTO of older languages.
  • Each block has one way in and one way out, so it can be understood on its own.
  • The problem is designed top-down: split into subproblems, then those split again, until each is small enough to be one subroutine.
  • Each subroutine uses local variables and parameters rather than globals.

Hierarchy charts

A hierarchy chart shows how a program is divided into subroutines. The main program is at the top; each box is a subroutine; a line down from a box goes to a subroutine that it calls. It shows what calls what, not the order or how many times.

Hierarchy chart for the shapes programmain programpolygon(sides, length)fanfare()side(length)corner(sides)
Hierarchy chart for the shapes program

Reading it: the main program calls polygon and fanfare; polygon calls side and corner. The chart does not say that polygon calls side several times in a loop; that detail belongs in the code or a flowchart.

The advantages of the structured approach:

  • Each subroutine is small, so it is easier to write, read and test, and can be tested alone.
  • Different subroutines can be written by different people at the same time.
  • A subroutine can be reused in other programs.
  • Programs are easier to maintain: a change is made in one subroutine, and the others are unaffected if its interface stays the same.
  • The design shows the whole structure before any code is written.

Task: structure it from the hierarchy chart

The starter drives a square and a triangle with every move typed out, then plays three notes. Restructure it to match the hierarchy chart above, with no global variables:

  • side(length) drives forward length cm.
  • corner(sides) turns right by the angle for a regular polygon with sides sides: a full turn, 360 degrees, divided by sides. Work it out; do not type 90 or 120.
  • polygon(sides, length) repeats side then corner once for each side, then prints polygon <sides> done.
  • fanfare() plays the notes 523, 659 and 784 Hz for 0.15 seconds each.

The main program calls polygon(4, 20), then polygon(3, 20), then fanfare(), and nothing else.

# the two lines every program starts with: the commands, then the robot
from bugbot import *
connect()

forward(60, distance=20)
turn_right(30, angle=90)
forward(60, distance=20)
turn_right(30, angle=90)
forward(60, distance=20)
turn_right(30, angle=90)
forward(60, distance=20)
turn_right(30, angle=90)
print("polygon 4 done")
forward(60, distance=20)
turn_right(30, angle=120)
forward(60, distance=20)
turn_right(30, angle=120)
forward(60, distance=20)
turn_right(30, angle=120)
print("polygon 3 done")
tone(523, 0.15)
tone(659, 0.15)
tone(784, 0.15)

Challenges

  1. Add a star(points, length) subroutine to the chart and the code. Which existing boxes does it call?
  2. Write the shapes program in AQA pseudo-code, with one SUBROUTINE for each box.
  3. Pick a program from earlier in the module and draw its hierarchy chart. Does any box call a subroutine that also appears under a different box?