Why Functional Programming Matters

Ramblings on the subject of "why FP matters"

Transcript

1. Why FP Matters and everyone should learn more of it
3. Major Concepts
4. Expressions, not assignments FP encourages thinking in results of evaluation, rather than assigning results to re-assignable variables
5. Example Recursive computation
6. (def map! (fn [f coll]! (if (empty? coll) (quote ())! (cons (f (first coll))! (map f (next coll))))))!
7. Outcome Easier composition Less errors (no way to modify result in-between calls)
8. How to do, not what to do FP discourages operational reasoning, promotes algorithmical reasoning
9. Example Evaluation
10. In Java You write a sequences of steps requiring for solving the problem
11. In Haskell You write resolution formulas
12. In Haskell You write resolution formulas
13. eval closure sym@(LispSymbol _) eval :: [LispEnvironment] -> LispExpression -> State LispEnvironment LispExpression eval closure (LispList[(ReservedKeyword FnKeyword), LispVector bindings, form])
14. Outcome Obvious problem description, based on signatures Matching logic doesn’t involve if/else statements Logic is inherently recursive
15. Function composition FP encourages function, rather than object composition
16. Example Routing: URL parsing + handler logic
17. (compojure/defroutes main-routes! (GET root "/" request (index request))! (GET search "/search" request (search request)))
18. Outcome Both handlers and parsing logic is reusable Testing handlers doesn’t involve any additional object composition
19. Primitives FP encourages using language primitives, such as keywords (lightweight strings), lists, maps instead of heavy objects
20. Outcome Adapter logic is just a transformation Reusability increases Easier composition
21. Powerful collection fns All Functional languages have amazingly powerful collection manipulation primitives, such as filter/map/reduce, which always involves conditionals, mutable state, loops and so on.
22. Outcome Obvious results Thinking in patterns Reusability, describing processes as sequence of steps Many opportunities instead of a single “for” loop
23. Inherently concurrent FP languages do not let you modify state, which prevents using locking structures, synchronisation primitives and allows thinking of state as “value at a time”
24. Outcome Easier to scale Everything is paralellisable
25. Different polymorphism In different languages, there are different means. For example, in Clojure you have protocols and multimethods, in Haskell - algebraic data types, type classes and pattern matching
26. Outcome Dispatch rarely involves any if/else statements It’s easier to refactor functions to use a common protocol or implement a type class / ADT
27. Partial evaluation / currying Concept that requires lots of bells and whistles in Java In both Clojure and Haskell, you can split a function to sequence of partial evaluation calls
28. Outcome It’s possible to return a partial evaluation result, and act on it as if it was a future, evaluating it till the end as the rest of args pop in
29. Lazy evaluation Despite the fact the concept is extremely easy, it’s seldom used in imperative languages. Most FP languages have built-in primitives for `next` calculation
30. Example Byte Buffer position generation
31. (defn positions! "Returns a lazy sequence containing positions of elements"! [types]! ((fn rpositions [[t & more] current-pos]! (when t! (cons current-pos ! ! ! ! ! (lazy-seq ! ! ! ! ! (rpositions more (+ current-pos (size t))))))) types 0))
32. Outcome Infinite data structures No mutable state during `next` generation Generator is easy to read and modify, knowing the semantics No leaks, no accidental captures
33. Predictable output Because of lack of side-effects, functions generally produce single output for same input
34. Outcome Easier to test Easier to debug Smaller error rate Determinism / potential for optimisation Easier to prove program correctness
35. Why it matters for us?
36. Patterns In Consulting, it’s important to identify problem fast and provide an easily explainable solution
37. Knowing it before them Adoption of FP languages is growing every day. Not being able to provide services will leave us with limited business opportunities.
38. Rapid Prototyping FP languages allow you to express a problem fast, with minimal effort and provide a working result quicker than imperative one
39. Mind Flexibility Being able to approach the problem from different perspective never hurts
40. FP In Java Reactor is one of my favourite examples of using FP paradigms even in Java 7. Java 8 and lambdas is a step forward. Being able to use them knowing the context of where they’re coming from opens up a lot of possibilities.
41. Reactive programming Reactive programming also grows from FP. Having a function as a callback was used singe ages in FP.
42. Having more fun @ work Self-explanatory
43. Questions?