Tour of language landscape (BuildStuff)

1. Yan Cui @theburningmonk

2. hi,I’mYanCui

9. http://bit.ly/1SPNPn7

10. ZOOZU VAPA BOROU DUMBU dark shades of blue, red, green & purple white & some shades of yellow some shades of green & blue other shades of green, red & brown

13. “The limits of my language means the limits of my world.” - Ludwig Wittgenstein

14. agenda

15. Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Borrowed Pointers Dependent Types Uniqueness Types Bit Syntax Signals Macros Unit-of-Measure Actor Model

18. your app

19. your app CSVCSVCSV CSVCSVXML

20. your app CSVCSVCSV CSVCSVXML some service

21. your app CSVCSVCSV CSVCSVXML some service DB

22. 1. define DTO types 2. I/O 3. marshal data into DTO 4. do useful work

23. 1. define DTO types 2. I/O 3. marshal data into DTO 4. do useful work

24. compiler provideexternal data source typed info

25. type providers

26. intellisense tooltips …

29. intellisense over S3 buckets & objects!

30. compile time validation

31. no code generation

32. 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

33. Don Syme can taste lies.

35. “…a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort.” - Daniel Higginbotham (www.visualmess.com)

36. Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage problem using a message passing approach. Naturally, I wanted to answer that question with Erlang! Let’s first dissect the problem and decide what processes we need and how they need to interact with one another. The stable marriage problem is commonly stated as: Given n men and n women, where each person has ranked all members of the opposite sex with a unique number between 1 and n in order of preference, marry the men and women together such that there are no two people of opposite sex who would both rather have each other than their current partners. If there are no such people, all the marriages are “stable”. (It is assumed that the participants are binary gendered and that marriages are not same-sex). From the problem description, we can see that we need: * a module for man * a module for woman * a module for orchestrating the experiment In terms of interaction between the different modules, I imagined something along the lines of… how we read ENGLISH see also http://bit.ly/1KN8cd0

37. Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage problem using a message passing approach. Naturally, I wanted to answer that question with Erlang! Let’s first dissect the problem and decide what processes we need and how they need to interact with one another. The stable marriage problem is commonly stated as: Given n men and n women, where each person has ranked all members of the opposite sex with a unique number between 1 and n in order of preference, marry the men and women together such that there are no two people of opposite sex who would both rather have each other than their current partners. If there are no such people, all the marriages are “stable”. (It is assumed that the participants are binary gendered and that marriages are not same-sex). From the problem description, we can see that we need: * a module for man * a module for woman * a module for orchestrating the experiment In terms of interaction between the different modules, I imagined something along the lines of… 2.top-to-bottom 1.left-to-right how we read ENGLISH see also http://bit.ly/1KN8cd0

38. how we read CODE public void DoSomething(int x, int y) { Foo(y, Bar(x, Zoo(Monkey()))); } see also http://bit.ly/1KN8cd0

39. how we read CODE public void DoSomething(int x, int y) { Foo(y, Bar(x, Zoo(Monkey()))); } 2.bottom-to-top 1.right-to-left see also http://bit.ly/1KN8cd0

40. Whilst talking with an ex-colleague, a question came up on how to implement the Stable Marriage problem using a message passing approach. Naturally, I wanted to answer that question with Erlang! Let’s first dissect the problem and decide what processes we need and how they need to interact with one another. The stable marriage problem is commonly stated as: Given n men and n women, where each person has ranked all members of the opposite sex with a unique number between 1 and n in order of preference, marry the men and women together such that there are no two people of opposite sex who would both rather have each other than their current partners. If there are no such people, all the marriages are “stable”. (It is assumed that the participants are binary gendered and that marriages are not same-sex). From the problem description, we can see that we need: * a module for man * a module for woman * a module for orchestrating the experiment In terms of interaction between the different modules, I imagined something along the lines of… 2.top-to-bottom 1.left-to-right how we read ENGLISH public void DoSomething(int x, int y) { Foo(y, Bar(x, Zoo(Monkey()))); } 2.top-to-bottom 1.right-to-left how we read CODE see also http://bit.ly/1KN8cd0

41. “…a clean design is one that supports visual thinking so people can meet their informational needs with a minimum of conscious effort.”

42. |>

43. how we read CODE let drawCircle x y radius = radius |> circle |> ﬁlled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0

44. how we read CODE let drawCircle x y radius = radius |> circle |> ﬁlled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) 2.top-to-bottom 1.left-to-right see also http://bit.ly/1KN8cd0

45. let drawCircle x y radius = circle radius |> ﬁlled (rgb 150 170 150) |> alpha 0.5 |> move (x, y) see also http://bit.ly/1KN8cd0

49. NASA orbiter crashed because one engineer accidentally used miles instead of kilometres

50. you’re never too smart to make mistakes

51. unit-of-measure

52. [<Measure>] type Pence e.g. 42<Pence> 153<Pence> …

53. 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

54. 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

57. Duck Typing If it looks like a duck and quacks like a duck, it's a duck

58. def say_quack(duck): duck.quack()

