Lochemem Bruno Michael
PHP enthusiast from Kampala, Uganda
Slide 3
Slide 3 text
Functional Programming, huh?
● A declarative programming paradigm
● Mandates that pure functions be written
● Saliently features the use of expressions
● Emphasizes the importance of composition
Slide 4
Slide 4 text
What are the benefits?
● Functional Programming helps address complexity
○ Complexity often deters project advancement
○ Functions exist only as callable units and do not affect histories
● FP techniques truncate the cognitive load of developing software
○ Short-term memory is a finite resource
○ FP conditions one to parameterize constructs
○ The paradigm sturdies one’s intellection when writing programs
Slide 5
Slide 5 text
4-7
Quanta in working memory models
Slide 6
Slide 6 text
All of this in PHP?
Slide 7
Slide 7 text
Expressions
Slide 8
Slide 8 text
First-class
functions
Slide 9
Slide 9 text
Do not forget
everything you know
about programming!
Slide 10
Slide 10 text
Functions
everywhere!
Slide 11
Slide 11 text
User-defined
functions
Slide 12
Slide 12 text
Anonymous
functions
Slide 13
Slide 13 text
Class methods
Slide 14
Slide 14 text
Keep the functions
pure, please!
Side effects
Side causes
Slide 15
Slide 15 text
Not so pure!
● Mutable global variable
(side-cause)
● Value mutated after function is
called (side-effect)
Slide 16
Slide 16 text
An improvement?
● Use a closure
● Mutate only within the function
Slide 17
Slide 17 text
Parameterize the
things!
Slide 18
Slide 18 text
Another fix?
● Parameterize the accumulator
● Return one integer for every
$x-$acc parameter
combination
Slide 19
Slide 19 text
Every argument
input should yield
the same output.
Slide 20
Slide 20 text
What about
classes?
Slide 21
Slide 21 text
Also not pure!
● Setter mutates internal state
whenever invoked
● Each setter call increases
temporal coupling
Slide 22
Slide 22 text
The cardinal rule
of purity still
applies!
Slide 23
Slide 23 text
Either
● Remove the setter
● Single $empName value for
each object
Slide 24
Slide 24 text
Or
● Make the setter a pure
function
● Create new copy of
Employee
Slide 25
Slide 25 text
Pure Functions
● Do not create side-effects
● Yield the same output given the same input
● Are referentially transparent
Slide 26
Slide 26 text
Compose the
functions!
f(x) = x + 1
g(x) = 2x
f ∘ g = f(g(x))
Slide 27
Slide 27 text
“If you’re chaining, you’re composing”
- From Eric Elliott in Composing Software: An Introduction
Slide 28
Slide 28 text
Traditionally
● Invoke functions as function
arguments
● Cumbersome to deal with
long chains
Slide 29
Slide 29 text
Approaching
helper library
territory!
Slide 30
Slide 30 text
Point-free?
● No explicit parameter
mentions
● Seemingly more compact
Slide 31
Slide 31 text
const for
functions?
Slide 32
Slide 32 text
Some FP sauce to add to your program
● Partial application
● Currying
● Map, Filter, Fold/Reduce
● Pattern Matching
● Persistent Data Structures
Slide 33
Slide 33 text
You might have
used some of
these techniques
before.
Slide 34
Slide 34 text
Currying
● Decompose a function into a
series of sub-functions
● Each sub-function takes one
argument
Slide 35
Slide 35 text
Partial Application
● Similar to currying
● Also useful for deferred function
calls
● Each sub-function has variable
arity
Slide 36
Slide 36 text
Map, Filter, Fold
● Higher-order functions for array
transformations
● Highly composable
● Single iteration for every
transformation
Slide 37
Slide 37 text
Pattern Matching
● Native support in pure FP
languages
● Useful whenever data has
discernible patterns
● Especially good for flow-control
● Composable, as a function
Slide 38
Slide 38 text
Immutable Lists
● Persistent data structure
● Each transformation outputs a
new copy
● Single iteration for each
transformation
Slide 39
Slide 39 text
Real world IO is
messy!
Slide 40
Slide 40 text
Messy, huh? Why?
● Many operations are inherently impure
● Exceptions - used commonly - are also inherently impure
● IO can get complicated
Slide 41
Slide 41 text
Impure IO?
● Filesystem interaction
● Writing to and reading from standard output and standard input
● Opening windows
● Database interactions
Slide 42
Slide 42 text
Exceptions
● Inherently impure
● Not good for function chains
Slide 43
Slide 43 text
How you can cope with this
● Use functors and monads
● Parameterize (might lead to callback hell)
● Favor composition with forward function chaining
● Use persistent data structures
Slide 44
Slide 44 text
Functor
● Something you can map over
● Typically a type class
● A type of category
● Supports forward chaining
Slide 45
Slide 45 text
Monad
● A special type of functor
● Convenient because of inherent
ad-hoc value
● Especially good for flow-control
Slide 46
Slide 46 text
Real world monads
● Either and Maybe union types
● IO monad
● State monad
● Reader monad
● Writer monad
Slide 47
Slide 47 text
Either and Maybe
Types
● Great for error handling
● Emphasize writing two-track
functions (Railway pattern)
Slide 48
Slide 48 text
IO Monad
● Great for IO-related tasks
● Encapsulated within the monad
is an executable function
Slide 49
Slide 49 text
State Monad
● Stores an initial state
● Transforms copies of initial state
in separate container
Slide 50
Slide 50 text
Reader Monad
● Useful for sharing data amongst
functions
● Akin to Dependency Injection (DI)
in OO
Slide 51
Slide 51 text
Writer Monad
● Great for logging data
● Can, in some contexts, be used
for event sourcing
Slide 52
Slide 52 text
How do I know I’m doing it right?
The functions you write should have the following qualities:
● Purity
● Referential Transparency
● Composability
● Conciseness