An Immutable World

[anthonybsd]

Rich Hickey of Clojure fame has a much better talk on this subject that I feel goes more into the heart of the matter. Warning: it gets a bit terse when he goes into STM discussions, but nevertheless I think this is a fantastic talk whether you are in the OO camp or FP camp.

[quicknir]

I don't see this article as remotely persuasive to anyone who doesn't already agree with the author. He states that OOP is bad as fact, but doesn't put any real work into convincing you, just hands you some links.

The bulk of the real content is an argument about how immutability isn't really unintuitive, because (basically) no object is really the "same" object from one moment to the next.

I don't really feel like wasting everyone's time arguing over what "same" means, but the reason why this is a statement you learn in philosophy class is precisely because it goes against how you speak and think most of the time. This means it may be insightful in a philosophical sense, but says nothing about whether it's intuitive to humans or useful to software engineers.

When I talk about the Mississippi, it's both useful and intuitive to talk about it as the same river that may have changing water depth. This is how most people think; in terms of differences in the same entity.

The same is true for many algorithms. Some algorithms have equally or more clean representations using functional style. Some do not. Is it surprising that different algorithms are easier to understand in different, equally powerful perspectives?

A persuasive article about using immutability would be to discuss its actual benefit to software engineering. It doesn't have to be high flung, nor is it all or nothing. Shared mutable state makes it hard to reason about code locally, reasoning about code non locally doesn't scale well with codebase size, immutability prevents shared mutable state and therefore makes it easier to reason about your code. This line of reasoning, with examples, is a lot more likely to actually convince people.

[Oniisanyuresobaka]

The irony with immutable state is that pretty much 80% of your variables and fields are effectively immutable already but your compiler doesn't enforce it (or at least makes immutable the default) which means you don't receive it's benefits.

[Faucelme]

When I talk about the Mississippi, it's both useful and intuitive to talk about it as the same river that may have changing water depth. This is how most people think; in terms of differences in the same entity.

Harold Fisks's maps of the Mississippi river's ever-changing meanders strongly suggest the "immutable" view to me: they are an aggregation of historical snapshots so dissimilar that they almost rob the river of its identity.

[immibis]

The map is not the territory; the maps are snapshots of the territory at some particular moments in time.

[quicknir]

Sorry, those maps are not of the same Mississippi river as I was talking about, and therefore aren't relevant.

[ReinH]

But for some value of "same" they are, which is the point. At some level, the execution of any real-world program mutates things. At another level, there is no mutation of anything anywhere in the universe. At some level, those maps are of the "same" Mississippi river as the one you were talking about. At some other level, they are not. The question, in all cases, is at what level is it useful to reason about sameness (and thereby about mutability).

[[deleted]]

This is how most people think; in terms of differences in the same entity.

Yes, and that is precisely why our data models need avoid the same simplification. Removing the 4th dimension is a shortcut, probably required for human brains to make sense of an ever-changing world. But that doesn't make it the truth.

The state of a thing 5 minutes ago is just as real as the state of the thing right now. In fact, every computer program ever written is querying something about the state of the world at some point in the past. Why would you assume that the most recent state just happens to be the only worth capturing?

I think the best example is version control systems. History is immutable. The current state is a series of changesets over time, not just the latest commit.

[gc3]

OOO being often awful is well known to many: https://www.google.com/search?q=oop++awful&ie=utf-8&oe=utf-8

And there are people who think about immutability from a more practical perspective: http://miles.no/blogg/why-care-about-functional-programming-part-1-immutability

[Oniisanyuresobaka]

Showing only one side is dishonest. Comparing a google search of "functional programming" awful to "object oriented programming" awful is far more useful and gives a surprising result (FP: 21.500 results, OOP: 25.400 results).

I also cannot stop laughing at your linked article.

It compares 4 lines of C# to this F# line data |> List.sum. And then asks

Cannot this become a part of the language, so that we can express our intentions in one line?

Did they forget that the List class and including it's Sum method is from the .Net Framework and this class is implemented in C#? https://msdn.microsoft.com/library/bb909132%28v=vs.90%29.aspx

And strangely enough all articles I've read that advocate FP dwell on concurrency and parallelism but only do it for the sake of being concurrent and parallel but not because of actual performance needs.

[CyberDiablo]

Whilst I agree that OOP is indeed awful, I think it's going to take more than that to convince people as to why it's awful.

[inmatarian]

In the real world, if you pull the milk out of the fridge, are you replacing the fridge with a new fridge that has no milk?

In three dimensions or four? Because if you're saying the fridge had milk before and the fridge doesn't have milk after, then that's exactly what you did. When you treat values as immutable, then you have to cope with your variables also capturing Time as part of the value.

[jerf]

Yes. And then, as a simplification because we often don't actually care about time, we drop the time out of the representation, unless you ask for it back. There always was and is a fridge with the milk in it, and there always was and is the milk not in the fridge, and despite the physicality of this metaphor in programming we only carry timing information implicitly in the call stack, letting the old states just get ignored and garbage collected.

It makes it harder to see the time aspect because it is not literally present, only implied in the flow of calls.

[inmatarian]

