Slide 2
Slide 2 text
@ArgesRic
What we’ll talk about
• Quick background on immutable data and FP.
• Advantages and trade-offs. i.e., “why bother?”
• Four simple things to put it in practice in an object-oriented
approach.
Slide 3
Slide 3 text
@ArgesRic
Getting to know each other
Slide 4
Slide 4 text
@ArgesRic
Anyone working without
garbage collection?
Slide 5
Slide 5 text
@ArgesRic
Who’s working on a functional
programming language?
Slide 6
Slide 6 text
@ArgesRic
What are you working on?
Python? Ruby? Java? C#?
Slide 7
Slide 7 text
@ArgesRic
Who is already using
immutable data somewhere?
Slide 8
Slide 8 text
@ArgesRic
About me
• Software engineer, run Numergent.
• Run project-specific, distributed development teams.
• Work mostly with data-oriented projects, on media, health care
information management, and financial companies.
• Doing software development professionally for 20+, hacking around
for longer.
Slide 9
Slide 9 text
@ArgesRic
My path here
Slide 10
Slide 10 text
@ArgesRic
Come for the functional way,
stay for the immutable data.
Slide 11
Slide 11 text
@ArgesRic
Realized immutable data made
code easier to refactor.
Slide 12
Slide 12 text
@ArgesRic
Slide 13
Slide 13 text
@ArgesRic
Slide 14
Slide 14 text
@ArgesRic
Slide 15
Slide 15 text
@ArgesRic
If you have mutable data,
you have to take things on faith.
Slide 16
Slide 16 text
@ArgesRic
Slide 17
Slide 17 text
@ArgesRic
Slide 18
Slide 18 text
@ArgesRic
Slide 19
Slide 19 text
@ArgesRic
Can a long-lived object trust we
won’t change its parameters?
Slide 20
Slide 20 text
@ArgesRic
Why immutable data?
Slide 21
Slide 21 text
@ArgesRic
There is no frictionless
movement.
Slide 22
Slide 22 text
@ArgesRic
Stop thinking about operations,
start thinking about results
Slide 23
Slide 23 text
@ArgesRic
Immutability
is not
statelessness
Slide 24
Slide 24 text
@ArgesRic
You have a state.
Your state is your world view.
Slide 25
Slide 25 text
@ArgesRic
When your state changes,
you don’t discard knowledge.
Slide 26
Slide 26 text
@ArgesRic
A functional approach
Slide 27
Slide 27 text
@ArgesRic
Many inputs, one single output.
Slide 28
Slide 28 text
@ArgesRic
Values are immutable.
Slide 29
Slide 29 text
@ArgesRic
Functions do not trigger any
state side-effects.
Slide 30
Slide 30 text
@ArgesRic
Functional is about semantics,
languages just help
Slide 31
Slide 31 text
@ArgesRic
“The most boring things in the
universe”
“Clojure is Boring”
Constantin Dumitrescu @ BucharestFP
https://8thlight.com/blog/colin-jones/2016/10/06/clojure-is-boring.html
Slide 32
Slide 32 text
@ArgesRic
Slide 33
Slide 33 text
@ArgesRic
Slide 34
Slide 34 text
@ArgesRic
Slide 35
Slide 35 text
@ArgesRic
Show of hands again…
C# / Java users.
Slide 36
Slide 36 text
@ArgesRic
Strings!
• Do you have a problem understanding how they work?
• Are you worried that they’ll be changed from under you?
• Are you concerned about using it as a key in a dictionary?
• Have you had to check the implementation?
• Do you think they are exciting?
Slide 37
Slide 37 text
@ArgesRic
Strings are boring, reliable,
immutable data items.
Slide 38
Slide 38 text
@ArgesRic
Slide 39
Slide 39 text
@ArgesRic
void DoSomethingToObject()
In-place Add/Remove
ref and out
Slide 40
Slide 40 text
@ArgesRic
Dealing with unknowns
Slide 41
Slide 41 text
@ArgesRic
Slide 42
Slide 42 text
@ArgesRic
Slide 43
Slide 43 text
@ArgesRic
For an unknown method:
1. Poke it.
2. Read it.
Slide 44
Slide 44 text
@ArgesRic
Being fully acquainted with the
code is the only option with
variable data.
Slide 45
Slide 45 text
@ArgesRic
1. Have access to every source
involved.
2. Have the time available.
Slide 46
Slide 46 text
@ArgesRic
There’s unknowns everywhere.
The larger the team, the more
unknowns.
Slide 47
Slide 47 text
@ArgesRic
1. Not everyone will understand
the subtleties of the language.
Slide 48
Slide 48 text
@ArgesRic
2. Not everyone will understand
the subtleties of your code base.
Slide 49
Slide 49 text
@ArgesRic
But…
Single Responsibility Principle!
Slide 50
Slide 50 text
@ArgesRic
Cross-cutting concerns make
Single Responsibility non-trivial.
Slide 51
Slide 51 text
@ArgesRic
Eventually, you’ll encapsulate
your herd of methods.
Slide 52
Slide 52 text
@ArgesRic
Encapsulation reduces mental
clutter.
It also obscures.
Slide 53
Slide 53 text
@ArgesRic
Readability is a matter of habit.
Slide 54
Slide 54 text
@ArgesRic
Not only Readability,
but
Comprehensibility.
Slide 55
Slide 55 text
@ArgesRic
Functional, the OOP way
Slide 56
Slide 56 text
@ArgesRic
1. Structs can be a gateway drug.
Slide 57
Slide 57 text
@ArgesRic
2. Don’t mutate your objects.
Slide 58
Slide 58 text
@ArgesRic
Vector.Normalize()
Vector.Normalized
Slide 59
Slide 59 text
@ArgesRic
employee.Salary += 100
Employee SalaryChange(float v)
employee.SalaryChange(100)
.SetPosition(newTitle)
.SetSomeProp(true)
Slide 60
Slide 60 text
@ArgesRic
3. Write to Enumerables, not to
Collections.
Slide 61
Slide 61 text
@ArgesRic
3.a. Use the functional facilities
for result generation (Where,
Select, etc).
Slide 62
Slide 62 text
@ArgesRic
4. Use immutable collections.
.Net: https://msdn.microsoft.com/en-us/library/system.collections.immutable(v=vs.111).aspx
Java: https://github.com/google/guava/wiki/ImmutableCollectionsExplained
Slide 63
Slide 63 text
@ArgesRic
http://clojure.org/
Slide 64
Slide 64 text
@ArgesRic
Where to do this?
Slide 65
Slide 65 text
@ArgesRic
Business logic?
Slide 66
Slide 66 text
@ArgesRic
Logic is about reasoning
according to strict principles of
validity.
Slide 67
Slide 67 text
@ArgesRic
UI?
Slide 68
Slide 68 text
@ArgesRic
UI should be about
representing state.
Slide 69
Slide 69 text
@ArgesRic
re-frame’s event conveyor belt
https://github.com/Day8/re-frame
Slide 70
Slide 70 text
@ArgesRic
“Oh well, that’s all fine for two
divs and a listbox”
Slide 71
Slide 71 text
@ArgesRic
Defold
https://www.youtube.com/watch?v=ajX09xQ_UEg
Slide 72
Slide 72 text
@ArgesRic
For a simple UI, anything will do.
For a complex UI,
immutability helps.
Slide 73
Slide 73 text
@ArgesRic
Data layer?
Slide 74
Slide 74 text
@ArgesRic
Slide 75
Slide 75 text
@ArgesRic
Where NOT to do this?
Slide 76
Slide 76 text
@ArgesRic
Is RAM a concern?
Is the GC hit a concern?
Is raw performance a concern?
Slide 77
Slide 77 text
@ArgesRic
Why do this?
Slide 78
Slide 78 text
@ArgesRic
Trading off GC hit for a codebase
that’s easier to reason about.
Slide 79
Slide 79 text
@ArgesRic
You’ll never have to wonder
about side-effects when
refactoring again.
Slide 80
Slide 80 text
@ArgesRic
You’ll write code that’s easier to
delete.
Slide 81
Slide 81 text
@ArgesRic
Easier threading.
Easier to offload processing.
Slide 82
Slide 82 text
@ArgesRic
"Who’s holding these objects?"
Who cares?
Slide 83
Slide 83 text
@ArgesRic
Immutable data lets you focus
on comprehension,
not memorization.
Slide 84
Slide 84 text
@ArgesRic
Conclusions
Slide 85
Slide 85 text
@ArgesRic
Immutability frees you to change
your mind.
Slide 86
Slide 86 text
@ArgesRic
To be in control, you have to know.
Variability demands you take
things on faith.
Slide 87
Slide 87 text
@ArgesRic
Try some functional patterns.
Replace trust with certainty.
Slide 88
Slide 88 text
@ArgesRic
Questions?
Slide 89
Slide 89 text
@ArgesRic
Thank you!
Ricardo J. Méndez
[email protected]
https://speakerdeck.com/ricardojmendez/flexibility-through-immutability