Programming paradigms and procedural programming
Procedural, object-oriented, declarative and low-level paradigms, the structured approach, and hierarchy charts.
Do this lesson in the simulatorEverything 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))
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
GOTOof 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.
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 forwardlengthcm.corner(sides)turns right by the angle for a regular polygon withsidessides: a full turn, 360 degrees, divided bysides. Work it out; do not type 90 or 120.polygon(sides, length)repeatssidethencorneronce for each side, then printspolygon <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
- Add a
star(points, length)subroutine to the chart and the code. Which existing boxes does it call? - Write the shapes program in AQA pseudo-code, with one
SUBROUTINEfor each box. - 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?