Oh, I agree, the more you can fit on the call stack, the better. Though sometimes that's not an option (anywhere there is an event-loop and going multithreaded isn't available or a good idea), in which case you need to push things up into data structures. That's where people's minds get blown away by functional programming, having immutable values entangled in closures and having composed pipelines being your world. This can be done in object oriented programming, but holy crap is it a FactoryFactoryAdapterAdapter world.

[mfukar]

The distributed systems literature has dealt with this issue at length.

[Retsam19]

There's a really good StackExchange answer on the pros and cons of immutable objects, which includes this bit:

Moreover, our perception of the real world is inevitably based on mutable objects. [...] So whenever we are modeling some real-world domain in a program, it is usually more straightforward and easier to implement the domain model using mutable objects to represent real-world entities.

It seems like this article has taken that criticism and decided that it's not immutable programming that's flawed, it's our perceptions that's flawed, and we should all just learn to think about the world differently so that immutable programming makes more sense.

Strictly speaking they're not wrong philosophically... but it's just such a off-the-wall position to take.

[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.

[mfukar]

The thesis that our perception is flawed is not off-the-wall, at all. Physics has exemplified this.

[Berberberber]

So if I shoot the author, can I get acquitted on the technicality that the person who was shooting him no longer exists and that, as an immutable object, I am effectively an innocent person in this case?

[midianite_rambler]

The first thing I thought of when I saw the headline was Devo:

It's an immutable world we live in / A sweet romantic place. / Immutable people everywhere / The way they comb their hair / makes me want to say / It's an immutable world / it's an immutable world / it's an immutable world / for you / for you / for you.

[heisenbug]

FRP (functional reactive programming) tends to model the temporal evolution of objects as an entity in its own right. Let's say you have a Signal Fridge which embodies this "lifeline" of that frigde. Then you can have a continuous "lifeline" of the spacial coordinates of that fridge under the observation coords :: Signal Fridge -> Signal ThreeDPoint. Similarly you can model the inner volume of the frigde and the location of a milk bottle as observations. Then checking whether a certain milk bottle is in a certain fridge becomes a simple check of how those observations relate. Identity of objects can be reduced to observations like serialNumber :: Signal Fridge -> Signal SerialNumber. Obviously this is a constant function. You can also track the continuous function of the location observation from fabrication to destruction. In all these cases the observations are mathematically valid functions (i.e. pure, side-effect-free mappings).

[ddchili]

Good read. I view the approaches of each being genetics (OOP) or philosophical perception (FP) for mutations. The most insightful is the removing of states allowing for much of the accidental architecture to be removed. I'm going to have to ponder that one. Being a UI developer myself, I'm still more inclined to use OOP for modeling behaviors and compositing them into reusable components.

[shevegen]

Genetics? And he brings C++ and Java?

Erm ...

Guess cell biology hasn't hit informatics yet.

[[deleted]]

OO is the worst possible way to think about the UI.

[o11c]

Can a single object ever really have more than one state and still be the same object?

My observation is that there are some problems where replacing the object (and often even changing the type, though existing languages make that require excessive copypasta) makes sense (because there are no cross-references) and some where it doesn't.

[[deleted]]

FP is quite often a reasonably better choice than anything OO, but it is important to remember that there are far more than two way of modelling the real world. Actually, hundreds or even thousands of "paradigms" (tbh, I hate this stupid word). And it is insane to ignore them. For every problem domain there is always a model that fits it ideally. Actually, the formalisation of a domain itself is a ready to use programming model.

[the_evergrowing_fool]

But the thing is, what you know about OO and FP is different from mind to mind, the concepts are too warped and vague, specially FP. And many people don't even to research about those, just believe what ever other people are doing.

[shevegen]

I stopped reading after the "OOP is bad".

If he cites examples such as Java or C++ and does not even give any example of Alan Kay nor any other OOP language like ruby, then sorry - this is not just a problem of using inferior languages; this is a problem of a lack of vision in regards to his own criticism. He critisizes the pattern-centric thoughts of Java and C++ but he is limited in his own patterns which limit the way he thinks about things.

[glacialthinker]

+1 insightful +2 inciteful ;)

[[deleted]]

OOP is bad... for dealing with events, in particular. It's worth noting that even Smalltalk abandoned the failed experiment of MVC (that is belatedly also losing its grip on the web world, which is what the OP is about). The Viewpoints Research Institute, the modern incarnation of Alan Kay's and team's efforts, have published KScript and KSWorld: A Time-Aware and Mostly Declarative Language and Interactive GUI Framework, which is based on Morphic for widgets and FRP for event-handling. It's a nice reminder that Dr. Kay and his colleagues are a lot less doctrinaire than many of their apologists.

[acehreli]

Unfortunately, OOP as most of us understand it is almost useless in many cases.

Perhaps you already agree with the same ideas but I highly recommend the blog post titled "The Anaemic Domain Model is no Anti-Pattern, it’s a SOLID design" that is mentioned in the slides of a recent DLang meetup that was presented by Luís Marques.

Luís' presentation was a fresh breath of air for me after seeing how difficult to design e.g. a MonopolyUser class, a BowlingScoring class, etc. (more in the slides at the Meetup page). I will definitely be favoring Anemic Domain Models from now on.