Procedural Programming: It’s Back? It Never Went Away

Procedural Programming
It's Back? It Never Went Away
@KevlinHenney

This is the Unix philosophy:
Write programs that do one
thing and do it well.Write
programs to work together.
Doug McIlroy

In McIlroy's summary, the hard
part is his second sentence:
Write programs to work
together.
John D Cook

In the long run every
program becomes rococo
— then rubble.
Alan Perlis

I began to use the term “software
engineering” to distinguish it from
hardware and other kinds of engineering;
yet, treat each type of engineering as part of
the overall systems engineering process.
Margaret Hamilton

Define a subset of the system which is
small enough to bring to an operational
state [...] then build on that subsystem.
E E David

This strategy requires that the system
be designed in modules which can be
realized, tested, and modified
independently, apart from conventions
for intermodule communication.
E E David

The design process
is an iterative one.
Andy Kinslow

There are two classes of system designers.
The first, if given five problems will solve
them one at a time.
Andy Kinslow

The second will come back and announce
that these aren’t the real problems, and
will eventually propose a solution to the
single problem which underlies the
original five.
Andy Kinslow

This is the ‘system type’ who is great
during the initial stages of a design project.
However, you had better get rid of him
after the first six months if you want to get
a working system.
Andy Kinslow

A software system can best be
designed if the testing is interlaced
with the designing instead of
being used after the design.
Alan Perlis

proc is leap year = (int year) bool:
skip;

false;
[] proposition leap year spec =
(
("Years not divisible by 4 are not leap years",
void: (assert (not is leap year (1967))))
);

mode proposition = struct (string name, proc void test);

false;
(
);
test (leap year spec)

mode proposition = struct (string name, proc void test);
proc test = ([] proposition spec) void:
for entry from lwb spec to upb spec
do
print (name of spec [entry]);
test of spec [entry];
print (new line)
od;

year mod 4 = 0;
(
void: (assert (not is leap year (1967)))),
("Years divisible by 4 but not by 100 are leap years",
void: (assert (is leap year (1968))))
);

year mod 4 = 0 and year mod 100 /= 0;
(
void: (assert (is leap year (1968)))),
("Years divisible by 100 but not by 400 are not leap years",
);

year mod 4 = 0 and year mod 100 /= 0 or year mod 400 = 0;
(
void: (assert (is leap year (1968)))),
("Years divisible by 400 are leap years",
void: (assert (is leap year (2000))))
);

year mod 4 = 0 and year mod 100 /= 0 or year mod 400 = 0;
(
with (2018, 2001, 1967, 1), expect (false)),
with (2016, 1984, 1968, 4), expect (true)),
with (2100, 1900, 100), expect (false)),
("Years divisible by 400 are leap years",
with (2000, 1600, 400), expect (true))
);
test (is leap year, leap year spec)

mode expect = bool;
mode with = flex [1:0] int;
mode proposition = struct (string name, with inputs, expect result);

proc test = (proc (int) bool function, [] proposition spec) void:
do
string report := "", separator := " failed for ";
[] int inputs = inputs of spec [entry];
for value from lwb inputs to upb inputs
do
if
bool expected = result of spec [entry];
function (inputs [value]) /= expected
then
report +:= separator + whole(inputs[value], 0);
separator := " "
fi
od;
print (if report = "" then (new line) else (new line, report, new line) fi)
od;

proc test = (proc (int) bool function, [] proposition spec) void:
do
string report := "", separator := " failed for ";
[] int inputs = inputs of spec [entry];
for value from lwb inputs to upb inputs
do
if
bool expected = result of spec [entry];
function (inputs [value]) /= expected
then
report +:= separator + whole(inputs[value], 0);
separator := " "
fi
od;
print ((report = "" | (new line) | (new line, report, new line)))
od;

We instituted a rigorous regression
test for all of the features of AWK.
Any of the three of us who put in a
new feature into the language [...],
first had to write a test for the new
feature.
Alfred Aho
http://www.computerworld.com.au/article/216844/a-z_programming_languages_awk/

There is no such question as testing things after the
fact with simulation models, but that in effect the
testing and the replacement of simulations with
modules that are deeper and more detailed goes on
with the simulation model controlling, as it were,
the place and order in which these things are done.
Alan Perlis

As design work progresses this
simulation will gradually evolve
into the real system.
The simulation is the design.
Tad B Pinkerton