59. def say_quack(duck): duck.quack()

60. Convenience Safety

61. implicit interface implementation

62. type Duck interface { Quack() } see also http://bit.ly/1ER5zVs

63. func sayQuack(duck Duck) { duck.Quack() } see also http://bit.ly/1ER5zVs

64. type Donald struct { } func (d Donald) Quack() { fmt.Println(“quack quack!”) } see also http://bit.ly/1ER5zVs

65. type Bird struct { } func (b Bird) Quack() { fmt.Println(“tweet tweet!”) } see also http://bit.ly/1ER5zVs

66. func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) } see also http://bit.ly/1ER5zVs

67. quack quack! func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) }

68. tweet tweet! func main() { donald := Donald{} sayQuack(donald) bird := Bird{} sayQuack(bird) }

69. type Dog struct { } func (d Dog) Bark() { fmt.Println(“woof woof!”) } see also http://bit.ly/1ER5zVs

70. func main() { dog := Dog{} sayQuack(dog) } main.go:40: cannot use dog (type Dog) as type Duck in argument to sayQuack: Dog does not implement Duck (missing Quack method) see also http://bit.ly/1ER5zVs

71. Convenience Safety see also http://bit.ly/1ER5zVs

72. patterns are observed after the fact see also http://bit.ly/1ER5zVs

73. system building is also a process of learning and discovery see also http://bit.ly/1ER5zVs

74. implementation package interface package see also http://bit.ly/1ER5zVs

75. encourages precise interface deﬁnitions see also http://bit.ly/1ER5zVs

78. Homoiconicity …homoiconicity is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program’s internal representation can be inferred by reading the text’s layout…

79. code is data data is code

80. (let [x 1] (inc x)) see also http://bit.ly/1PpIrjS

81. (let [x 1] (inc x)) => 2 see also http://bit.ly/1PpIrjS

82. list (1 2 3) vector [1 2 3] see also http://bit.ly/1PpIrjS

83. (let [x 1] (inc x)) list see also http://bit.ly/1PpIrjS

84. (let [x 1] (inc x)) symbol see also http://bit.ly/1PpIrjS

85. (let [x 1] (inc x)) vector see also http://bit.ly/1PpIrjS

86. (let [x 1] (inc x)) list see also http://bit.ly/1PpIrjS

87. form : code as data structure see also http://bit.ly/1PpIrjS

88. code data quote eval see also http://bit.ly/1PpIrjS

89. quote (+ 1 2) => 3 see also http://bit.ly/1PpIrjS

90. quote (+ 1 2) => 3 (quote (+ 1 2)) => (+ 1 2) see also http://bit.ly/1PpIrjS

91. quote (+ 1 2) => 3 (quote (+ 1 2)) => (+ 1 2) ‘(+ 1 2) => (+ 1 2) see also http://bit.ly/1PpIrjS

92. eval ‘(+ 1 2) => (+ 1 2) (eval ‘(+ 1 2)) => 3 see also http://bit.ly/1PpIrjS

93. macros

