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

Flexibility Through Immutability

Flexibility Through Immutability

While immutable data is a key part of purely functional programming languages, coming from a purely variable background can make it initially seem extremely constraining. We’ll explore how, on the contrary, it can bring an amount of freedom and flexibility to how you structure your application, reducing an entire class of problems that would otherwise tie your hands and limit your options.

Ricardo J. Méndez

May 20, 2016
Tweet

More Decks by Ricardo J. Méndez

Other Decks in Technology

Transcript

  1. Flexibility Through
    Immutability
    Ricardo J. Méndez
    [email protected]

    View full-size slide

  2. @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.

    View full-size slide

  3. @ArgesRic
    Getting to know each other

    View full-size slide

  4. @ArgesRic
    Anyone working without
    garbage collection?

    View full-size slide

  5. @ArgesRic
    Who’s working on a functional
    programming language?

    View full-size slide

  6. @ArgesRic
    What are you working on?
    Python? Ruby? Java? C#?

    View full-size slide

  7. @ArgesRic
    Who is already using
    immutable data somewhere?

    View full-size slide

  8. @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.

    View full-size slide

  9. @ArgesRic
    My path here

    View full-size slide

  10. @ArgesRic
    Come for the functional way,
    stay for the immutable data.

    View full-size slide

  11. @ArgesRic
    Realized immutable data made
    code easier to refactor.

    View full-size slide

  12. @ArgesRic
    If you have mutable data,
    you have to take things on faith.

    View full-size slide

  13. @ArgesRic
    Can a long-lived object trust we
    won’t change its parameters?

    View full-size slide

  14. @ArgesRic
    Why immutable data?

    View full-size slide

  15. @ArgesRic
    There is no frictionless
    movement.

    View full-size slide

  16. @ArgesRic
    Stop thinking about operations,
    start thinking about results

    View full-size slide

  17. @ArgesRic
    Immutability 

    is not 

    statelessness

    View full-size slide

  18. @ArgesRic
    You have a state.
    Your state is your world view.

    View full-size slide

  19. @ArgesRic
    When your state changes,
    you don’t discard knowledge.

    View full-size slide

  20. @ArgesRic
    A functional approach

    View full-size slide

  21. @ArgesRic
    Many inputs, one single output.

    View full-size slide

  22. @ArgesRic
    Values are immutable.

    View full-size slide

  23. @ArgesRic
    Functions do not trigger any
    state side-effects.

    View full-size slide

  24. @ArgesRic
    Functional is about semantics,
    languages just help

    View full-size slide

  25. @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

    View full-size slide

  26. @ArgesRic
    Show of hands again…
    C# / Java users.

    View full-size slide

  27. @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?

    View full-size slide

  28. @ArgesRic
    Strings are boring, reliable,
    immutable data items.

    View full-size slide

  29. @ArgesRic
    void DoSomethingToObject()
    In-place Add/Remove


    ref and out

    View full-size slide

  30. @ArgesRic
    Dealing with unknowns

    View full-size slide

  31. @ArgesRic
    For an unknown method:
    1. Poke it.
    2. Read it.

    View full-size slide

  32. @ArgesRic
    Being fully acquainted with the
    code is the only option with
    variable data.

    View full-size slide

  33. @ArgesRic
    1. Have access to every source
    involved.
    2. Have the time available.

    View full-size slide

  34. @ArgesRic
    There’s unknowns everywhere.
    The larger the team, the more
    unknowns.

    View full-size slide

  35. @ArgesRic
    1. Not everyone will understand
    the subtleties of the language.

    View full-size slide

  36. @ArgesRic
    2. Not everyone will understand
    the subtleties of your code base.

    View full-size slide

  37. @ArgesRic
    But…


    Single Responsibility Principle!

    View full-size slide

  38. @ArgesRic
    Cross-cutting concerns make
    Single Responsibility non-trivial.

    View full-size slide

  39. @ArgesRic
    Eventually, you’ll encapsulate
    your herd of methods.

    View full-size slide

  40. @ArgesRic
    Encapsulation reduces mental
    clutter.
    It also obscures.

    View full-size slide

  41. @ArgesRic
    Readability is a matter of habit.

    View full-size slide

  42. @ArgesRic
    Not only Readability,
    but
    Comprehensibility.

    View full-size slide

  43. @ArgesRic
    Functional, the OOP way

    View full-size slide

  44. @ArgesRic
    1. Structs can be a gateway drug.

    View full-size slide

  45. @ArgesRic
    2. Don’t mutate your objects.

    View full-size slide

  46. @ArgesRic
    Vector.Normalize()
    Vector.Normalized

    View full-size slide

  47. @ArgesRic
    employee.Salary += 100
    Employee SalaryChange(float v)
    employee.SalaryChange(100)
    .SetPosition(newTitle)

    .SetSomeProp(true)

    View full-size slide

  48. @ArgesRic
    3. Write to Enumerables, not to
    Collections.

    View full-size slide

  49. @ArgesRic
    3.a. Use the functional facilities
    for result generation (Where,
    Select, etc).

    View full-size slide

  50. @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

    View full-size slide

  51. @ArgesRic
    http://clojure.org/

    View full-size slide

  52. @ArgesRic
    Where to do this?

    View full-size slide

  53. @ArgesRic
    Business logic?

    View full-size slide

  54. @ArgesRic
    Logic is about reasoning
    according to strict principles of
    validity.

    View full-size slide

  55. @ArgesRic
    UI?

    View full-size slide

  56. @ArgesRic
    UI should be about 

    representing state.

    View full-size slide

  57. @ArgesRic
    re-frame’s event conveyor belt
    https://github.com/Day8/re-frame

    View full-size slide

  58. @ArgesRic
    “Oh well, that’s all fine for two
    divs and a listbox”

    View full-size slide

  59. @ArgesRic
    Defold
    https://www.youtube.com/watch?v=ajX09xQ_UEg

    View full-size slide

  60. @ArgesRic
    For a simple UI, anything will do.


    For a complex UI, 

    immutability helps.

    View full-size slide

  61. @ArgesRic
    Data layer?

    View full-size slide

  62. @ArgesRic
    Where NOT to do this?

    View full-size slide

  63. @ArgesRic
    Is RAM a concern?
    Is the GC hit a concern?
    Is raw performance a concern?

    View full-size slide

  64. @ArgesRic
    Why do this?

    View full-size slide

  65. @ArgesRic
    Trading off GC hit for a codebase
    that’s easier to reason about.

    View full-size slide

  66. @ArgesRic
    You’ll never have to wonder
    about side-effects when
    refactoring again.

    View full-size slide

  67. @ArgesRic
    You’ll write code that’s easier to
    delete.

    View full-size slide

  68. @ArgesRic
    Easier threading.
    Easier to offload processing.

    View full-size slide

  69. @ArgesRic
    "Who’s holding these objects?"


    Who cares?

    View full-size slide

  70. @ArgesRic
    Immutable data lets you focus
    on comprehension,

    not memorization.

    View full-size slide

  71. @ArgesRic
    Conclusions

    View full-size slide

  72. @ArgesRic
    Immutability frees you to change
    your mind.

    View full-size slide

  73. @ArgesRic
    To be in control, you have to know.
    Variability demands you take
    things on faith.

    View full-size slide

  74. @ArgesRic
    Try some functional patterns.
    Replace trust with certainty.

    View full-size slide

  75. @ArgesRic
    Questions?

    View full-size slide

  76. @ArgesRic
    Thank you!
    Ricardo J. Méndez
    [email protected]
    https://speakerdeck.com/ricardojmendez/flexibility-through-immutability

    View full-size slide