8 ms·

> and you can't just will it to have a different width and height and expect it to obey you through some force of nature I think you have let functional progra

> and you can't just will it to have a different width and height and expect it to obey you through some force of nature I think you have let functional programming and immutable data-structures bias your world view. The real world is mutable and the wonder of the digital mutable world is that it is pretty much just will-alone that can set attributes as you describe. It is immutability that is a trendy but artificial layer on top of this reality.

kccqzy 9y ago
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.
- fnl 9y ago
  Which is only because Java doesn't understand contravariance. In Scala, that problem no longer exists.
  - kccqzy 9y ago
    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.
    - fnl 9y ago
      Consumers are contravariant in Scala, but producers are covariant. EDIT: Good reference: https://www.atlassian.com/blog/software-teams/covariance-and-contravariance-in-scala https://www.atlassian.com/blog/software-teams/covariance-and...
- KMag 9y ago
  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.
tome 9y ago
Is the real world "subtypeable", in your opinion?
- coldtea 9y ago
  Sure. I want a vehicle to go to work. A car, preferably, but a motorcycle or bus will do too in a pinch.
  - dc443 9y ago
    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?
    - coldtea 9y ago
      >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.
  - tome 9y ago
    Will a bicycle? A plane? A boat?
    - coldtea 9y ago
w0utert 9y ago
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’.
greydius 9y ago
> 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.
- kaoD 9y ago
  "Everything changes and nothing remains still; you cannot step twice into the same stream"
  - kerkeslager 9y ago
    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).
    - kaoD 9y ago
      Yes, that's exactly what I meant. Sorry for not being clearer.
    - your-nanny 9y ago
      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.
- weberc2 9y ago
  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.
- seanmcdirmid 9y ago
  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).
seanmcdirmid 9y ago
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.
pulverizer 9y ago
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.
arximboldi 9y ago
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 https://www.youtube.com/watch?v=NMol_5-2owo

kccqzy 9y ago

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.

fnl 9y ago
Which is only because Java doesn't understand contravariance. In Scala, that problem no longer exists.
- kccqzy 9y ago
  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.
  - fnl 9y ago
    Consumers are contravariant in Scala, but producers are covariant. EDIT: Good reference: https://www.atlassian.com/blog/software-teams/covariance-and-contravariance-in-scala https://www.atlassian.com/blog/software-teams/covariance-and...
KMag 9y ago
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.

tome 9y ago

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

coldtea 9y ago
Sure. I want a vehicle to go to work. A car, preferably, but a motorcycle or bus will do too in a pinch.
- dc443 9y ago
  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?
  - coldtea 9y ago
    >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.
- tome 9y ago
  Will a bicycle? A plane? A boat?
  - coldtea 9y ago

w0utert 9y ago

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

greydius 9y ago

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

kaoD 9y ago
"Everything changes and nothing remains still; you cannot step twice into the same stream"
- kerkeslager 9y ago
  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).
  - kaoD 9y ago
    Yes, that's exactly what I meant. Sorry for not being clearer.
  - your-nanny 9y ago
    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.
weberc2 9y ago
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.
seanmcdirmid 9y ago
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).

seanmcdirmid 9y ago

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.

pulverizer 9y ago

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.

arximboldi 9y ago

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 https://www.youtube.com/watch?v=NMol_5-2owo