When I first started learning functional programming, immutability was one of the great looming walls which I encountered. I kept looking for some deep and complex reason that variables shouldn’t mutate, when in fact, the reason is very, very simple. Immutable variables make code more predictable.
Let’s say you and I, and ten others are seated in a circle. You need to pass a message to everyone, but you can’t do it by speaking. “Aha,” you declare. “I’ll write a note, and everyone can pass it down!” If I asked you at this point whether you’d like the note laminated, what would your response be?
My guess is, you’d answer, “No, thanks. It’s just going around the circle.” Seems pretty reasonable, when you’re just making sure 11 people get the same message, especially if you know and trust them. What if you needed to pass the note to a thousand people, or ten thousand? The note might get ripped, smudged, or some troll might deliberately change it.
Laminating the message ensures that everyone gets the same message, and that is where immutability becomes powerful. Know what the difference is between this:
| var message = "This is a message."; | |
| logger.Log(message); | |
| var messageInQuotes = "\"" + message + "\""; |
and this?
| let message = "This is a message." | |
| logger.Log message | |
| let messageInQuotes = "\"" + message + "\"" |
The difference is that we can only predict the value of messageInQuotes in the second code example. In the C# example, once the message variable is passed into the Log method, you are allowing it or any methods it calls to change the state of the message. With immutable variables, you can predict the state of messageInQuotes.
This may not seem earth-shaking or profound, and that’s because it isn’t. Like the best things in programming, it’s incredibly simple. If you’re writing a ten-line console app, who cares about mutability? When you’re working with ten-million lines of code, event-driven asynchronous processing, and multi-threading (or as I like to call it, enterprise development), you might want to care.
Going back to our analogy of ten-thousand people all getting the same message, you don’t have to assume there’s a bad egg. People make mistakes all the time. Maybe the message was, “There’s a party on Fulton St,” and someone thought, “I don’t know a Fulton St. You must have meant Fuller St. I’ll fix it for you and pass it on.” Only with software, it’s that one errant function.
I’m not trying to say that C# is bad, or that F# is better. Both C# and F# offer mutability and immutability. With any language, enterprise-scale development is complicated and complexity reduces predictability, which in turn reduces reliability. Immutability can help your code to be more predictable, and (IMHO) more readable.
In closing, look at the following code. Assuming we want to get the reversed value of an original string, is it clearer to pass the string to a function which will reverse it, or to pass it into a method which will return the reversed value and then assign that value to a new variable?
| // relying on mutability | |
| public void ReverseString(string forwards) | |
| { | |
| var chars = forwards.ToCharArray(); | |
| Array.Reverse(chars); | |
| forwards = new String(chars); | |
| } | |
| ReverseString(message); | |
| // immutable implementation | |
| public string ReverseString(string forwards) | |
| { | |
| var chars = forwards.ToCharArray(); | |
| var reversedChars = chars.Reverse().ToArray(); | |
| return new String(reversedChars); | |
| } | |
| reversedMessage = ReverseString(message); |
Fun times with Functions 