Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tour of language landscape (BuildStuff)

0 views

Published on

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.

Published in: Technology
  • Be the first to comment

Tour of language landscape (BuildStuff)

  1. 1. Yan Cui @theburningmonk
  2. 2. hi,I’mYanCui
  3. 3. http://bit.ly/1SPNPn7
  4. 4. 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
  5. 5. “The limits of my language means the limits of my world.” - Ludwig Wittgenstein
  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. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  9. 9. your app
  10. 10. your app CSVCSVCSV CSVCSVXML
  11. 11. your app CSVCSVCSV CSVCSVXML some service
  12. 12. your app CSVCSVCSV CSVCSVXML some service DB
  13. 13. 1. define DTO types 2. I/O 3. marshal data into DTO 4. do useful work
  14. 14. 1. define DTO types 2. I/O 3. marshal data into DTO 4. do useful work
  15. 15. compiler provideexternal data source typed info
  16. 16. type providers
  17. 17. intellisense tooltips …
  18. 18. intellisense over S3 buckets & objects!
  19. 19. compile time validation
  20. 20. no code generation
  21. 21. R FunScript Azure Amazon S3 CSVSQLite SQL Server WSDL WorldBank Regex ODATA IKVM Facebook Apiary XAMLFreebase Hadoop Oracle Minesweeper Don Syme Powershell JSON Fizzbuzz Mixin RSS Matlab Dates NorthPole XML Python
  22. 22. Don Syme can taste lies.
  23. 23. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  24. 24. “…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)
  25. 25. 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
  26. 26. 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
  27. 27. how we read CODE public void DoSomething(int x, int y) { Foo(y, Bar(x, Zoo(Monkey()))); } see also http://bit.ly/1KN8cd0
  28. 28. 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
  29. 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… 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
  30. 30. “…a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort.”
  31. 31. |>
  32. 32. 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
  33. 33. 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
  34. 34. let drawCircle x y radius = circle radius |> filled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0
  35. 35. let drawCircle x y radius = circle radius |> filled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0
  36. 36. let drawCircle x y radius = circle radius |> filled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0
  37. 37. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  38. 38. NASA orbiter crashed because one engineer accidentally used miles instead of kilometres
  39. 39. you’re never too smart to make mistakes
  40. 40. unit-of-measure
  41. 41. [<Measure>] type Pence e.g. 42<Pence> 153<Pence> …
  42. 42. 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
  43. 43. 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
  44. 44. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  45. 45. Duck Typing If it looks like a duck and quacks like a duck, it's a duck
  46. 46. def say_quack(duck): duck.quack()
  47. 47. def say_quack(duck): duck.quack()
  48. 48. Convenience Safety
  49. 49. implicit interface implementation
  50. 50. type Duck interface { Quack() } see also http://bit.ly/1ER5zVs
  51. 51. func sayQuack(duck Duck) { duck.Quack() } see also http://bit.ly/1ER5zVs
  52. 52. type Donald struct { } func (d Donald) Quack() { fmt.Println(“quack quack!”) } see also http://bit.ly/1ER5zVs
  53. 53. type Bird struct { } func (b Bird) Quack() { fmt.Println(“tweet tweet!”) } see also http://bit.ly/1ER5zVs
  54. 54. func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) } see also http://bit.ly/1ER5zVs
  55. 55. quack quack! func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) }
  56. 56. tweet tweet! func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) }
  57. 57. type Dog struct { } func (d Dog) Bark() { fmt.Println(“woof woof!”) } see also http://bit.ly/1ER5zVs
  58. 58. 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
  59. 59. Convenience Safety see also http://bit.ly/1ER5zVs
  60. 60. patterns are observed after the fact see also http://bit.ly/1ER5zVs
  61. 61. system building is also a process of learning and discovery see also http://bit.ly/1ER5zVs
  62. 62. implementation package interface package see also http://bit.ly/1ER5zVs
  63. 63. encourages precise interface definitions see also http://bit.ly/1ER5zVs
  64. 64. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  65. 65. 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…
  66. 66. code is data data is code
  67. 67. (let [x 1] (inc x)) see also http://bit.ly/1PpIrjS
  68. 68. (let [x 1] (inc x)) => 2 see also http://bit.ly/1PpIrjS
  69. 69. list (1 2 3) vector [1 2 3] see also http://bit.ly/1PpIrjS
  70. 70. (let [x 1] (inc x)) list see also http://bit.ly/1PpIrjS
  71. 71. (let [x 1] (inc x)) symbol see also http://bit.ly/1PpIrjS
  72. 72. (let [x 1] (inc x)) vector see also http://bit.ly/1PpIrjS
  73. 73. (let [x 1] (inc x)) list see also http://bit.ly/1PpIrjS
  74. 74. form : code as data structure see also http://bit.ly/1PpIrjS
  75. 75. code data quote eval see also http://bit.ly/1PpIrjS
  76. 76. quote (+ 1 2) => 3 see also http://bit.ly/1PpIrjS
  77. 77. quote (+ 1 2) => 3 (quote (+ 1 2)) => (+ 1 2) see also http://bit.ly/1PpIrjS
  78. 78. quote (+ 1 2) => 3 (quote (+ 1 2)) => (+ 1 2) ‘(+ 1 2) => (+ 1 2) see also http://bit.ly/1PpIrjS
  79. 79. eval ‘(+ 1 2) => (+ 1 2) (eval ‘(+ 1 2)) => 3 see also http://bit.ly/1PpIrjS
  80. 80. macros
  81. 81. (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
  82. 82. (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
  83. 83. (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
  84. 84. (assert-equals (inc 1) 2) ; => nil (assert-equals (inc 1) (+ 0 1)) ; => AssertionError FAIL in (inc 1) ; expected: (+ 0 1) ; actual: 2 huh?? where? what? how? see also http://bit.ly/1PpIrjS
  85. 85. (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
  86. 86. (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
  87. 87. (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
  88. 88. (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
  89. 89. (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
  90. 90. expanded at compile time see also http://bit.ly/1PpIrjS
  91. 91. (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__))))) see also http://bit.ly/1PpIrjS
  92. 92. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  93. 93. GC is great
  94. 94. runtime cost
  95. 95. ownership see also http://bit.ly/1F6WBVD
  96. 96. memory safety without GC see also http://bit.ly/1F6WBVD
  97. 97. ZERO runtime cost see also http://bit.ly/1F6WBVD
  98. 98. safety + speed see also http://bit.ly/1F6WBVD
  99. 99. 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
  100. 100. immutable by default see also http://bit.ly/1F6WBVD
  101. 101. // take ownership let v = vec![1, 2, 3]; see also http://bit.ly/1F6WBVD
  102. 102. // take ownership let v = vec![1, 2, 3]; // moved ownership to v2 let v2 = v; see also http://bit.ly/1F6WBVD
  103. 103. // 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
  104. 104. fn take(v : Vec<i32>) { // ownership of vector transferred // to v in this scope } see also http://bit.ly/1F6WBVD
  105. 105. // take ownership let v = vec![1, 2, 3]; // moved ownership take(v); see also http://bit.ly/1F6WBVD
  106. 106. // 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
  107. 107. see also http://bit.ly/1F6WBVD
  108. 108. let me buy your book see also http://bit.ly/1F6WBVD
  109. 109. sure thing! see also http://bit.ly/1F6WBVD
  110. 110. thanks see also http://bit.ly/1F6WBVD
  111. 111. BURN!!! >:D see also http://bit.ly/1F6WBVD
  112. 112. but I still need it.. :’( see also http://bit.ly/1F6WBVD
  113. 113. borrowing see also http://bit.ly/1F6WBVD
  114. 114. // 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
  115. 115. // 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
  116. 116. let me borrow your book see also http://bit.ly/1F6WBVD
  117. 117. sure thing! see also http://bit.ly/1F6WBVD
  118. 118. thanks see also http://bit.ly/1F6WBVD
  119. 119. I’m done, here you go see also http://bit.ly/1F6WBVD
  120. 120. thanks see also http://bit.ly/1F6WBVD
  121. 121. immutable by default see also http://bit.ly/1F6WBVD
  122. 122. 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
  123. 123. 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
  124. 124. there are 2 rules to BORROWING
  125. 125. Rule 1. the borrower’s scope must not outlast the owner see also http://bit.ly/1F6WBVD
  126. 126. 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
  127. 127. 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
  128. 128. 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
  129. 129. 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
  130. 130. 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
  131. 131. see also http://bit.ly/1F6WBVD
  132. 132. Dependent Types Uniqueness Types Bit Syntax Borrowed Pointers Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Signals Macros Unit-of-Measure Actor Model
  133. 133. seen generics? aka parametric polymorphism
  134. 134. List<T>
  135. 135. List<T> List<int> List<Cat> List<string>
  136. 136. what if…
  137. 137. types that depend on arbitrary values?
  138. 138. Vect n a vector of n elements of type a
  139. 139. zipWith : (a -> b -> c) -> Vect n a -> Vect n b -> Vect n c
  140. 140. zipWith f [] [] = [] zipWith f (x :: xs) (y :: ys) = f x y :: zipWith f xs ys
  141. 141. Type Driven Development
  142. 142. “Make illegal states unrepresentable” - Yaron Minsky
  143. 143. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model
  144. 144. 10,000 hours to be good at something see also http://bit.ly/1KN7SLq
  145. 145. 10,000 hours to be good at something see also http://bit.ly/1KN7SLq
  146. 146. 10,000 hours to reach top of an ultra- competitive field see also http://bit.ly/1KN7SLq
  147. 147. the first 20 hours - how to learn anything see also http://bit.ly/1KN7SLq
  148. 148. Practice Time Howgoodyouare see also http://bit.ly/1KN7SLq
  149. 149. 1.Deconstruct the skill see also http://bit.ly/1KN7SLq
  150. 150. 1.Deconstruct the skill 2.Learn enough to self-correct see also http://bit.ly/1KN7SLq
  151. 151. 1.Deconstruct the skill 2.Learn enough to self-correct 3.Remove practice barriers see also http://bit.ly/1KN7SLq
  152. 152. 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
  153. 153. learn a new paradigm not a new syntax see also http://bit.ly/1IzXVSo
  154. 154. “Programming languages have a devious influence: they shape our thinking habits.” - Edsger W. Dijkstra
  155. 155. logic programming
  156. 156. stack-oriented programming
  157. 157. array programming
  158. 158. “A language that doesn't affect the way you think about programming, is not worth knowing.” - Alan Perlis
  159. 159. see also http://bit.ly/1IzXVSo
  160. 160. see also http://bit.ly/1IzXVSo
  161. 161. “Learning is an act of creation itself, because something happens in you that wasn't there before.” - Alan Kay
  162. 162. @theburningmonk theburningmonk.com github.com/theburningmonk

×