Clojure(script) and Functional Programming

Clojure(script)
and Functional Programming
(for anyone who hasn’t done it before)

Transcript

1. Clojure(script) and Functional Programming (for anyone who hasn’t done it before) Thursday, February 21, 13
2. expectations Thursday, February 21, 13
3. • imma talk on Functional Programming rather than ClojureScript • if you don’t buy FP, you won’t benefit from CS • if you buy FP, you can benefit even without using CS • from backend development experience • more relevant for parallel systems Setting expectations Thursday, February 21, 13
4. WORA (write once run anywhere thingie) Thursday, February 21, 13
5. • imma talk on Functional Programming rather than ClojureScript • if you don’t buy FP, you won’t benefit from CS • if you buy FP, you can benefit even without using CS • from backend development experience • more relevant for parallel systems WORA Thursday, February 21, 13
6. Client Side development is simple(r) (depending on what you do YMMV, but most of time you don’t push thousands of messages or process TBs of data through browser) Thursday, February 21, 13
7. • DOM Manipulation • Reacting upon events • Rendering • Request/response • Adding interactivity Client Side stuff (simplified) Thursday, February 21, 13
8. Server Side (backend) development is hard(er) (unless you mostly do CRUD) Thursday, February 21, 13
9. • Streaming • Crunching (lots of) data • Persisting data • Validating user input • Doing stuff in parallel Interesting Problems arising on Server Side Thursday, February 21, 13
10. Functional programming makes things easier Thursday, February 21, 13
11. Web talk, right? Thursday, February 21, 13
12. Typical server-side use-cases Get a request Parse it Run through middlewares Thursday, February 21, 13
13. What do your middlewares look like? Thursday, February 21, 13
14. In world of objects and prototypes (let's say it's pseudocode) Thursday, February 21, 13
15. var BaseMiddleware = Object.extend({ init: function(app){ this.app = app; }, process: function(env){ // do pre-processing ... this.app(env); // or skip // do post-processing } }); Thursday, February 21, 13
16. var CookieMiddleware = BaseMiddleware.extend({ process: function(env){ // do cookie-related things, prepare // for handler this.app(env); // or skip // do more cookie-related stuff, // prepare for response } }); Thursday, February 21, 13
17. More functional approach Thursday, February 21, 13
18. var handler = function (env) { // Do something with env }; function wrapCookies(fn) { var f = function (env) { // do cookie-related things, // prepare for handler fn(env); // do more cookie-related stuff, // prepare for response } return f; } // Run! wrapCookies(handler)(env); Thursday, February 21, 13
19. (defn handler [env] ;; do something ) (defn wrap-cookies [f] (fn [request] ;; do cookie-related things, ;; prepare for handler (f env) ;; do more cookie-related stuff, ;; prepare for response ) Thursday, February 21, 13
20. What does it give you? Thursday, February 21, 13
21. • less code • separation of concerns (no coupling of verbs with nouns) • => no objects that could potentially store state • => no side effects • easy to test in isolation • easy to compose and reuse • easy to reproduce flows What does it give you? Thursday, February 21, 13
22. Side effects add fun to your callback hell! Thursday, February 21, 13
23. var counter = 1; // Somewhere in a galaxy far, far away // ... someobj.doSomething(obj, {callback: function () { // debug it, suckers counter++; }}); Thursday, February 21, 13
24. Could be represented as: Thursday, February 21, 13
25. var a = {}; function changeIt (b) { b["wat"] = "yo" } changeIt(a) a // Object {wat: "yo"} Thursday, February 21, 13
26. THAT IS ENTIRELY WHAT I EXPECTED! Thursday, February 21, 13
27. • closures allow handler/callback function to mess up your scope • they work well only when enclosed values don't change • mutable objects lead to unpredictable behavior (state sucks) • when you set something, second later you're not sure anymore if it's still set What does it give you? Thursday, February 21, 13
28. D00d! I'm smarter than that! Thursday, February 21, 13
29. Sure you are. Thursday, February 21, 13
30. Your runtime isn't. Thursday, February 21, 13
31. Being careful is safer than overconfident. Thursday, February 21, 13
32. Typical server-side use-cases Get data Transform it Save it, or show it Thursday, February 21, 13
33. In world of objects and prototypes (let's say it's pseudocode) Thursday, February 21, 13
34. var books = [ {title: "hitchhiker's guide to the galaxy", author: {name: "Douglas Adams", birth_year: 1952} }, {title: "Ender's game", author: {name: "Orson Scott Card", birth_year: 1951} }]; _.each(books, function(book) { book.author.age = 2013 - book.author.birth_year; }); Thursday, February 21, 13
35. • mostly unpredictable • array may change during iteration Thursday, February 21, 13
36. But even that’d be not as bad! Thursday, February 21, 13
37. Noun + Verb = <3 ? Thursday, February 21, 13
38. class Person name birth_date age: function () ... Thursday, February 21, 13
39. Does age belong to Person?.. Thursday, February 21, 13
40. class Tree planted_at age: function () Thursday, February 21, 13
41. Polymorphism Thursday, February 21, 13
42. (defprotocol Age (age [o])) (extend-protocol Age Person (age [o] ;; impl... ) Tree (age [o] ;; impl... )) Thursday, February 21, 13
43. • coupling data with actions is (usually) not side-effect free • decoupling data from functions doesn’t mean you can’t dispatch on type anymore • even if your data is decoupled from action, doesn’t guarantee it doesn’t change Thursday, February 21, 13
44. Typical server-side use-cases Get data from user Validate it Thursday, February 21, 13
45. class Model validate: () => unless (this.emailValid (this.email)) @errors["email"] = "Email is invalid" Thursday, February 21, 13
46. • in 99% of cases, coupled with Model (mixins do not change fact of coupling) • change internal state • implementer has to remember to clear errors on reload or state change • potentially destructive against the Model • code reuse would require implementing abstraction on higher level (base class or helper) Thursday, February 21, 13
47. • functional way is simpler • does not affect validated object (immutability) • trivial to test • always yields same result given same input (can’t give same guarantee with shared state) • reusable/composable right away • always operating primitives, easy to understand Thursday, February 21, 13
48. Typical server-side use-cases Receive request Pass it through filters Trigger controller call Thursday, February 21, 13
49. // Pseudo-code, no real framework kept in mind :P class OrderController before_filter signed_in_only, fetch_order signed_in_only: ()-> ... fetch_order: ()-> @order = Database.get_me_order(params.id) ... update: ()-> @order ... Thursday, February 21, 13
50. • try to test dat • oh right, I’ll just take a framework that will test it all for me • can you rely on the presence of @order? • or on its consistency? • explicit vs implicit function calls • testing chained calls that rely on state is extremely hard • even implementing can be tricky Thursday, February 21, 13
51. • functional approach: explicit function calls, threading • test in isolation • no shared/mutable state • predictable results • obvious outcome • local bindings for shared state • refs/atoms for transactional mutable state • if STM doesn’t work well for your use-case (too many interleaving state) changes, use message passing Thursday, February 21, 13
52. Typical server-side use-cases Data processing Thursday, February 21, 13
53. • use lazy sequences where possible • in essence, lazy sequence is • already calculated part • function to yield next part • controlling flow, avoiding fetching/calculation when you got enough data • avoid needless calculations • (potentially) infinite data structures • (potentially) smaller memory footprint • use chunks to win performance, when you need to prefetch more than just next step Thursday, February 21, 13
54. Typical server-side use-cases Mutable local state Thursday, February 21, 13
55. • break down your code to smaller steps • understand and isolate changes to data structure • when changes are isolated, compose them with mapper/ reducer/merger or any other mean Thursday, February 21, 13
56. Immutability, Persistent DSs Thursday, February 21, 13
57. • Changing state doesn't discard old value • You have 5EUR at 13:55 today • You got 10EUR from a friend at 14:00 • Doesn't change the fact you had 5EUR at 13:55 Thursday, February 21, 13
58. {:a 1} Thursday, February 21, 13
59. {:a 1} Thursday, February 21, 13
60. {:a 1 :b 2} {:a 1 :c 3} Thursday, February 21, 13
61. (def a ‘(1 2 3)) 3 a 2 1 Thursday, February 21, 13
62. (def a ‘(1 2 3)) (def b (cons 4 a)) 3 a 2 1 b 4 Thursday, February 21, 13
63. (def a ‘(1 2 3)) (def b (cons 4 a)) (def c (cons 5 (rest a)) 3 a 2 1 b 4 c 5 Thursday, February 21, 13
64. • doesn’t have anything to do with disk persistence • efficient creation of “modified” versions • structural sharing • inherently thread & iteration-safe will not mutate in a middle • immutable modification yields new coll • composite • No need for defensive copy • Referential Transparency Thursday, February 21, 13
65. Function composition Thursday, February 21, 13
66. (empty? []) (def not-empty? (complement empty?)) Thursday, February 21, 13
67. (reduce + arr) ;; + is a function, passed to reduce (map inc [1 2 3]) ;; => (2 3 4) Thursday, February 21, 13
68. (def people [{:name "Alex" :age 26 :occupation :hacker} {:name "Nick" :age 19 :occupation :student} {:name "Ron" :age 27 :occupation :doctor}]) (def youngster? #(< (:age %) 25)) (def hacker? #(= :hacker (:occupation %))) (defn filter-people [f people] (filter f people)) (filter-people youngster? people) ;; => ({:age 19, :name "Nick"}) (filter-people (complement youngster?) people) ;; => ({:age 26, :name "Alex"} {:age 27, :name "Ron"}) Thursday, February 21, 13
69. (def people [{:name "Alex" :age 26 :occupation :hacker} {:name "Nick" :age 19 :occupation :student} {:name "Ron" :age 27 :occupation :doctor}]) (defn filter-people [coll & predicates] (filter #(every? true? ((apply juxt predicates) %)) coll)) ;; ((juxt a b c) x) => [(a x) (b x) (c x)] (filter-people people hacker? (complement youngster?)) Thursday, February 21, 13
70. (def hundred-times (partial * 100)) (hundred-times 5) ;; => 500 Thursday, February 21, 13
71. • simplifies code • makes interface easier to understand • (very) reusable building blocks • smaller pieces are easier to test, write and understand • fns may take fns as arguments Thursday, February 21, 13
72. Macros Thursday, February 21, 13
73. ;; Simplest macro? (defmacro call [form x] (list form x)) (call inc 1) ;; => 2 Thursday, February 21, 13
74. ;; From Clojure.core, bit shortened (defmacro -> ([x] x) ([x form] (if (seq? form) `(~(first form) ~x ~@(next form)) (list form x))) ([x form & more] `(-> (-> ~x ~form) ~@more))) (-> 1 inc inc dec) ;; => 2 Thursday, February 21, 13
75. (defmacro when [test & body] (list 'if test (cons 'do body))) (when (too-cool?) (give-me-more!) (and-more!)) Thursday, February 21, 13
76. (defmacro time [expr] `(let [start# (. System (nanoTime)) ret# ~expr] (prn (str "Elapsed time: " (- (. System (nanoTime)) start#)) " msecs")) ret#)) (time (* 1 10000000)) ;; "Elapsed time: 0.021 msecs" ;; => 10000000 Thursday, February 21, 13
77. destructuring Thursday, February 21, 13
78. (def arr ["first" "second" "third"]) (let [[first second third] arr] (println first) ;; "first" (println second) ;; "second" (println third) ;; "third" ) Thursday, February 21, 13
79. (def m {:first 1 :second 2 :third 3}) (let [{:keys [first second third] :as all} m] (println first) ;; 1 (println second) ;; 2 (println third) ;; 3 (println all) ;; {:first 1 :second 2 :third 3} ) Thursday, February 21, 13
80. (map (fn [[k v]] (println k “=” v)) {:first 1 :second 2 :third 3}) ;; :first = 1 ;; :second = 2 ;; :third = 3} Thursday, February 21, 13
81. Thursday, February 21, 13
82. ifesdjeen clojurewerkz / / michaelklishin / Also, you should follow Thursday, February 21, 13