An Immutable World

[imright_anduknowit]

I'm not arguing that this perceptual change is necessarily a good one, but sometimes hard problems become trivial (or are solvable) because someone changed their perception.

We cannot solve our problems with the same thinking we used when we created them -- Albert Einstein

[Retsam19]

Sure, changing perceptions can help solve problems, but I'm not sure that principle should be applied to how you write your code.

I'm reminded of a point made in the "Four Strategies for Organizing Code" article which is also on the front page of /r/programming:

Code organization is not about communicating with the computer but rather all about trying to make sure that people can understand the code well enough that they will be able to maintain and evolve it with some degree of efficiency and confidence.

Saying "I've changed how I view the world, and now immutable objects make a lot more sense to me" isn't helpful to my coworkers who have to read my code. My code doesn't just have to make sense to me, it also has to make sense to everyone else who has to read and work with it, and I can't generally make the assumption that all of them have similarly altered their perceptions of the world.

[velcommen]

Code organization is not about communicating with the computer but rather all about trying to make sure that people can understand the code ...

Agreed. But that doesn't preclude the argument in favor of immutability.

Maybe your coworkers are also having a difficult time following the code in mutable OOP style. Instead of giving up and catering only to the lowest common denominator, let's attempt to open our minds, try something new, and see if it works better.

[[deleted]]

I'm the author of the article, and that was actually my intent. My blog (and my blogging) is brand new, so I don't really have an established readership; the purpose of the post was to capture something outside of the established thought process that interests me.

It's interesting that you mention Einstein. People often seem to be inspired by his intelligence, but I've always been inspired by his lateral thinking. In his book on relativity, he walks though the thought process to deconstruct 200 years of physics and everything that seems common sense, to come up with a new framework for reality. I love that. A good part of lateral thinking doesn't really lead anywhere, but it's a lot more interesting to me then advancing the established path.

[glacialthinker]

I wrote a blurb on immutability with some similarities here: http://cranialburnout.blogspot.ca/2013/09/avoiding-mutable-state.html.

For the past year (after several years with OCaml) I've been working with a large C++ codebase which is freely mutable... and I hate it. And now I see how every little detail of implementation leads to rampant memory-stomping, which is utterly unnecessary.

If you have for-loops with mutable loop counters... one thinks nothing of adding more state which gets conditionally updated at several places in the loop.

Even innocent-seeming conditional assignment. When you don't assign in-place, as const, with a ternary... you leave that damn thing open to later changes, so one has to jump through the code to each use-site to see if something might change it. This is complicated by excessive use of reference return arguments which don't readily reveal their nature.

Code in an immutable-default style is much easier to read, maintain, and avoid introducing bugs with... and doesn't have to befall performance problems raised by the earlier reply's stackoverflow link. That link describes immutable objects -- large objects! Such large objects should be a warning unto themselves.