Outcome
Both handlers and parsing logic is reusable
Testing handlers doesn’t involve any additional object composition
Slide 19
Slide 19 text
Primitives
FP encourages using language primitives, such as
keywords (lightweight strings), lists, maps instead of heavy objects
Slide 20
Slide 20 text
Outcome
Adapter logic is just a transformation
Reusability increases
Easier composition
Slide 21
Slide 21 text
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.
Slide 22
Slide 22 text
Outcome
Obvious results
Thinking in patterns
Reusability, describing processes as sequence of steps
Many opportunities instead of a single “for” loop
Slide 23
Slide 23 text
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”
Slide 24
Slide 24 text
Outcome
Easier to scale
Everything is paralellisable
Slide 25
Slide 25 text
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
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
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
Slide 28
Slide 28 text
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
Slide 29
Slide 29 text
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
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
Slide 33
Slide 33 text
Predictable output
Because of lack of side-effects, functions generally produce single
output for same input
Slide 34
Slide 34 text
Outcome
Easier to test
Easier to debug
Smaller error rate
Determinism / potential for optimisation
Easier to prove program correctness
Slide 35
Slide 35 text
Why it matters for us?
Slide 36
Slide 36 text
Patterns
In Consulting, it’s important to identify problem fast and provide an
easily explainable solution
Slide 37
Slide 37 text
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.
Slide 38
Slide 38 text
Rapid Prototyping
FP languages allow you to express a problem fast, with minimal
effort and provide a working result quicker than imperative one
Slide 39
Slide 39 text
Mind Flexibility
Being able to approach the problem from different perspective never
hurts
Slide 40
Slide 40 text
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.
Slide 41
Slide 41 text
Reactive programming
Reactive programming also grows from FP.
Having a function as a callback was used singe ages in FP.