> The real world is mutable

Only if you ignore time. It's not possible to change the state of the world at some previous instant (as far as our understanding of physics is concerned). The mutable world model is an artificial construction that aligns with our human perception.

Something that changes over time is mutable. Time exists and we can’t escape it, even with time-indexed immutable data structures that implement explicit mutability. The only question is does the thing change internally (an object) or is it replaced with a new one (a value).

I think it's not at all evident that reality is not a value replaced with a new one all the time.

Even if that were the case, it wouldn’t be useful since we experience time with continuity anyways. Bob at time t is still Bob at t+1 even if his state (like position) has changed. If Bob were a value, then he would be another person, we would have to add a persistent ID to the bob values so we could see them as the same object.

> Bob at time t is still Bob at t+1

I guess we're getting more into philosophical issues now. If I leave an ice cube on my counter, at exactly what time is it no longer an ice cube.

Mutability is mutability, it also applies to ontology even if most OO languages don’t model dynamic ontology with inheritance (unlike say Self or Cecil).

Your ice cube was never just an ice cube in the first place, it was just some water that happened to be frozen as a cube...once heat was applied to the water, it’s state changed so that it eventually could no longer be classified as an ice cube.

> Your ice cube was never just an ice cube in the first place

That's my point. This idea that there are objects with mutable state is a myth. Even at the smallest scale, what we call elementary particles, are abstractions. There is nothing except the state of the universe at a given instant in time.

Again, we are unable to work or perceive at that level. So the abstraction of state is incredibly useful to us non-sub-atomic beings.

Agreed, but if we're accepting an abstraction instead of reality, than arguing for mutability because you think it's reality doesn't make much sense now does it? You're saying it's okay to abstract things away from molecules, but it's not okay to abstract things away from mutation. Why?

(Note that I'm not even persuaded yet that mutation is reality. I'm just saying that even if mutation were reality, it doesn't follow that mutation is the best abstraction with which to model reality.)

> Bob at time t is still Bob at t+1 even if his state (like position) has changed.

Again, I don't think this is at all evident.

What if we remove a limb? Give him a dose of LSD? Give him a brain tumor? Replace most of his cells as happens to each of us every few years? What change is large enough that it's easier to represent with:

   bob = getNext(bob);

...rather than:

   bob.foo = bar;

? Is it even harder to represent change one way rather than the other?

Indeed, socially, the concept of identity is a leaky enough abstraction to cause problems; for example if we are criticized for actions that we took years ago, it's easy to get defensive even if we are a different enough person now that we would never take that action now.

Bringing this back to inheritance: if it would make sense to model Bob as an instance of Child one day and as an instance of Octogenarian another day, why not create a new instance of Bob?

You want to argue this from the standpoint of "this is how things are" but I think that there are multiple ways to model Bob and which is appropriate actually depends more on the needs of the system than the true nature of Bob.

Bob’s state might change, but he is still Bob. That would also go for the Ship of Theseus. However you represent it, change is still change, it is still mutability.

We can argue if identity is useful in real life, but most people cling to names and identity, it isn't a controversial subject.

Dynamic inheritance is extremely useful in a programming language, though only a few have it. It is a very OO concept, as are the languages that have explored the concept (e.g. Self, Cecil, among others, even Javascript has this aspect, though not focused enough to use very well).

"Everything changes and nothing remains still; you cannot step twice into the same stream"

Ironically, the latter part of what you quoted shows the solution to representing change in an immutable system: create a different stream object instead of mutating the same stream object.

(Streams in this case not being streams in an I/O sense, just an example of a class).

Meh. Once you mutate an object it is not the same object it once was either; you've only maintained a stable memory reference and alias, without the overhead of making a new one.

Yes, that's exactly what I meant. Sorry for not being clearer.

If you're modeling the world, you can do so immutably. If you're interacting with the world (I.e., I/O), then you cannot.

No. Mutation essentially breaks subtyping. The infamous ArrayStoreException in Java is the story of how references (which should be invariant) are treated as covariant and therefore causes runtime exceptions.

If your array type (the only reified generic type in Java) is going to be parameterized by a single type, then you're right that it needs to be invariant.

One alternative would be to keep track of two types for an array: the most general type that can be stored into it and the most general type that might come back out of it. Any type cast that makes the types storable more strict or the type expected coming out less strict should be allowed. If you throw in a bottom type in your type system, then you get immutable arrays for free.

Of course, such a type system would probably cause a revolt among the majority of Java programmers for being too complex.

Which is only because Java doesn't understand contravariance. In Scala, that problem no longer exists.

No. When references or arrays of references are treated as contravariant, you would have the opposite problem of ArrayReadException. You can now store things into arrays safely but you can no longer extract things from arrays safely.

Consumers are contravariant in Scala, but producers are covariant.

EDIT: Good reference: https://www.atlassian.com/blog/software-teams/covariance-and...

This is not wrong, but it ignores that in terms of reliable software architectures, it’s very often still better to model change using strictly immutable data types. Often, not always.

As usual the truth is somewhere in the middle, which is why I don’t like the periodically recurring discussions why OO is bad, FP is good or vice versa. I think the article splits up the issue quite nicely, the conclusion I get from it is that the answer to the question whether to use inheritance or not is ‘it depends’.

The real world is mutable in some sense, but our thinking, even in the most trivial exercises, works by detaching _objects_ them from their physical nature and building immutable _ideas_. Thinking is a struggle trying to find what is necessary in a contingent world, trying to find essence in a world of form. That is why values and immutability are so useful for modeling, architecture, and building resilient software.

I talked more about this in this MeetingC++'17 talk: https://www.youtube.com/watch?v=NMol_5-2owo

In real world you stretch a square and it may become a rectangle. So in OO even type of an object should be mutable if you want to model real world closely.

Is the real world "subtypeable", in your opinion?

Sure. I want a vehicle to go to work. A car, preferably, but a motorcycle or bus will do too in a pinch.

I don't know about this. Is a teleporter a vehicle? What about a vehicle which doesnt have wheels, in a world built around assuming that vehicles have wheels?

>I don't know about this. Is a teleporter a vehicle?

Depends on your definition on vehicle. For many purposes (e.g. going somewhere) it could be, especially if it also existed.

Subtyping just means "having a taxonomy of things, where we can substitute things lower on the taxonomy -- more concrete, more specialized and so on" with things higher up when wanting less abstraction (and vise versa).

And this is pretty much the case with the world -- Plato's "ideas", scientific taxonomies (e.g. of animals and plants), or RDF and semantic taxonomies, and so on are all based on the same concept.

(That doesn't mean they're perfect descriptions of the world, like our class taxonomies in OOP don't lead to perfect descriptions of most problem domains either).

>What about a vehicle which doesn't have wheels, in a world built around assuming that vehicles have wheels?

That's a problem of definition of what should belong in the class of things we call "vehicle" (and you could have the exact same questions when doing OOP).

As such it's not an argument in whether the real world has or doesn't have subtyping.

Will a bicycle? A plane? A boat?

Most of them. But that's not the point. Not all subtypes are applicable to any task in OOP either.

Then I'm not quite sure what's the point of them. Surely instead of using a type you're allowed to use any of its subtypes.

Values should be immutable even in OO languages. A point’s x and y coordinates can’t be mutated because then it would be a different, just like a number’s value can’t be mutated. The question is then is a rectangle a value or an object? I would say no and then stack allocate it like any other value, recomputing it if a rect property ever changed.

The real world has both values and objects, any ideology that doesn’t acknowledge both is just fooling itself.