SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
28.
“…a clean design is one that
supports visual thinking so
people can meet their
informational needs with a
minimum of conscious effort.”
- Daniel Higginbotham
(www.visualmess.com)
29.
Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage
problem using a message passing approach. Naturally, I wanted to answer that question with Erlang!!
!
Let’s first dissect the problem and decide what processes we need and how they need to interact with
one another.!
!
The stable marriage problem is commonly stated as:!
Given n men and n women, where each person has ranked all members of the opposite sex with a
unique number between 1 and n in order of preference, marry the men and women together such that
there are no two people of opposite sex who would both rather have each other than their current
partners. If there are no such people, all the marriages are “stable”. (It is assumed that the participants
are binary gendered and that marriages are not same-sex).!
From the problem description, we can see that we need:!
* a module for man!
* a module for woman!
* a module for orchestrating the experiment!
In terms of interaction between the different modules, I imagined something along the lines of…
how we read ENGLISH
see also http://bit.ly/1KN8cd0
30.
Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage
problem using a message passing approach. Naturally, I wanted to answer that question with Erlang!!
!
Let’s first dissect the problem and decide what processes we need and how they need to interact with
one another.!
!
The stable marriage problem is commonly stated as:!
Given n men and n women, where each person has ranked all members of the opposite sex with a
unique number between 1 and n in order of preference, marry the men and women together such that
there are no two people of opposite sex who would both rather have each other than their current
partners. If there are no such people, all the marriages are “stable”. (It is assumed that the participants
are binary gendered and that marriages are not same-sex).!
From the problem description, we can see that we need:!
* a module for man!
* a module for woman!
* a module for orchestrating the experiment!
In terms of interaction between the different modules, I imagined something along the lines of…
2.top-to-bottom
1.left-to-right
how we read ENGLISH
see also http://bit.ly/1KN8cd0
31.
how we read CODE
public void DoSomething(int x, int y)!
{!
Foo(y,!
Bar(x,!
Zoo(Monkey())));!
}
see also http://bit.ly/1KN8cd0
32.
how we read CODE
public void DoSomething(int x, int y)!
{!
Foo(y,!
Bar(x,!
Zoo(Monkey())));!
}
2.bottom-to-top
1.right-to-left
see also http://bit.ly/1KN8cd0
33.
Whilst talking with an ex-colleague, a question came up on
how to implement the Stable Marriage problem using a
message passing approach. Naturally, I wanted to answer
that question with Erlang!!
!
Let’s first dissect the problem and decide what processes we
need and how they need to interact with one another.!
!
The stable marriage problem is commonly stated as:!
Given n men and n women, where each person has ranked
all members of the opposite sex with a unique number
between 1 and n in order of preference, marry the men and
women together such that there are no two people of
opposite sex who would both rather have each other than
their current partners. If there are no such people, all the
marriages are “stable”. (It is assumed that the participants
are binary gendered and that marriages are not same-sex).!
From the problem description, we can see that we need:!
* a module for man!
* a module for woman!
* a module for orchestrating the experiment!
In terms of interaction between the different modules, I
imagined something along the lines of…
2.top-to-bottom
1.left-to-right
how we read ENGLISH
public void DoSomething(int x, int y)!
{!
Foo(y,!
Bar(x,!
Zoo(Monkey())));!
}
2.top-to-bottom
1.right-to-left
how we read CODE
see also http://bit.ly/1KN8cd0
34.
“…a clean design is one that
supports visual thinking so
people can meet their
informational needs with a
minimum of conscious effort.”
36.
how we read CODE
let drawCircle x y radius =
radius |> circle
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
37.
how we read CODE
let drawCircle x y radius =
radius |> circle
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
2.top-to-bottom
1.left-to-right
see also http://bit.ly/1KN8cd0
38.
let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
39.
let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
40.
let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
41.
NASA orbiter crashed
because one engineer
accidentally used miles
instead of kilometres
66.
type Dog struct { }
func (d Dog) Bark()
{
fmt.Println(“woof woof!”)
}
see also http://bit.ly/1ER5zVs
67.
func main() {
dog := Dog{}
sayQuack(dog)
}
main.go:40: cannot use dog (type Dog) as type
Duck in argument to sayQuack:!
! Dog does not implement Duck (missing
Quack method)
see also http://bit.ly/1ER5zVs
68.
patterns are observed
after the fact
see also http://bit.ly/1ER5zVs
69.
system building is also
a process of learning
and discovery
see also http://bit.ly/1ER5zVs
70.
implementation
package
interface package
see also http://bit.ly/1ER5zVs
71.
encourages precise
interface definitions
see also http://bit.ly/1ER5zVs
73.
Homoiconicity
…homoiconicity is a property of some
programming languages in which the program
structure is similar to its syntax, and therefore
the program’s internal representation can be
inferred by reading the text’s layout…
104.
memory safety
without GC
see also http://bit.ly/1F6WBVD
105.
ZERO
runtime cost
see also http://bit.ly/1F6WBVD
106.
safety + speed
see also http://bit.ly/1F6WBVD
107.
fn foo() {
// v has ownership of the vector
let v = vec![1, 2, 3];
// mutable binding
let mut v2 = vec![];
}
// vector is deallocated at the
// end of scope,
// this happens deterministically
see also http://bit.ly/1F6WBVD
108.
immutable by default
see also http://bit.ly/1F6WBVD
109.
// take ownership
let v = vec![1, 2, 3];
see also http://bit.ly/1F6WBVD
110.
// take ownership
let v = vec![1, 2, 3];
!
// moved ownership to v2
let v2 = v;
see also http://bit.ly/1F6WBVD
111.
// take ownership
let v = vec![1, 2, 3];
!
// moved ownership to v2
let v2 = v;
!
println!("v[0] is {}", v[0]);
// error: use of moved value: `v`
// println!("v[0] is {}", v[0]);
// ^
see also http://bit.ly/1F6WBVD
112.
fn take(v : Vec<i32>) {
// ownership of vector transferred
// to v in this scope
}
see also http://bit.ly/1F6WBVD
113.
// take ownership
let v = vec![1, 2, 3];
!
// moved ownership
take(v);
see also http://bit.ly/1F6WBVD
114.
// take ownership
let v = vec![1, 2, 3];
!
// moved ownership
take(v);
!
println!("v[0] is {}", v[0]);
// error: use of moved value: `v`
// println!("v[0] is {}", v[0]);
// ^
see also http://bit.ly/1F6WBVD
122.
// note we're taking a reference,
// &Vec<i32>, instead of Vec<i32>
fn take(v : &Vec<i32>) {
// no need to deallocate the vector
// after we go out of scope here
}
see also http://bit.ly/1F6WBVD
123.
// take ownership
let v = vec![1, 2, 3];
!
// notice we're passing a reference,
// &v, instead of v
take(&v); // borrow ownership
!
println!("v[0] is {}", v[0]);
// v[0] is 1
see also http://bit.ly/1F6WBVD
124.
see also http://bit.ly/1F6WBVD
let me
borrow your
book
129.
see also http://bit.ly/1F6WBVD
immutable by default
130.
fn take(v : &Vec<i32>) {
v.push(5);
}
!
let v = vec![];
take(&v);
// cannot borrow immutable borrowed
// content `*v` as mutable
// v.push(5);
// ^
see also http://bit.ly/1F6WBVD
131.
fn take(v : &mut Vec<i32>) {
v.push(5);
}
!
let mut v = vec![];
take(&mut v);
!
println!("v[0] is {}", v[0]);
// v[0] is 5
see also http://bit.ly/1F6WBVD
132.
borrowing
rules
see also http://bit.ly/1F6WBVD
133.
see also http://bit.ly/1F6WBVD
Rule 1.!
!
the borrower’s scope must not
outlast the owner
134.
see also http://bit.ly/1F6WBVD
Rule 2.!
!
one of the following, but not both:!
2.1 0 or more refs to a resource!
2.2 exactly 1 mutable ref
135.
see also http://bit.ly/1F6WBVD
data race
There is a ‘data race’ when two or more pointers
access the same memory location at the same
time, where at least one of them is writing, and
the operations are not synchronised.
136.
see also http://bit.ly/1F6WBVD
data race
a. two or more pointers to the same resource!
b. at least one is writing!
c. operations are not synchronised
137.
see also http://bit.ly/1F6WBVD
Data Race Conditions!
a. two or more pointers to the same resource!
b. at least one is writing!
c. operations are not synchronised
Borrowing Rules!
one of the following, but not both:!
! 2.1 0 or more refs to a resource!
! 2.2 exactly 1 mutable ref
138.
see also http://bit.ly/1F6WBVD
Data Race Conditions!
a. two or more pointers to the same resource!
b. at least one is writing!
c. operations are not synchronised
Borrowing Rules!
one of the following, but not both:!
! 2.1 0 or more refs to a resource!
! 2.2 exactly 1 mutable ref
158.
private var arrowKeyUp:Bool;
private var arrowKeyDown:Bool;
!
private var platform1:Platform;
private var platform2:Platform;
private var ball:Ball;
159.
function keyDown(event:KeyboardEvent):Void
{
if (currentGameState == Paused &&
event.keyCode == 32) {
setGameState(Playing);
} else if (event.keyCode == 38) {
! ! arrowKeyUp = true;!
}else if (event.keyCode == 40) {
! ! arrowKeyDown = true;!
}
}
160.
function keyUp(event:KeyboardEvent):Void {
if (event.keyCode == 38) {
! ! arrowKeyUp = false;!
} else if (event.keyCode == 40) {
! ! arrowKeyDown = false;!
}
}
161.
function everyFrame(event:Event):Void {
if(currentGameState == Playing){
if (arrowKeyUp) {
platform1.y -= platformSpeed;
}
if (arrowKeyDown) {
platform1.y += platformSpeed;
}
if (platform1.y < 5)
platform1.y = 5;
if (platform1.y > 395)
platform1.y = 395;
}
}
162.
function everyFrame(event:Event):Void {
if(currentGameState == Playing){
if (arrowKeyUp) {
platform1.y -= platformSpeed;
}
if (arrowKeyDown) {
platform1.y += platformSpeed;
}
if (platform1.y < 5) !
! ! ! platform1.y = 5;!
! ! if (platform1.y > 395) !
! ! ! platform1.y = 395;!
}
}
170.
type alias Platform = {x:Int, y:Int}
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
171.
type alias Platform = {x:Int, y:Int}!
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
172.
type alias Platform = {x:Int, y:Int}
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
173.
Keyboard.arrows
UP { x=0, y=1 }
DOWN { x=0, y=-1 }
LEFT { x=-1, y=0 }
RIGHT { x=1, y=0 }
174.
type alias Platform = {x:Int, y:Int}
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform!
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
175.
type alias Platform = {x:Int, y:Int}
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
176.
type alias Platform = {x:Int, y:Int}
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
177.
type alias Platform = {x:Int, y:Int}
defaultPlatform = {x=5, y=0}
!
delta = Time.fps 20
input = Signal.sampleOn delta Keyboard.arrows
!
cap x = max 5 <| min x 395
!
p1 : Signal Platform
p1 = foldp ({x, y} s -> {s | y <- cap <| s.y + 5*y})
defaultPlatform
input
179.
“I thought of objects being like
biological cells and/or
individual computers on a
network, only able to
communicate with messages.”
- Alan Kay
180.
“OOP to me means only
messaging, local retention and
protection and hiding of state-
process, and extreme late-
binding of all things.”
- Alan Kay
203.
Network is reliable!
Latency is zero!
Bandwidth is infinite!
Network is secure!
Topology doesn't change!
There is one administrator!
Transport cost is zero!
The network is homogeneous
8 fallacies of distributed computing