In this talk we looked at some of the interesting ideas from a number of fringe languages - F#'s type providers, Clojure's macros, Erlang's actor model, Idris's dependent types, Rust's borrow pointers, Go's interfaces and Elm's signals.
12. Being literate isn't simply a matter of being
able to put words on the page, it's solidifying
our thoughts such that they can be written.
Interpreting and applying someone else's
thoughts is the equivalent for reading. We call
these composition and comprehension.
And they are what literacy really is.
- Chris Granger
13. Coding, like writing, is a mechanical act…
Just like writing, we have to know how to solidify
our thoughts and get them out of our head…!
We build mental models of everything… If we
want computers to be able to compute for us,
then we have to accurately extract these
models from our heads and record them.
- Chris Granger
16. “One of the most disastrous
thing we can learn is the first
programming language, even
if it's a good programming
language.”
- Alan Kay
17. “Just as there are odours that dogs can smell and
we cannot, as well as sounds that dogs can hear
and we cannot, so too there are wavelengths of light
we cannot see and flavours we cannot taste. Why
then, given our brains wired the way they are, does
the remark "Perhaps there are thoughts we cannot
think," surprise you? Evolution, so far, may possibly
have blocked us from being able to think in some
directions; there could be unthinkable thoughts.”
- Richard Hamming
18. “Just as there are odours that dogs can smell and
we cannot, as well as sounds that dogs can hear
and we cannot, so too there are wavelengths of light
we cannot see and flavours we cannot taste. Why
then, given our brains wired the way they are, does
the remark "Perhaps there are thoughts we cannot
think," surprise you? Evolution, so far, may possibly
have blocked us from being able to think in some
directions; there could be unthinkable thoughts.”
- Richard Hamming
23. “The limits of my
language means the
limits of my world.”
- Ludwig Wittgenstein
25. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
40. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
41. “…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)
42. 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
43. 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
44. how we read CODE
public void DoSomething(int x, int y)!
{!
Foo(y,!
Bar(x,!
Zoo(Monkey())));!
}
see also http://bit.ly/1KN8cd0
45. 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
46. 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
47. “…a clean design is one that
supports visual thinking so
people can meet their
informational needs with a
minimum of conscious effort.”
49. 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
50. 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
51. let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
52. let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
53. let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
54. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
73. let inline sayQuack (duck : ^a) =
(^a : (member Quack : unit -> unit) duck)
see also http://bit.ly/1H2fN9i
74. let inline sayQuack (duck : ^a) =
(^a : (member Quack : unit -> unit) duck)
see also http://bit.ly/1H2fN9i
75. let inline sayQuack (duck : ^a) =
(^a : (member Quack : unit -> unit) duck)
see also http://bit.ly/1H2fN9i
76. let inline sayQuack (duck : ^a) =
(^a : (member Quack : unit -> unit) duck)
see also http://bit.ly/1H2fN9i
77. type Duck () =
member __.Quack() =
printfn “quack quack!”
!
let duck = Duck()
sayQuack duck
!
> quack quack!
see also http://bit.ly/1H2fN9i
78. type Bird () =
member __.Quack() =
printfn “tweet tweet!”
!
let bird = Bird()
sayQuack bird
!
> tweet tweet!
see also http://bit.ly/1H2fN9i
79. type Dog () =
member __.Bark() =
printfn “woof woof!”
!
let dog = Dog()
sayQuack dog
!
error FS0001: The type ‘Dog’ does not
support the operator ‘Quack’
see also http://bit.ly/1H2fN9i
91. type Dog struct { }
func (d Dog) Bark()
{
fmt.Println(“woof woof!”)
}
see also http://bit.ly/1ER5zVs
92. 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
99. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
100. 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…
134. 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
137. // take ownership
let v = vec![1, 2, 3];
!
// moved ownership to v2
let v2 = v;
see also http://bit.ly/1F6WBVD
138. // 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
139. fn take(v : Vec<i32>) {
// ownership of vector transferred
// to v in this scope
}
see also http://bit.ly/1F6WBVD
140. // take ownership
let v = vec![1, 2, 3];
!
// moved ownership
take(v);
see also http://bit.ly/1F6WBVD
141. // 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
149. // 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
150. // 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
157. 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
158. 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
162. 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.
163. 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
164. 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
165. 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
187. private var arrowKeyUp:Bool;
private var arrowKeyDown:Bool;
!
private var platform1:Platform;
private var platform2:Platform;
private var ball:Ball;
199. 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
200. 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
201. 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
203. 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
204. 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
205. 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
206. 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
207. “I thought of objects being like
biological cells and/or
individual computers on a
network, only able to
communicate with messages.”
- Alan Kay
208. “OOP to me means only
messaging, local retention and
protection and hiding of state-
process, and extreme late-
binding of all things.”
- Alan Kay
210. Borrowed Pointers
Actor Model
Bit Syntax
Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Dependent Types
Uniqueness Types
Signals
Macros
Unit-of-Measure
234. 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
281. Enterprise Tic-Tac-Toe -
a Functional Approach
Type Driven Development
Computation expression in context :
a history of the otter king
Learning From Haskell
282. “Learning is an act of creation
itself, because something
happens in you that wasn't
there before.”
- Alan Kay