Tour of language landscape

5,353 views

Published on

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.

Published in: Technology

Tour of language landscape

  1. 1. tour guide : Yan Cui @theburningmonk
  2. 2. Hi, my name is Yan Cui.
  3. 3. 1MILLION USERS ACTIVE DAILY
  4. 4. 250MILLION DAY PER REQUEST
  5. 5. 2MONTH TB P E R sec ops 25,000
  6. 6. agenda
  7. 7. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  8. 8. disclaimers
  9. 9. syntax! doesn’t matter
  10. 10. 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
  11. 11. 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
  12. 12. IDEAS matter
  13. 13. “Programming languages have a devious influence: they shape our thinking habits.” - Edsger W. Dijkstra
  14. 14. “One of the most disastrous thing we can learn is the first programming language, even if it's a good programming language.” - Alan Kay
  15. 15. “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
  16. 16. “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
  17. 17. “The limits of my language means the limits of my world.” - Ludwig Wittgenstein
  18. 18. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  19. 19. your app
  20. 20. your app CSVCSVCSV CSVCSVXML
  21. 21. your app CSVCSVCSV CSVCSVXML some service
  22. 22. your app CSVCSVCSV CSVCSVXML some service DB
  23. 23. 1. define DTO types! 2. I/O! 3. marshal data into DTO! 4. do useful work
  24. 24. 1. define DTO types! 2. I/O! 3. marshal data into DTO! 4. do useful work
  25. 25. compiler provideexternal data source typed info
  26. 26. type providers
  27. 27. intellisense! tooltips! …
  28. 28. compile time validation
  29. 29. no code generation
  30. 30. R FunScript Azure Amazon S3 CSVSQLite SQL Server WSDL WorldBank Regex ODATA IKVM Facebook Apiary XAMLFreebaseHadoop Oracle Minesweeper Don Syme Powershell JSON Fizzbuzz Mixin RSS Matlab Dates NorthPole XML Python
  31. 31. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  32. 32. “…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)
  33. 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… how we read ENGLISH see also http://bit.ly/1KN8cd0
  34. 34. 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
  35. 35. how we read CODE public void DoSomething(int x, int y)! {! Foo(y,! Bar(x,! Zoo(Monkey())));! } see also http://bit.ly/1KN8cd0
  36. 36. 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
  37. 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 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
  38. 38. “…a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort.”
  39. 39. |>
  40. 40. 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
  41. 41. 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
  42. 42. let drawCircle x y radius = circle radius |> filled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0
  43. 43. let drawCircle x y radius = circle radius |> filled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0
  44. 44. let drawCircle x y radius = circle radius |> filled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0
  45. 45. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  46. 46. NASA orbiter crashed because one engineer accidentally used miles instead of kilometres
  47. 47. you’re never too smart to make mistakes
  48. 48. unit-of-measure
  49. 49. [<Measure>]! type Pence e.g.! 42<Pence>! ! 153<Pence>! ! …
  50. 50. 10<Meter> / 2<Second> ! = 5<Meter/Second>! 10<Meter> * 2<Second> ! = 20<Meter Second> ! 10<Meter> + 10<Meter> ! = 20<Meter>! 10<Meter> * 10! ! ! = 100<Meter>! 10<Meter> * 10<Meter> ! = 100<Meter2>! 10<Meter> + 2<Second> ! // error! 10<Meter> + 2 ! ! ! // error
  51. 51. 10<Meter> / 2<Second> ! = 5<Meter/Second>! 10<Meter> * 2<Second> ! = 20<Meter Second> ! 10<Meter> + 10<Meter> ! = 20<Meter>! 10<Meter> * 10! ! ! = 100<Meter>! 10<Meter> * 10<Meter> ! = 100<Meter2>! 10<Meter> + 2<Second> ! // error! 10<Meter> + 2 ! ! ! // error
  52. 52. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  53. 53. Duck Typing If it looks like a duck and quacks like a duck, it's a duck
  54. 54. def say_quack(duck): duck.quack()
  55. 55. def say_quack(duck): duck.quack()
  56. 56. class Duck: def quack(self): print("quack quack!”)
  57. 57. class Duck: def quack(self): print("quack quack!”) ! duck = Duck() say_quack(duck) ! > quack quack!
  58. 58. class Bird: def quack(self): print(“tweet tweet!”)
  59. 59. class Bird: def quack(self): print(“tweet tweet!”) ! bird = Bird() say_quack(bird) ! > tweet tweet!
  60. 60. Convenience Safety
  61. 61. what if…
  62. 62. Convenience Safety see also http://bit.ly/1H2fN9i
  63. 63. statically resolved! type parameters
  64. 64. let inline sayQuack (duck : ^a) = (^a : (member Quack : unit -> unit) duck) see also http://bit.ly/1H2fN9i
  65. 65. let inline sayQuack (duck : ^a) = (^a : (member Quack : unit -> unit) duck) see also http://bit.ly/1H2fN9i
  66. 66. let inline sayQuack (duck : ^a) = (^a : (member Quack : unit -> unit) duck) see also http://bit.ly/1H2fN9i
  67. 67. let inline sayQuack (duck : ^a) = (^a : (member Quack : unit -> unit) duck) see also http://bit.ly/1H2fN9i
  68. 68. type Duck () = member __.Quack() = printfn “quack quack!” ! let duck = Duck() sayQuack duck ! > quack quack! see also http://bit.ly/1H2fN9i
  69. 69. type Bird () = member __.Quack() = printfn “tweet tweet!” ! let bird = Bird() sayQuack bird ! > tweet tweet! see also http://bit.ly/1H2fN9i
  70. 70. 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
  71. 71. Convenience Safety see also http://bit.ly/1H2fN9i
  72. 72. 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. 73. implicit interface! implementation
  74. 74. type Duck interface { Quack() } see also http://bit.ly/1ER5zVs
  75. 75. func sayQuack(duck Duck) { duck.Quack() } see also http://bit.ly/1ER5zVs
  76. 76. type Donald struct { } func (d Donald) Quack() { fmt.Println(“quack quack!”) } see also http://bit.ly/1ER5zVs
  77. 77. type Bird struct { } func (b Bird) Quack() { fmt.Println(“tweet tweet!”) } see also http://bit.ly/1ER5zVs
  78. 78. func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) } see also http://bit.ly/1ER5zVs
  79. 79. quack quack! func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) }
  80. 80. tweet tweet! func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) }
  81. 81. type Dog struct { } func (d Dog) Bark() { fmt.Println(“woof woof!”) } see also http://bit.ly/1ER5zVs
  82. 82. 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
  83. 83. Convenience Safety see also http://bit.ly/1ER5zVs
  84. 84. patterns are observed after the fact see also http://bit.ly/1ER5zVs
  85. 85. system building is also a process of learning and discovery see also http://bit.ly/1ER5zVs
  86. 86. implementation package interface package see also http://bit.ly/1ER5zVs
  87. 87. encourages precise interface definitions see also http://bit.ly/1ER5zVs
  88. 88. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  89. 89. 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…
  90. 90. code is data data is code
  91. 91. (let [x 1] (inc x)) see also http://bit.ly/1PpIrjS
  92. 92. (let [x 1] (inc x)) ! => 2 see also http://bit.ly/1PpIrjS
  93. 93. list (1 2 3) vector [1 2 3] see also http://bit.ly/1PpIrjS
  94. 94. (let [x 1] (inc x)) ! list see also http://bit.ly/1PpIrjS
  95. 95. (let [x 1] (inc x)) ! symbol see also http://bit.ly/1PpIrjS
  96. 96. (let [x 1] (inc x)) ! vector see also http://bit.ly/1PpIrjS
  97. 97. (let [x 1] (inc x)) ! list see also http://bit.ly/1PpIrjS
  98. 98. form : code as data structure see also http://bit.ly/1PpIrjS
  99. 99. code data quote eval see also http://bit.ly/1PpIrjS
  100. 100. quote (+ 1 2) => 3 see also http://bit.ly/1PpIrjS
  101. 101. quote (+ 1 2) => 3 (quote (+ 1 2)) => (+ 1 2) see also http://bit.ly/1PpIrjS
  102. 102. quote (+ 1 2) => 3 (quote (+ 1 2)) => (+ 1 2) ‘(+ 1 2) => (+ 1 2) see also http://bit.ly/1PpIrjS
  103. 103. eval ‘(+ 1 2) => (+ 1 2) (eval ‘(+ 1 2)) => 3 see also http://bit.ly/1PpIrjS
  104. 104. macros
  105. 105. (defmacro assert-equals [actual expected] ‘(let [actual-val# ~actual] (when-not (= actual-val# ~expected) (throw (AssertionError. (str “FAIL in “ ‘~actual “n expected: “ ‘~expected “n actual: “ actual-val#)))))) see also http://bit.ly/1PpIrjS
  106. 106. (assert-equals (inc 1) 2) ; => nil (assert-equals (inc 1) (+ 0 1)) ; => AssertionError FAIL in (inc 1) ; expected: (+ 0 1) ; actual: 2 see also http://bit.ly/1PpIrjS
  107. 107. (assert-equals (inc 1) 2) ; => nil (assert-equals (inc 1) (+ 0 1)) ; => AssertionError FAIL in (inc 1) ; expected: (+ 0 1) ; actual: 2 see also http://bit.ly/1PpIrjS
  108. 108. (assert-equals (inc 1) 2) ; => nil (assert-equals (inc 1) (+ 0 1)) ; => AssertionError FAIL in (inc 1) ; expected: (+ 0 1) ; actual: 2 see also http://bit.ly/1PpIrjS huh?? where? what? how?
  109. 109. (defmacro assert-equals [actual expected] ‘(let [actual-val# ~actual] (when-not (= actual-val# ~expected) (throw (AssertionError. (str “FAIL in “ ‘~actual “n expected: “ ‘~expected “n actual: “ actual-val#)))))) (assert-equals (inc 1) (+ 0 1)) see also http://bit.ly/1PpIrjS
  110. 110. (defmacro assert-equals [actual expected] ‘(let [actual-val# ~actual] (when-not (= actual-val# ~expected) (throw (AssertionError. (str “FAIL in “ ‘~actual “n expected: “ ‘~expected “n actual: “ actual-val#)))))) (assert-equals (inc 1) (+ 0 1)) see also http://bit.ly/1PpIrjS
  111. 111. (defmacro assert-equals [actual expected] ‘(let [actual-val# ~actual] (when-not (= actual-val# ~expected) (throw (AssertionError. (str “FAIL in “ ‘~actual “n expected: “ ‘~expected “n actual: “ actual-val#)))))) (assert-equals (inc 1) (+ 0 1)) see also http://bit.ly/1PpIrjS
  112. 112. see also http://bit.ly/1PpIrjS (defmacro assert-equals [actual expected] ‘(let [actual-val# ~actual] (when-not (= actual-val# ~expected) (throw (AssertionError. (str “FAIL in “ ‘~actual “n expected: “ ‘~expected “n actual: “ actual-val#))))))
  113. 113. expanded at compile time see also http://bit.ly/1PpIrjS
  114. 114. see also http://bit.ly/1PpIrjS (macroexpand '(assert-equals (inc 1) (+ 0 1))) ; => ; (let* [actual-value__16087__auto__ (inc 1)] ; (clojure.core/when-not ; (clojure.core/= actual-value__16087__auto__ (+ 0 1)) ; (throw (java.lang.AssertionError. ; (clojure.core/str ; "FAIL in " (quote (inc 1)) ; "nexpected: " (quote (+ 0 1)) ; "n actual: " actual-value__16087__auto__)))))
  115. 115. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  116. 116. GC is great
  117. 117. runtime cost
  118. 118. ownership see also http://bit.ly/1F6WBVD
  119. 119. memory safety without GC see also http://bit.ly/1F6WBVD
  120. 120. ZERO runtime cost see also http://bit.ly/1F6WBVD
  121. 121. safety + speed see also http://bit.ly/1F6WBVD
  122. 122. 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
  123. 123. immutable by default see also http://bit.ly/1F6WBVD
  124. 124. // take ownership let v = vec![1, 2, 3]; see also http://bit.ly/1F6WBVD
  125. 125. // take ownership let v = vec![1, 2, 3]; ! // moved ownership to v2 let v2 = v; see also http://bit.ly/1F6WBVD
  126. 126. // 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
  127. 127. fn take(v : Vec<i32>) { // ownership of vector transferred // to v in this scope } see also http://bit.ly/1F6WBVD
  128. 128. // take ownership let v = vec![1, 2, 3]; ! // moved ownership take(v); see also http://bit.ly/1F6WBVD
  129. 129. // 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
  130. 130. see also http://bit.ly/1F6WBVD
  131. 131. see also http://bit.ly/1F6WBVD let me buy your book
  132. 132. see also http://bit.ly/1F6WBVD sure thing!
  133. 133. see also http://bit.ly/1F6WBVD thanks
  134. 134. see also http://bit.ly/1F6WBVD BURN!!! ! >:D
  135. 135. see also http://bit.ly/1F6WBVD but I still need it..! :’(
  136. 136. borrowing see also http://bit.ly/1F6WBVD
  137. 137. // 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
  138. 138. // 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
  139. 139. see also http://bit.ly/1F6WBVD let me borrow your book
  140. 140. see also http://bit.ly/1F6WBVD sure thing!
  141. 141. see also http://bit.ly/1F6WBVD thanks
  142. 142. see also http://bit.ly/1F6WBVD I’m done, here you go
  143. 143. see also http://bit.ly/1F6WBVD thanks
  144. 144. see also http://bit.ly/1F6WBVD immutable by default
  145. 145. 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
  146. 146. 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
  147. 147. borrowing rules see also http://bit.ly/1F6WBVD
  148. 148. see also http://bit.ly/1F6WBVD Rule 1.! ! the borrower’s scope must not outlast the owner
  149. 149. 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
  150. 150. 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.
  151. 151. 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
  152. 152. 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
  153. 153. 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
  154. 154. see also http://bit.ly/1F6WBVD
  155. 155. Dependent Types Uniqueness Types Bit Syntax Borrowed Pointers Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Signals Macros Unit-of-Measure Actor Model
  156. 156. seen generics? aka parametric polymorphism
  157. 157. List<T>
  158. 158. List<T> List<int> List<Cat> List<string>
  159. 159. what if…
  160. 160. types that depend on arbitrary values?
  161. 161. Vect n a vector of n elements of type a
  162. 162. zipWith : (a -> b -> c) -> Vect n a -> Vect n b -> Vect n c
  163. 163. zipWith f [] [] = [] zipWith f (x :: xs) (y :: ys) = f x y :: zipWith f xs ys
  164. 164. Type Driven Development
  165. 165. making invalid state UNREPRESENTABLE
  166. 166. see also https://vimeo.com/123606435
  167. 167. Signals Dependent Types Uniqueness Types Bit Syntax Borrowed Pointers Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Macros Unit-of-Measure Actor Model
  168. 168. Function Reactive Programming
  169. 169. Value over Time
  170. 170. Time Value
  171. 171. Signals
  172. 172. Move Up Move Down
  173. 173. private var arrowKeyUp:Bool; private var arrowKeyDown:Bool; ! private var platform1:Platform; private var platform2:Platform; private var ball:Ball;
  174. 174. 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;! } }
  175. 175. function keyUp(event:KeyboardEvent):Void { if (event.keyCode == 38) { ! ! arrowKeyUp = false;! } else if (event.keyCode == 40) { ! ! arrowKeyDown = false;! } }
  176. 176. 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; } }
  177. 177. 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;! } }
  178. 178. source files state changes
  179. 179. source files execution
  180. 180. source files execution
  181. 181. mental model input state new state behaviour { x; y } { x; y-speed } { x; y } { x; y+speed } timer { x; y } { x; y } draw platform … … … …
  182. 182. transformation let y = f(x) Imperative Functional x.f() mutation
  183. 183. transformations simplify problem decomposition
  184. 184. Move Up Move Down
  185. 185. 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
  186. 186. 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
  187. 187. 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
  188. 188. Keyboard.arrows UP { x=0, y=1 } DOWN { x=0, y=-1 } LEFT { x=-1, y=0 } RIGHT { x=1, y=0 }
  189. 189. 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
  190. 190. 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
  191. 191. 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
  192. 192. 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
  193. 193. “I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.” - Alan Kay
  194. 194. “OOP to me means only messaging, local retention and protection and hiding of state- process, and extreme late- binding of all things.” - Alan Kay
  195. 195. Borrowed Pointers Actor Model Bit Syntax Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Dependent Types Uniqueness Types Signals Macros Unit-of-Measure
  196. 196. actor model
  197. 197. actor state mailbox
  198. 198. actors share nothing
  199. 199. actor state mailbox actor
  200. 200. actor state mailbox actor
  201. 201. processing! storage! communication
  202. 202. loop (Map) ->! receive! {get, Key, Pid} ->! Pid ! maps:get(Key, Map, not_found),! loop(Map);! {set, Key, Value} ->! loop(maps:put(Key, Value, Map))! end.
  203. 203. loop (Map) ->! receive! {get, Key, Pid} ->! Pid ! maps:get(Key, Map, not_found),! loop(Map);! {set, Key, Value} ->! loop(maps:put(Key, Value, Map))! end.
  204. 204. loop (Map) ->! receive! {get, Key, Pid} ->! Pid ! maps:get(Key, Map, not_found),! loop(Map);! {set, Key, Value} ->! loop(maps:put(Key, Value, Map))! end.
  205. 205. loop (Map) ->! receive! {get, Key, Pid} ->! Pid ! maps:get(Key, Map, not_found),! loop(Map);! {set, Key, Value} ->! loop(maps:put(Key, Value, Map))! end.
  206. 206. client (N, Pid) ->! Pid ! {set, N, N},! Pid ! {get, N, self()},! receive! not_found -> io:format(“~p :-(~n”, [N]);! N -> io:format(“~p :-)~n”, [N]);! _ -> io:format(“~p …~n”, [N])! end.
  207. 207. client (N, Pid) ->! Pid ! {set, N, N},! Pid ! {get, N, self()},! receive! not_found -> io:format(“~p :-(~n”, [N]);! N -> io:format(“~p :-)~n”, [N]);! _ -> io:format(“~p …~n”, [N])! end.
  208. 208. client (N, Pid) ->! Pid ! {set, N, N},! Pid ! {get, N, self()},! receive! not_found -> io:format(“~p :-(~n”, [N]);! N -> io:format(“~p :-)~n”, [N]);! _ -> io:format(“~p …~n”, [N])! end.
  209. 209. start(N) ->! Kvs = spawn(mod, loop, [#{}]),! [spawn(mod, client, [X, Kvs]) ! || X <- lists:seq(1,N)].
  210. 210. actors are cheap
  211. 211. no locks!
  212. 212. need state?! talk to the actor!
  213. 213. location transparency
  214. 214. pre-emptive scheduling
  215. 215. makes you ! THINK ! about ! distributed systems
  216. 216. messaging promotes failure thinking
  217. 217. Distributed Computing
  218. 218. 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
  219. 219. supervise & restart
  220. 220. http://www.ustream.tv/recorded/61443262 https://aphyr.com/posts
  221. 221. Borrowed Pointers Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Dependent Types Uniqueness Types Signals Macros Unit-of-Measure Bit Syntax Actor Model
  222. 222. pattern matching
  223. 223. { X, Y } = { 1, 2 }
  224. 224. { X, Y } = { 1, 2 }
  225. 225. [ H | T ] = [ 1, 2, 3 ]
  226. 226. image from http://learnyousomeerlang.com/
  227. 227. [ H | T ] = [ 1, 2, 3 ]
  228. 228. what if…
  229. 229. you can pattern match binary data?! e.g. TCP payload
  230. 230. <<SourcePort:16, DestinationPort:16, ! SeqNumber:32,! AckNumber:32, DataOffset:4, ! Reserved:3, Flags:9, WindSize:16,! CheckSum:16, UrgentPointer:16,! Payload/binary>> = SomeBinary
  231. 231. <<SourcePort:16, DestinationPort:16, ! SeqNumber:32,! AckNumber:32, DataOffset:4, ! Reserved:3, Flags:9, WindSize:16,! CheckSum:16, UrgentPointer:16,! Payload/binary>> = SomeBinary
  232. 232. <<SourcePort:16, DestinationPort:16, ! SeqNumber:32,! AckNumber:32, DataOffset:4, ! Reserved:3, Flags:9, WindSize:16,! CheckSum:16, UrgentPointer:16,! Payload/binary>> = SomeBinary
  233. 233. <<SourcePort:16, DestinationPort:16, ! SeqNumber:32,! AckNumber:32, DataOffset:4, ! Reserved:3, Flags:9, WindSize:16,! CheckSum:16, UrgentPointer:16,! Payload/binary>> = SomeBinary
  234. 234. <<SourcePort:16, DestinationPort:16, ! SeqNumber:32,! AckNumber:32, DataOffset:4, ! Reserved:3, Flags:9, WindSize:16,! CheckSum:16, UrgentPointer:16,! Payload/binary>> = SomeBinary
  235. 235. .! .! .
  236. 236. <<SourcePort:16, DestinationPort:16, ! SeqNumber:32,! AckNumber:32, DataOffset:4, ! Reserved:3, Flags:9, WindSize:16,! CheckSum:16, UrgentPointer:16,! Payload/binary>> = SomeBinary
  237. 237. case Packet of! <<SeqNum:16/big-unsigned-integer, ! Timestamp:32/big-unsigned-integer, ! Src:32/little-signed-integer, ! _/binary>> ->! ! % do something useful! ! …! _ ->! ! % invalid format! ! …! end
  238. 238. case Packet of! <<SeqNum:16/big-unsigned-integer, ! Timestamp:32/big-unsigned-integer, ! Src:32/little-signed-integer, ! _/binary>> ->! ! % do something useful! ! …! _ ->! ! % invalid format! ! …! end
  239. 239. case Packet of! <<SeqNum:16/big-unsigned-integer, ! Timestamp:32/big-unsigned-integer, ! Src:32/little-signed-integer, ! _/binary>> ->! ! % do something useful! ! …! _ ->! ! % invalid format! ! …! end
  240. 240. case Packet of! <<SeqNum:16/big-unsigned-integer, ! Timestamp:32/big-unsigned-integer, ! Src:32/little-signed-integer, ! _/binary>> ->! ! % do something useful! ! …! _ ->! ! % invalid format! ! …! end
  241. 241. case Packet of! <<SeqNum:16/big-unsigned-integer, ! Timestamp:32/big-unsigned-integer, ! Src:32/little-signed-integer, ! _/binary>> ->! ! % do something useful! ! …! _ ->! ! % invalid format! ! …! end
  242. 242. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness TypesOTP Bit Syntax Signals Macros Unit-of-Measure
  243. 243. 10,000 hours to be good at something see also http://bit.ly/1KN7SLq
  244. 244. 10,000 hours to be good at something see also http://bit.ly/1KN7SLq
  245. 245. 10,000 hours to reach top of an ultra- competitive field see also http://bit.ly/1KN7SLq
  246. 246. the first 20 hours - how to learn anything see also http://bit.ly/1KN7SLq
  247. 247. Practice Time Howgoodyouare see also http://bit.ly/1KN7SLq
  248. 248. 1.Deconstruct the skill see also http://bit.ly/1KN7SLq
  249. 249. 1.Deconstruct the skill! 2.Learn enough to self-correct see also http://bit.ly/1KN7SLq
  250. 250. 1.Deconstruct the skill! 2.Learn enough to self-correct! 3.Remove practice barriers see also http://bit.ly/1KN7SLq
  251. 251. 1.Deconstruct the skill! 2.Learn enough to self-correct! 3.Remove practice barriers! 4.Practice at least 20 hrs see also http://bit.ly/1KN7SLq
  252. 252. learn a new paradigm! not a new syntax see also http://bit.ly/1IzXVSo
  253. 253. logic programming
  254. 254. stack-oriented programming
  255. 255. array programming
  256. 256. “A language that doesn't affect the way you think about programming, is not worth knowing.” - Alan Perlis
  257. 257. see also http://bit.ly/1IzXVSo
  258. 258. see also http://bit.ly/1IzXVSo
  259. 259. Enterprise Tic-Tac-Toe - a Functional Approach Type Driven Development Computation expression in context : a history of the otter king Learning From Haskell
  260. 260. “Learning is an act of creation itself, because something happens in you that wasn't there before.” - Alan Kay
  261. 261. @theburningmonk theburningmonk.com github.com/theburningmonk
  262. 262. @theburningmonk theburningmonk.com github.com/theburningmonk
  263. 263. WE’RE HIRING www.gamesyscorporate.com/careers

×