There seems to be a new programming language every week, and for us busy developers we just don't have the time to keep up with them. But have you wondered what we might have missed out on whilst we're busy working in our language of choice?
Having spent time with numerous programming languages the past few years Yan have learnt something new from each.
In this talk, Yan will take us on a whirlwind tour of the interesting concepts and ideas he have encountered, from F#'s type providers, Rust's borrowed pointers, to Elm's signals and Idris's dependent types to name a few.
10. ZOOZU
VAPA
BOROU
DUMBU
dark shades of blue, red, green & purple
white & some shades of yellow
some shades of green & blue
other shades of green, red & brown
11.
12.
13. “The limits of my
language means the
limits of my world.”
- Ludwig Wittgenstein
34. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
35. “…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)
36. 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
37. 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
38. how we read CODE
public void DoSomething(int x, int y)
{
Foo(y,
Bar(x,
Zoo(Monkey())));
}
see also http://bit.ly/1KN8cd0
39. 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
40. 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
41. “…a clean design is one that
supports visual thinking so
people can meet their
informational needs with a
minimum of conscious effort.”
43. 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
44. 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
45. let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
46. let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
47. let drawCircle x y radius =
circle radius
|> filled (rgb 150 170 150)
|> alpha 0.5
|> move (x, y)
see also http://bit.ly/1KN8cd0
48. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
69. type Dog struct { }
func (d Dog) Bark()
{
fmt.Println(“woof woof!”)
}
see also http://bit.ly/1ER5zVs
70. 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
77. Type Provider Pipes
Statically Resolved TP
Implicit Interface
Implementation
Borrowed Pointers Dependent Types
Uniqueness Types
Bit Syntax
Signals
Macros
Unit-of-Measure
Actor Model
78. 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…
113. 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
116. // take ownership
let v = vec![1, 2, 3];
// moved ownership to v2
let v2 = v;
see also http://bit.ly/1F6WBVD
117. // 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
118. fn take(v : Vec<i32>) {
// ownership of vector transferred
// to v in this scope
}
see also http://bit.ly/1F6WBVD
119. // take ownership
let v = vec![1, 2, 3];
// moved ownership
take(v);
see also http://bit.ly/1F6WBVD
120. // 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
128. // 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
129. // 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
136. 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
137. 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
140. Rule 2.
one of the following, but not both:
2.1 0 or more refs to a resource
2.2 exactly 1 mutable ref
see also http://bit.ly/1F6WBVD
141. 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.
see also http://bit.ly/1F6WBVD
142. data race
a. two or more pointers to the same resource
b. at least one is writing
c. operations are not synchronised
see also http://bit.ly/1F6WBVD
143. 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
see also http://bit.ly/1F6WBVD
144. 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
see also http://bit.ly/1F6WBVD