Design

1
Why should we design?
You don’t have to.

Some people learn best from experience.

2
How do we design
programs?

3
Working at a distance
Imagine that you are fixing something that is high up—maybe on the roof of
a building.

Your tools and items are all on the ground; they are too heavy to carry up.

Fortunately, you have a helper who can pass things to you if you ask for them!

4
Working at a distance
Give me a Thanks, I’ll tell you if I
hammer, please. need anything else.

1 Ask for item /

2
get item
Work with it 🎉! done!

3a
3b if another item is needed
5
Working at a distance
Give me a
No, I said a hammer.
hammer, please.

if wrong item, ask for another

1 Ask for item /

2
get item
Work with it 🎉! done!

3a
3b if another item is needed
6
Working at a distance
● (1) The worker requests things based on what work they’re doing right now.
○ If they get given the wrong item, they don’t use it! They ignore it and ask for the right item.
● (2) They can do work in any order, as long as it gets done. (Some work, obviously, might depend on
other work being completed first!)
● (3a) If the work is done, it’s done 😇 … everyone is happy.
● (3b) If the work isn’t complete yet, and another item is needed, go to (1).

if wrong item, ask for another

1 Ask for item /

2
get item
Work with it 🎉! done!

3a
3b if another item is needed
7
Fundamental program design
Give me an Thanks, I’ll tell you if I
31337
integer, please. need anything else.

1 Output / input
2
function
💯Pure done!
Computation🎉!
3a
3b if more input is needed
8
Fundamental program design
“Output/input function”:
● Combination of output function (show the user something) & input function (get user response).
● ⚠ NOT PURE! ⚠: The only impure part of the system.
○ Could make use of other (pure or impure) functions.
● Needs to know what is needed, so that the correct input can be requested.
○ Domain: a value that is the basis of the output. PROBABLY a product type.
○ Codomain: a value based on the input. PROBABLY a sum type. NEVER the direct input.

1 Output / input
2
function
💯Pure done!
Computation🎉!
3a
3b if more input is needed
9
Fundamental program design
Give me an yolo.wut No, I said an integer.
integer, please.

if bad input, ask for another

1 Output / input
2
function
💯Pure done!
Computation🎉!
3a
3b if more input is needed
10
Fundamental program design
💡 Fundamental idea: all values entering the program are checked.

● Separate & isolate side-effects and non-determinism.

○ If an “error” can occur, it will occur here! Keep this code as small as possible.
○ If input is incorrect/invalid/etc, recurse and try again.
○ Values received from the “output / input function” are handled by pure computation.
○ Values sent to “output / input function” are immutable.

if bad input, ask for another

1 Output / input
2
function
💯Pure done!
Computation🎉!
3a
3b if more input is needed
11
Fundamental program design
“💯 Pure Computation 🎉”:
● Uses a domain-specific language designed for the problem.
● Domain-specific language: “a computer programming language of limited expressiveness
focussed on a particular domain” (Fowler, 2011)
● Majority of the effort is spent making the language. Minority is spent solving the problem.

if bad input, ask for another

1 Output / input
2
function
💯Pure done!
Computation🎉!
3a
3b if more input is needed
12
Making a Domain-Specific
Language

13
Domain-specific languages
“a computer programming language of limited expressiveness focussed on a particular domain”

You already know at least one domain-specific language—if you did CS1 at Rhodes.
● Turtles in Python:
○ alex.left(45)
○ tess.forward(10)
● Others that you might know:
○ Regular expressions
○ SQL (only useful for database operations!)
○ HTML
○ CSS
○ Groovy language (as used in Gradle’s build files)

