Tour of language landscape (katsconf)

1. tour guide : Yan Cui @theburningmonk

2. Hi, my name is Yan Cui.

3. 1MILLION USERS ACTIVE DAILY

4. 250MILLION DAY PER REQUEST

5. agenda

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

7. F# ClojureErlang Go RustElm Idris

9. disclaimers

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

11. “One of the most disastrous thing we can learn is the ﬁrst programming language, even if it's a good programming language.” - Alan Kay

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

13. “We cannot solve our problems with the same thinking we used when we created them.” - Albert Einstein

15. your app

16. your app CSVCSVCSV CSVCSVXML

17. your app CSVCSVCSV CSVCSVXML some service

18. your app CSVCSVCSV CSVCSVXML some service DB

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

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

21. compiler provideexternal data source typed info

22. type providers

23. intellisense! tooltips! …

24. compile time validation

25. no code generation

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

27. pipes

28. “…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)

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… how we read ENGLISH see also http://bit.ly/1KN8cd0

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

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

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

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… 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

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

35. |>

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

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

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

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

42. you’re never too smart to make mistakes

43. unit-of-measure

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

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

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

47. F# ClojureErlang Go RustElm Idris !?

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

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

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

51. class Duck: def quack(self): print("quack quack!”)

52. class Duck: def quack(self): print("quack quack!”) ! duck = Duck() say_quack(duck) ! > quack quack!

53. class Bird: def quack(self): print(“tweet tweet!”)

54. class Bird: def quack(self): print(“tweet tweet!”) ! bird = Bird() say_quack(bird) ! > tweet tweet!

55. Convenience Safety

56. what if…

57. Convenience Safety see also http://bit.ly/1H2fN9i

58. implicit interface! implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

73. 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…

74. code is data data is code

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

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

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

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

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

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

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

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

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

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

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

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

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

88. macros

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

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

92. (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?

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

96. 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#))))))

97. 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#)))))) ‘(

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

99. 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__)))))

101. GC is great

102. runtime cost

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

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

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

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

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

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

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

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

111. // 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

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

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

114. // 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

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

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

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

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

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

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

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

122. // 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

123. // 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

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

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

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

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

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

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

132. borrowing rules see also http://bit.ly/1F6WBVD

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

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

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

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

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

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

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

140. F# ClojureErlang Go RustElm Idris !!!

141. seen generics? aka parametric polymorphism

142. List<T>

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

144. what if…

145. types that depend on arbitrary values?

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

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

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

149. Type Driven Development

150. making invalid state UNREPRESENTABLE

151. see also https://vimeo.com/123606435

153. Functional Reactive Programming

154. Value over Time

155. Time Value

156. Signals

157. Move Up Move Down

158. private var arrowKeyUp:Bool; private var arrowKeyDown:Bool; ! private var platform1:Platform; private var platform2:Platform; private var ball:Ball;

159. 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;! } }

160. function keyUp(event:KeyboardEvent):Void { if (event.keyCode == 38) { ! ! arrowKeyUp = false;! } else if (event.keyCode == 40) { ! ! arrowKeyDown = false;! } }

161. 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; } }

162. 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;! } }

163. source ﬁles state changes

164. source ﬁles execution

165. source ﬁles execution

166. mental model input state new state behaviour { x; y } { x; y-speed } { x; y } { x; y+speed } timer { x; y } { x; y } draw platform … … … …

167. transformation let y = f(x) Imperative Functional x.f() mutation

168. transformations simplify problem decomposition

169. Move Up Move Down

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

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

173. Keyboard.arrows UP { x=0, y=1 } DOWN { x=0, y=-1 } LEFT { x=-1, y=0 } RIGHT { x=1, y=0 }

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

178. see also http://oreil.ly/1i5CyhO

179. “I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.” - Alan Kay

180. “OOP to me means only messaging, local retention and protection and hiding of state- process, and extreme late- binding of all things.” - Alan Kay

182. actor model

183. actor state mailbox

184. actors share nothing

185. actor state mailbox actor

186. actor state mailbox actor

187. processing! storage! communication

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

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

195. start(N) ->! Kvs = spawn(mod, loop, [#{}]),! [spawn(mod, client, [X, Kvs]) ! || X <- lists:seq(1,N)].

196. actors are cheap

197. no locks!

198. need state?! talk to the actor!

199. location transparency

200. makes you ! THINK ! about ! distributed systems

201. messaging promotes failure thinking

202. Distributed Computing

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

204. supervise & restart

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

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

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

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

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

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

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

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

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

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

216. logic programming

217. stack-oriented programming

218. array programming

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

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

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

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

223. @theburningmonk theburningmonk.com github.com/theburningmonk

Tour of language landscape (katsconf)

You are reading a preview.

Tour of language landscape (katsconf)

More Related Content

Similar to Tour of language landscape (katsconf)

More from Yan Cui

Featured

Related Books

Related Audiobooks