snowclone, noun
▪ clichéd wording used as a template, typically
originating in a single quote
▪ e.g., "X considered harmful", "These aren't
the Xs you're looking for", "X is the new Y",
"It's X, but not as we know it", "No X left
behind", "It's Xs all the way down", "All your
X are belong to us"

FUNCTION ISLEAP(YEAR)
LOGICAL ISLEAP
INTEGER YEAR
IF (MOD(YEAR, 400) .EQ. 0) GOTO 20
10 ISLEAP = .FALSE.
RETURN
20 ISLEAP = .TRUE.
END

LOGICAL ISLEAP
INTEGER YEAR
10 ISLEAP = .FALSE.
RETURN
20 ISLEAP = .TRUE.
RETURN
END

LOGICAL ISLEAP
INTEGER YEAR
10 ISLEAP = .FALSE.
GOTO 30
20 ISLEAP = .TRUE.
30 RETURN
END

LOGICAL ISLEAP
INTEGER YEAR
10 ISLEAP = .FALSE.
GOTO 30
20 ISLEAP = .TRUE.
GOTO 30
30 RETURN
END

LOGICAL ISLEAP
INTEGER YEAR
10 ISLEAP = .FALSE.
GOTO 30
20 ISLEAP = .TRUE.
GOTO 30
30 CONTINUE
RETURN
END

FUNCTION ISLEAP(Year)
LOGICAL ISLEAP
INTEGER YEAR
IF (MOD(YEAR, 400) .EQ. 0) THEN
ISLEAP = .TRUE.
ELSE IF (MOD(YEAR, 100) .EQ. 0) THEN
ISLEAP = .FALSE.
ELSE IF (MOD(YEAR, 4) .EQ. 0) THEN
ISLEAP = .TRUE.
ELSE
ISLEAP = .FALSE.
END IF
END

A goto completely
invalidates the high-level
structure of the code.
Taligent's Guide to Designing Programs

send(to, from, count)
register short *to, *from;
register count;
{
register n=(count+7)/8;
switch(count%8){
case 0: do{ *to = *from++;
case 7: *to = *from++;
}while(--n>0);
}
}

register count;
{
switch(count%8){
}while(--n>0);
}
}
I feel a combination of
pride and revulsion at
this discovery.
Tom Duff

register count;
{
switch(count%8){
}while(--n>0);
}
}
Many people have said that the worst
feature of C is that switches don't break
automatically before each case label.
This code forms some sort of argument
in that debate, but I'm not sure whether
it's for or against.
Tom Duff

One of the most powerful
mechanisms for program
structuring [...] is the block
and procedure concept.
Ole-Johan Dahl and C A R Hoare
"Hierarchical Program Structures"

Main Program and Subroutine
The goal is to decompose a program into
smaller pieces to help achieve modifiability.
A program is decomposed hierarchically.
Len Bass, Paul Clements & Rick Kazman
Software Architecture in Practice

afferent branch transform branch efferent branch
main
subroutine subroutine
subroutine
subroutine
subroutine
subroutine
subroutine
subroutine

There is typically a single thread of control
and each component in the hierarchy gets
this control (optionally along with some
data) from its parent and passes it along
to its children.
Len Bass, Paul Clements & Rick Kazman
Software Architecture in Practice

main
procedure procedure
procedure
procedure
procedure
procedure
procedure
procedure

main
function function
function
function
function
function
function
function

You cannot teach beginners
top-down programming,
because they don't know
which end is up.
C A R Hoare

Everything should be built
top-down, except the first
time.
Alan Perlis

Hamlet: To be, or not to be,
that is the question.

Ophelia: 'Tis in my memory
locked, and you yourself
shall keep the key of it.

Hamlet: Yea, from the table
of my memory I'll wipe
away all trivial fond records.

begin
ref(Book) array books(1:capacity);
integer count;
procedure Push(top); ...
procedure Pop; ...
boolean procedure IsEmpty; ...
boolean procedure IsFull; ...
integer procedure Depth; ...
ref(Book) procedure Top; ...
count := 0
end;

A procedure which is capable of
giving rise to block instances which
survive its call will be known as a
class; and the instances will be
known as objects of that class.

class Stack(capacity);
integer capacity;
begin
ref(Book) array books(1:capacity);
integer count;
procedure Push(top); ...
procedure Pop; ...
boolean procedure IsEmpty; ...
boolean procedure IsFull; ...
integer procedure Depth; ...
ref(Book) procedure Top; ...
count := 0
end;

const newStack = () => {
const items = []
return {
depth: () => items.length,
top: () => items[0],
pop: () => { items.shift() },
push: newTop => { items.unshift(newTop) },
}
}