14
Importance of limited expressiveness
Ingredients Go to the store for some butter, bring it home. It’s
● 500g butter
okay if it melts a bit. You’ll also need some
● 12 tbs castor sugar condensed milk so don’t forget that. And castor
● 4½ cups plain flour sugar. Put the sugar and butter in a bowl (you’ll need
● 1 tin (400g) condensed milk
a bowl, do you have one?) and then mix them with
Method some milk added afterwards. If you have more
people, add more ingredients. Make sure you got
● Cream butter and sugar, add condensed milk,
then slowly add flour. flour from the store, because you need about 4-5
● Mix well. cups of that, just add it now to the mix. Bake it all at
● Shape mixture into balls, flatten slightly with a a high heat in little flattened balls until it’s brown.
fork and place onto a greased tray.
● Bake at 180°C for approx. 10 minutes until
browned.

15
Domain-specific languages
“a computer programming language of limited expressiveness focussed on a particular domain”

Fundamental idea: if we have a limited, restricted language that can do one thing very well, then:

● Make sure that everything that needs to be said, is actually said

● Mistakes are more difficult, because the language cannot express (some) “wrong” ideas
● It’s easier to program correctly, because you are using the concepts of the problem domain

16
Domain-specific languages
“a computer programming language of limited expressiveness focussed on a particular domain”

Fundamental idea: if we have a limited, restricted language that can do one thing very well, then:

● Make sure that everything that needs to be said, is actually said

○ e.g. “Ingredients” & “Methods” sections, ingredient quantities, baking temperature
● Mistakes are more difficult, because (as far as possible) only valid ideas are representable.
○ Nothing about going to the store or people coming over
● It’s easier to program correctly, because you are using the concepts of the problem domain
○ “Cream █ and █ , add █ , then slowly add █ . Mix well. Shape █ into █ , flatten slightly with █ and place onto
█ . Bake at █ °C for █ until █ .”
○ Even if I have never baked biscuits in my life, as long as I know the concepts (in bold above), I can do it!

17
Domain-specific languages
“a computer programming language of limited expressiveness focussed on a particular domain”

Three approaches:

1. “External”: implement a completely new language and create the necessary tools for it
○ Syntax & semantics are completely up to you
○ Learning new syntax & semantics might be tough!
○ A lot of work! Needs a parser, lexer, translator, …
○ All of this is covered in the Translators course
2. “Internal”: implement a limited embedded language within a host language
○ Syntax & semantics have to follow the conventions of the host language
○ If you know the host language, then there’s no extra syntax to learn
○ Much less work than the “external” approach
3. “Fragmentary”: extending a language with extra syntax
○ e.g. JSX extensions

18
Domain-specific languages
“a computer programming language of limited expressiveness focussed on a particular domain”

Three approaches:

1. “External”: implement a completely new language and create the necessary tools for it ❌
○ Syntax & semantics are completely up to you
○ Learning new syntax & semantics might be tough!
○ A lot of work! Needs a parser, lexer, translator, …
○ You have already done this in the Translators course!
2. “Internal”: implement a limited embedded language within a host language ✅
○ Syntax & semantics have to follow the conventions of the host language
○ If you know the host language, then there’s no extra syntax to learn
○ Much less work than the “external” approach
3. “Fragmentary”: extending a language with extra syntax ❌
○ You’ve seen this in a React-focused practical

19
Deep and Shallow
Embeddings

20
Moving house
Cain and Abel’s landlord has sold the house that they live in, and they are both being forced to move out.

Fortunately, they have found a great new place that they’ll move to, they have enough boxes, and now
they’re both ready to move.

However, they can’t decide on the best way to move, and they’ve come to YOU for advice.

Cain says: “We should just take items from wherever, put them into boxes, load the boxes into the truck, and
make as many trips as necessary to get it done. When our current house is empty, we’re done!”

Abel says: “We should make a list of items, then pack them carefully into the right labelled boxes, then load
the truck and make one trip.”

Are you ready to advise them?

21
“Why should I agree with you?”
Cain’s Idea Abel’s Idea

● It’s faster! Grab what you can, throw it ● Having a list makes it possible to
in. Writing a list takes time & ○ …optimise the packing by
resources. leaving some things out,
● We only need to move once, so it combining similar things in a
doesn’t matter how we do it. box, etc.
○ …get someone else to do the
packing.
● With a list, we can pack more quickly
and accurately
● If we move house again, we’ll be glad
we had the list.
● We might be able to use the list for
other things, e.g. unpacking 22
Making programs
Bob and Dora are making a program.

