Successfully reported this slideshow.

Tour of language landscape

2

Share

Upcoming SlideShare
Tour of language landscape
Tour of language landscape
Loading in …3
×
1 of 156
1 of 156

Tour of language landscape

2

Share

Download to read offline

Description

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.

Transcript

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

Description

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.

Transcript

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

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

×