const newStack = () => {
const items = []
return {
top: () => items[items.length - 1],
pop: () => { items.pop() },
push: newTop => { items.push(newTop) },
}
}

Concatenation is an operation
defined between two classes A
and B, or a class A and a block C,
and results in the formation of a
new class or block.

Concatenation consists in a
merging of the attributes of both
components, and the composition
of their actions.

const stackable = base => {
const items = []
return Object.assign(base, {
top: () => items[items.length - 1],
pop: () => { items.pop() },
push: newTop => { items.push(newTop) },
})
}

const newStack = () => stackable({})

const clearable = base => {
clear: () => {
while (base.depth())
base.pop()
},
})
}

const newStack =
() => clearable(stackable({}))

const newStack =
() => compose(clearable, stackable)({})
const compose = (...funcs) =>
arg => funcs.reduceRight(
(composed, func) => func(composed), arg)

Concept Hierarchies
The construction principle involved is best
called abstraction; we concentrate on features
common to many phenomena, and we abstract
away features too far removed from the
conceptual level at which we are working.

A type hierarchy is composed of subtypes and
supertypes. The intuitive idea of a subtype is
one whose objects provide all the behavior of
objects of another type (the supertype) plus
something extra.
Barbara Liskov
"Data Abstraction and Hierarchy"

What is wanted here is something like the
following substitution property: If for each
object o1 of type S there is an object o2 of type
T such that for all programs P defined in terms
of T, the behavior of P is unchanged when o1 is
substituted for o2, then S is a subtype of T.
Barbara Liskov
"Data Abstraction and Hierarchy"

const nonDuplicateTop = base => {
const push = base.push
push: newTop => {
if (base.top() !== newTop)
push(newTop)
},
})
}

tests = {
...
'A non-empty stack becomes deeper by retaining a pushed item as its top':
() => {
const stack = newStack()
stack.push('ACCU')
stack.push('2018')
stack.push('2018')
assert(stack.depth() === 3)
assert(stack.top() === '2018')
},
...
}

const newStack =
() => compose(clearable, stackable)({})
tests = {
...
() => {
stack.push('ACCU')
stack.push('2018')
stack.push('2018')
},
...
}

const newStack =
() => compose(nonDuplicateTop, clearable, stackable)({})
tests = {
...
() => {
stack.push('ACCU')
stack.push('2018')
stack.push('2018')
},
...
}

Mutable
Immutable
Unshared Shared
Unshared mutable
data needs no
synchronisation
Unshared immutable
data needs no
synchronisation
Shared mutable
data needs
synchronisation
Shared immutable
data needs no
synchronisation

Mutable
Immutable
Unshared Shared
Unshared mutable
data needs no
synchronisation
Unshared immutable
data needs no
synchronisation
Shared mutable
data needs
synchronisation
Shared immutable
data needs no
synchronisation
The Synchronisation Quadrant

Procedural Comfort Zone
Mutable
Immutable
Unshared Shared
Unshared mutable
data needs no
synchronisation
Unshared immutable
data needs no
synchronisation
Shared mutable
data needs
synchronisation
Shared immutable
data needs no
synchronisation

Procedural Discomfort Zone
Mutable
Immutable
Unshared Shared
Unshared mutable
data needs no
synchronisation
Unshared immutable
data needs no
synchronisation
Shared mutable
data needs
synchronisation
Shared immutable
data needs no
synchronisation
Procedural Comfort Zone

Threads and locks —
they’re kind of a dead
end, right?
BretVictor
"The future of programming"

So, I think if [...] we’re still using
threads and locks, we should
just, like, pack up and go home,
’cause we’ve clearly failed as an
engineering field.
BretVictor
"The future of programming"

single-threaded activity
no shared mutable state
coordination

N
bounded
buffered
asynchronous

N =
unbounded
buffered
asynchronous
∞

N = 1
bounded
buffered
asynchronous
futurepromise

N = 0
bounded
unbuffered
synchronous

Toutes choses sont dites
déjà; mais comme
personne n'écoute, il faut
toujours recommencer.
André Gide

Everything has been said
before; but since nobody
listens, we must always
start again.
André Gide

Procedural Programming: It’s Back? It Never Went Away

More Related Content

What's hot (20)

Similar to Procedural Programming: It’s Back? It Never Went Away (20)

More from Kevlin Henney (20)

Recently uploaded (20)

Procedural Programming: It’s Back? It Never Went Away