However, they can’t decide on the best way to design it, and they’ve come to YOU for advice.

Bob says: “We should just write the functions we need and when we’ve written them all, we’re done!”

Dora says: “We should list all the things that we need to do, and then structure the program as something
that just evaluates the list of things that are requested.”

Are you ready to advise them?

23
Making programs
Bob and Dora are making a program.

However, they can’t decide on the best way to design it, and they’ve come to YOU for advice.

Bob says: “We should just write the functions we need and when we’ve written them all, we’re done!”

Dora says: “We should list all the things that we need to do, and then structure the program as something
that just evaluates the list of things that are requested.”

Are you ready to advise them?

24
“Deep” vs “Shallow” internal languages
There are two ways to do an “internal” language: deep and shallow.

● Deep: use an abstract syntax tree (AST) to represent instructions/ideas in the problem domain. Then
evaluate it.
● Shallow: represent instructions/ideas in the problem domain directly as functions.

25
“Deep” internal language
Deep: write down what to do, in the language of the problem domain. Then do it.

You have a Write down Do what is

problem! what should be written down
done to solve
the problem

Advantages:

● Between the “writing down” and the “doing the work” steps, you might be able to optimise the work.
● Once you have it written down, you can save it to do later, duplicate it, give it to someone else, etc.
● Very neat way to separate “problem domain” from “execution”.
26
“Deep” internal language
Deep: write down what to do, in the language of the problem domain. Then do it.

You have a Write down Do what is

problem! what should be written down
done to solve
the problem

Disadvantages:

● Extra work: instead of just doing it, you are writing it down first. Takes extra time & space.

27
“Deep” internal language
Deep: use an abstract syntax tree to represent instructions/ideas in the problem domain. Then evaluate that
data.

You have a Represent problem Evaluate ADT

problem! using an ADT

Advantages:

● Between the “representing” and the “evaluating” steps, you might be able to optimise the work.
● Once you have it as data, you can save it to do later, duplicate it, run it somewhere else, etc.
● Very neat way to separate “problem domain” from “execution”

Disadvantages:

● Extra work: instead of just doing it, you represent it as data first. Takes extra time & space.

28
“Deep” internal language
Deep: use an abstract syntax tree to represent instructions/ideas in the problem domain. Then evaluate that
data.

You have a Represent problem Evaluate ADT

problem! using an ADT
Implementation:

1. Create Algebraic Data Types to represent:

a. problem domain
b. actions taken with regard to the problem domain
2. Create one “evaluation” function which accepts (1a) and (1b)
a. Helper functions to change the form of an ADT can also exist
b. Helper functions for complex evaluations can also exist

Solving the problem means: accepting (1b) from the user, and evaluating (2), possibly repeatedly.
29
“Shallow” internal language
Shallow: solve the problem, using the tools of the problem domain.

You have a Solve the problem, using tools

problem! from the problem domain

Advantages:

● Simple and direct

30
“Shallow” internal language
Shallow: solve the problem, using the tools of the problem domain.

You have a Solve the problem, using tools

problem! from the problem domain

Disadvantages:

● Few opportunities for optimisation

● Greater possibility of creating a poor solution
○ e.g. if moving boxes from one house to another,
■ Moving boxes one at a time instead of moving many boxes at once
■ Stacking boxes poorly so that needed boxes are at the back of the room
31
“Shallow” internal language
Shallow: represent instructions/ideas in the problem domain directly as functions.

You have a Solve the problem, using tools

Advantages: problem! from the problem domain

● Simple and direct: create functions that implement the functionality

Disadvantages:

● Few opportunities for optimisation

● Greater possibility of introducing accidental complexity as you work!
○ Essential complexity: complexity that exists because of the problem domain
○ Accidental complexity: complexity that exists because of the solution

32