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


  1. Flexibility Through Immutability Ricardo J. Méndez ricardo@numergent.com

  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.
  3. @ArgesRic Getting to know each other

  4. @ArgesRic Anyone working without garbage collection?

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

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

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

  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.
  9. @ArgesRic My path here

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

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

  12. @ArgesRic

  13. @ArgesRic

  14. @ArgesRic

  15. @ArgesRic If you have mutable data, you have to take

    things on faith.
  16. @ArgesRic

  17. @ArgesRic

  18. @ArgesRic

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

  20. @ArgesRic Why immutable data?

  21. @ArgesRic There is no frictionless movement.

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

  23. @ArgesRic Immutability 
 is not 

  24. @ArgesRic You have a state. Your state is your world

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

  26. @ArgesRic A functional approach

  27. @ArgesRic Many inputs, one single output.

  28. @ArgesRic Values are immutable.

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

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

  31. @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
  32. @ArgesRic

  33. @ArgesRic

  34. @ArgesRic

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

  36. @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?
  37. @ArgesRic Strings are boring, reliable, immutable data items.

  38. @ArgesRic

  39. @ArgesRic void DoSomethingToObject() In-place Add/Remove
 ref and out

  40. @ArgesRic Dealing with unknowns

  41. @ArgesRic

  42. @ArgesRic

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

  44. @ArgesRic Being fully acquainted with the code is the only

    option with variable data.
  45. @ArgesRic 1. Have access to every source involved. 2. Have

    the time available.
  46. @ArgesRic There’s unknowns everywhere. The larger the team, the more

  47. @ArgesRic 1. Not everyone will understand the subtleties of the

  48. @ArgesRic 2. Not everyone will understand the subtleties of your

    code base.
  49. @ArgesRic But…
 Single Responsibility Principle!

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

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

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

  53. @ArgesRic Readability is a matter of habit.

  54. @ArgesRic Not only Readability, but Comprehensibility.

  55. @ArgesRic Functional, the OOP way

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

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

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

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

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

  61. @ArgesRic 3.a. Use the functional facilities for result generation (Where,

    Select, etc).
  62. @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

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

  64. @ArgesRic Where to do this?

  65. @ArgesRic Business logic?

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

  67. @ArgesRic UI?

  68. @ArgesRic UI should be about 
 representing state.

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

  70. @ArgesRic “Oh well, that’s all fine for two divs and

    a listbox”
  71. @ArgesRic Defold https://www.youtube.com/watch?v=ajX09xQ_UEg

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

    a complex UI, 
 immutability helps.
  73. @ArgesRic Data layer?

  74. @ArgesRic

  75. @ArgesRic Where NOT to do this?

  76. @ArgesRic Is RAM a concern? Is the GC hit a

    concern? Is raw performance a concern?
  77. @ArgesRic Why do this?

  78. @ArgesRic Trading off GC hit for a codebase that’s easier

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

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

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

  82. @ArgesRic "Who’s holding these objects?"
 Who cares?

  83. @ArgesRic Immutable data lets you focus on comprehension,
 not memorization.

  84. @ArgesRic Conclusions

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

  86. @ArgesRic To be in control, you have to know. Variability

    demands you take things on faith.
  87. @ArgesRic Try some functional patterns. Replace trust with certainty.

  88. @ArgesRic Questions?

  89. @ArgesRic Thank you! Ricardo J. Méndez ricardo@numergent.com https://speakerdeck.com/ricardojmendez/flexibility-through-immutability