Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Adopting FP: the good, the familiar, and the unknown

Adopting FP: the good, the familiar, and the unknown

Colin Jones

July 21, 2016
Tweet

More Decks by Colin Jones

Other Decks in Programming

Transcript

  1. immutability def get_client_id(params) params[:warehouse][:client_id] end def test_client_id_equality params = {warehouse:

    {client_id: 42}} client_id_1 = get_client_id(params) client_id_2 = get_client_id(params) assert_equal(client_id_1, client_id_2) end
  2. immutability def get_client_id(params) params[:warehouse].delete(:client_id) end def test_client_id_equality params = {warehouse:

    {client_id: 42}} client_id_1 = get_client_id(params) client_id_2 = get_client_id(params) assert_equal(client_id_1, client_id_2) end
  3. immutability (deftest test-client-id-equality (let [params {:warehouse {:client-id 42}} client-id-1 (get-client-id

    params) client-id-2 (get-client-id params)] (is (= client-id-1 client-id-2))))
  4. immutability (defn- get-item-value [item] (* (:price item) (:quantity-available item))) (defn

    get-total-value [inventory] (->> (:items inventory) (map get-item-value) (reduce +)))
  5. immutability (let [params {:warehouse {:client-id 42}} updated (update-in params [:warehouse

    :client-id] inc)] (println "params:" (pr-str params)) (println "updated:" (pr-str updated))) ;; params: {:warehouse {:client-id 42}} ;; updated: {:warehouse {:client-id 43}} ;; => nil
  6. #1 hit benefits safer concurrency / parallelism simplicity / clarity

    easier testing / modularity useful constraints
  7. OO Principles DRY 4 rules of simple design command-query separation

    SOLID principles package principles code smells refactorings
  8. OO FP Software Principles DRY 4 rules of simple design

    command-query separation SOLID principles package principles code smells refactorings
  9. Example: Dependency Inversion Principle A. High level modules should not

    depend upon low level modules. Both should depend upon abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions.
  10. What is an "abstraction"? interfaces (Java, …) classes w/ only

    pure virtual methods (C++, …) duck typing (Ruby, …)
  11. What is an "abstraction"? duck typing (Erlang, Elixir, …) generic

    types (Haskell, Elm, F#, …) protocols (Clojure, Swift, Elixir, …) multimethods (Clojure, CLOS, …) typeclasses (Haskell, …) signatures (ML, OCaml, …) behaviours (Erlang, …) functions (we all have these!!!)
  12. Reading "Why Functional Programming Matters" by John Hughes https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf "What

    is Functional Programming?" by Kris Jenkins http://blog.jenkster.com/2015/12/what-is-functional-programming.html "Go To Statement Considered Harmful" by Edsger Dijkstra http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf "Understanding Clojure's Persistent Vectors" by Jean-Niklas L'Orange http://hypirion.com/musings/understanding-persistent-vector-pt-1 "Clojure Protocols" by Stuart Halloway http://gotocon.com/dl/jaoo-aarhus-2010/slides/StuartHalloway_ClojureProtocolsArenotInterfaces.pdf "Choose Boring Technology" by Dan McKinley http://mcfunley.com/choose-boring-technology