94. (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

95. (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

96. (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

97. (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

98. (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

101. (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

102. (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

103. expanded at compile time see also http://bit.ly/1PpIrjS

104. (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

107. GC is great

108. runtime cost

109. ownership see also http://bit.ly/1F6WBVD

110. memory safety without GC see also http://bit.ly/1F6WBVD

111. ZERO runtime cost see also http://bit.ly/1F6WBVD

112. safety + speed see also http://bit.ly/1F6WBVD

113. fn foo() { // v has ownership of the vector let v = vec![1, 2, 3]; // mutable binding let mut v2 = vec![]; } // vector is deallocated at the // end of scope, // this happens deterministically see also http://bit.ly/1F6WBVD

114. immutable by default see also http://bit.ly/1F6WBVD

115. // take ownership let v = vec![1, 2, 3]; see also http://bit.ly/1F6WBVD

116. // take ownership let v = vec![1, 2, 3]; // moved ownership to v2 let v2 = v; see also http://bit.ly/1F6WBVD

117. // take ownership let v = vec![1, 2, 3]; // moved ownership to v2 let v2 = v; println!("v[0] is {}", v[0]); // error: use of moved value: `v` // println!("v[0] is {}", v[0]); // ^ see also http://bit.ly/1F6WBVD

118. fn take(v : Vec<i32>) { // ownership of vector transferred // to v in this scope } see also http://bit.ly/1F6WBVD

119. // take ownership let v = vec![1, 2, 3]; // moved ownership take(v); see also http://bit.ly/1F6WBVD

120. // take ownership let v = vec![1, 2, 3]; // moved ownership take(v); println!("v[0] is {}", v[0]); // error: use of moved value: `v` // println!("v[0] is {}", v[0]); // ^ see also http://bit.ly/1F6WBVD

121. see also http://bit.ly/1F6WBVD

122. let me buy your book see also http://bit.ly/1F6WBVD

123. sure thing! see also http://bit.ly/1F6WBVD

124. thanks see also http://bit.ly/1F6WBVD

125. BURN!!! >:D see also http://bit.ly/1F6WBVD

126. but I still need it.. :’( see also http://bit.ly/1F6WBVD

127. borrowing see also http://bit.ly/1F6WBVD

128. // note we're taking a reference, // &Vec<i32>, instead of Vec<i32> fn take(v : &Vec<i32>) { // no need to deallocate the vector // after we go out of scope here } see also http://bit.ly/1F6WBVD

129. // take ownership let v = vec![1, 2, 3]; // notice we're passing a reference, // &v, instead of v take(&v); // borrow ownership println!("v[0] is {}", v[0]); // v[0] is 1 see also http://bit.ly/1F6WBVD

130. let me borrow your book see also http://bit.ly/1F6WBVD

131. sure thing! see also http://bit.ly/1F6WBVD

133. I’m done, here you go see also http://bit.ly/1F6WBVD

135. immutable by default see also http://bit.ly/1F6WBVD

136. fn take(v : &Vec<i32>) { v.push(5); } let v = vec![]; take(&v); // cannot borrow immutable borrowed // content `*v` as mutable // v.push(5); // ^ see also http://bit.ly/1F6WBVD

137. fn take(v : &mut Vec<i32>) { v.push(5); } let mut v = vec![]; take(&mut v); println!("v[0] is {}", v[0]); // v[0] is 5 see also http://bit.ly/1F6WBVD

138. there are 2 rules to BORROWING

139. Rule 1. the borrower’s scope must not outlast the owner see also http://bit.ly/1F6WBVD

140. Rule 2. one of the following, but not both: 2.1 0 or more refs to a resource 2.2 exactly 1 mutable ref see also http://bit.ly/1F6WBVD

141. data race There is a ‘data race’ when two or more pointers access the same memory location at the same time, where at least one of them is writing, and the operations are not synchronised. see also http://bit.ly/1F6WBVD

142. data race a. two or more pointers to the same resource b. at least one is writing c. operations are not synchronised see also http://bit.ly/1F6WBVD

143. Data Race Conditions a. two or more pointers to the same resource b. at least one is writing c. operations are not synchronised Borrowing Rules one of the following, but not both: 2.1 0 or more refs to a resource 2.2 exactly 1 mutable ref see also http://bit.ly/1F6WBVD

144. Data Race Conditions a. two or more pointers to the same resource b. at least one is writing c. operations are not synchronised Borrowing Rules one of the following, but not both: 2.1 0 or more refs to a resource 2.2 exactly 1 mutable ref see also http://bit.ly/1F6WBVD

145. see also http://bit.ly/1F6WBVD

147. Dependent Types Uniqueness Types Bit Syntax Borrowed Pointers Type Provider Pipes Statically Resolved TP Implicit Interface Implementation Signals Macros Unit-of-Measure Actor Model

148. seen generics? aka parametric polymorphism

149. List<T>

150. List<T> List<int> List<Cat> List<string>

151. what if…

152. types that depend on arbitrary values?

153. Vect n a vector of n elements of type a

154. zipWith : (a -> b -> c) -> Vect n a -> Vect n b -> Vect n c

155. zipWith f [] [] = [] zipWith f (x :: xs) (y :: ys) = f x y :: zipWith f xs ys

156. Type Driven Development

157. “Make illegal states unrepresentable” - Yaron Minsky

159. 10,000 hours to be good at something see also http://bit.ly/1KN7SLq

160. 10,000 hours to be good at something see also http://bit.ly/1KN7SLq

161. 10,000 hours to reach top of an ultra- competitive field see also http://bit.ly/1KN7SLq

163. the first 20 hours - how to learn anything see also http://bit.ly/1KN7SLq

164. Practice Time Howgoodyouare see also http://bit.ly/1KN7SLq

165. 1.Deconstruct the skill see also http://bit.ly/1KN7SLq

166. 1.Deconstruct the skill 2.Learn enough to self-correct see also http://bit.ly/1KN7SLq

167. 1.Deconstruct the skill 2.Learn enough to self-correct 3.Remove practice barriers see also http://bit.ly/1KN7SLq

168. 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

170. learn a new paradigm not a new syntax see also http://bit.ly/1IzXVSo

171. “Programming languages have a devious influence: they shape our thinking habits.” - Edsger W. Dijkstra

172. logic programming

173. stack-oriented programming

174. array programming

175. “A language that doesn't affect the way you think about programming, is not worth knowing.” - Alan Perlis

176. see also http://bit.ly/1IzXVSo

177. see also http://bit.ly/1IzXVSo

178. “Learning is an act of creation itself, because something happens in you that wasn't there before.” - Alan Kay

179. @theburningmonk theburningmonk.com github.com/theburningmonk

Tour of language landscape (BuildStuff)

Tour of language landscape (BuildStuff)

Recommended

More Related Content

Similar to Tour of language landscape (BuildStuff)

Similar to Tour of language landscape (BuildStuff)(20)

More from Yan Cui

More from Yan Cui(20)

Recently uploaded

Recently uploaded(20)

Tour of language landscape (BuildStuff)