3 Reasons not to be Mutable!
In this short article, while talking about immutability, I will also try to convince you why functional programming is the answer to your problems. Yes, functional programming is the answer. It’s the answer.
Concurrency
Writing thread-safe code is, quite a challenge with mutable objects. You will have to come up with a solution, using constructs such as locks, semaphores and mutexes.
In other words; you can’t take a code piece that uses mutable structures, and make it thread-safe without a major review and refactor.
Thread-safety is also hard to test and guarantee. When not done properly it creates the nastiest bugs.
In contrast immutable structures guarantee that; what you read is what you have. I will come back to this point again, hang on.
Rise of Functional Programming
Lets define what functional programming is. Quoting wikipedia;
In computer science, functional programming is a programming paradigm — a style of building the structure and elements of computer programs — that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.
Today, we have wonderful functional programming languages such as Clojure, Scala and Kotlin. These languages all run on the JVM and of-course use all the built in libraries. They are ready for enterprise work.
Value of Values
This is from title of a talk given by Rich Hickey author of Clojure. You can read the transcript here or find it on YouTube. It’s filled with convincing arguments to design your system with immutability in mind.
Couple of quotes that explains things quite well;
And mutable objects are nothing more than abstractions over places.
Think about your object oriented design. If you have a mutable object are you really abstracting complexity or do you just have a fancier pointer to a memory location?
When people built accounting systems before there were computers and they didn’t use erasers either, right? What did they use? Double-entry accounting or ledger-based accounting. They only made correcting entries.
Looks like event sourcing pattern was invented way back.
If you have a value, if you have an immutable thing, can you give that to somebody else and not worry? Yes…
Values support reproducible results. If you define a function in terms of values every time they call that function with the same values, will you get the same answer? Yes.
Simple explanation of why you are concurrent if you are using a system build with immutability in mind.
We use Java. Every new idea gets a new class. Every new thing gets a new thing. What does that cause to happen? We get this explosion of code.
This is a strong argument against OOP. All we do is create and design new objects for each problem. There is certain degree of reuse but, I would agree on this. Reuse in OOP world is a result of frameworks rather than OOP approach.
Instead what it’s implied is create pipelines of core functions, like map, reduce, fold, car, cdr, filter etc., on values.
Conclusion
In summary; using immutable structures, and functional programming will help you come up with better solutions.