4 ms·

> "Data abstraction is impossible." That's an amazing point. It explains where the object oriented proponents of decades past went wrong in thinking there woul

> "Data abstraction is impossible." That's an amazing point. It explains where the object oriented proponents of decades past went wrong in thinking there would be vendors for "Car" or "Employee" objects.

twic 5y ago
No, because you can absolutely abstract over data if it is encapsulated, which is the whole trick of objects, You can use a Point from any vendor, without caring if it has x and y, or r and theta, or some other representation inside, as long as it correctly implements the specified interface.
- jrumbut 5y ago
  But very few interesting real world objects can be consistently described across different pieces of software like a Point can, which is where it ties into the article.
  - Verdex 5y ago
    Yeah, very much this. Not to mention, if you want to serialize Point, then you have to know what its internals look like and what they mean. There is no data abstraction. [Okay, so when you serialize Point, you can also serialize all code that will ever do anything with point. However, we generally don't do this (partially because of security issues). But it doesn't really help that much because whatever the serialized code produces when run has to be some datatype where do understand the semantic meanings behind its internals.]
  - deleted 5y ago
    [deleted]
- Verdex 5y ago
  This feels like what you are describing is algorithmic or type abstraction. For your example, it's something like: Given some type Point which (I guess) interacts with some type Graph you should be able to run the Plot method. Or something. And in this case, yeah you can abstract, but it's not what I'm calling "data abstraction." [Maybe my name is just not quite right.] Data abstraction would be getting some arbitrary Point object and then being able to look into the internals and do the right thing. Whether it's x and y or r and theta. Now you might say, "that's just bad programming if you do that," but the point is that often times we don't have a choice in the matter because either of the constraints of the project OR because the "do the right thing" part interacts with non-code. So for example, if you want to send your Point over the network, then you either 1) Need to know the internals, what they mean, and how they work or 2) have to send along code for the remote device to execute to handle your custom internals. Case 2 is generally not done (and presents some security issues regardless). But this isn't just a technical issue. Names are notoriously difficult because data abstraction doesn't exist. How many first, middle, and last names does someone have? Is there a canonical ordering for the names? Does someone always have a name? What do the prefixes mean? What do the postfixes mean? These questions and more all have to do with what you're trying to use the name for AND what culture the name comes from. There is nothing you can do to abstract away the problem of names. And if you try you'll just end up with a lot of messy, complex code, that breaks all the time.
- short_sells_poo 5y ago
  You may be missing the main point of the parent (no pun intended). Their proposition is that in reality the problem is not how you define a point, but that a "point" means different things to different people and thus cannot be abstracted. I deeply agree with this observation. There are exceptions of course, but my experience is that this holds in the general case.
- ithkuil 5y ago
  Are you abstracting over the data or over the behaviour?
indymike 5y ago
> thinking there would be vendors for "Car" or "Employee" objects. For car object: Tesla, Ford, GM For employee object: Randstad, Kelly, Trueblue Much better implementation than the C++ one, too.
majormajor 5y ago
Yeah, if we look at the real world "car" object, we've certainly over decades established some common requirements that you could call interfaces: turn signals, headlights, a rough common size, etc. We've abstracted it + restricted the interface (through laws and regulations) to the point that you can build a highway or an intersection by following well-understood principles. But if you want to do something more complicated... it breaks down. Imagine trying to write software to do things with a generic "Transmission" interface. All the complicated logic would still be the responsibility of the vendor so you would be out of luck trying to come up with something more granular than "check_status()" and "repair(parts: List<Object>)" as an interface. Which is so limited as to be pointless.

twic 5y ago

No, because you can absolutely abstract over data if it is encapsulated, which is the whole trick of objects, You can use a Point from any vendor, without caring if it has x and y, or r and theta, or some other representation inside, as long as it correctly implements the specified interface.

jrumbut 5y ago
But very few interesting real world objects can be consistently described across different pieces of software like a Point can, which is where it ties into the article.
- Verdex 5y ago
  Yeah, very much this. Not to mention, if you want to serialize Point, then you have to know what its internals look like and what they mean. There is no data abstraction. [Okay, so when you serialize Point, you can also serialize all code that will ever do anything with point. However, we generally don't do this (partially because of security issues). But it doesn't really help that much because whatever the serialized code produces when run has to be some datatype where do understand the semantic meanings behind its internals.]
- deleted 5y ago
  [deleted]
Verdex 5y ago
This feels like what you are describing is algorithmic or type abstraction. For your example, it's something like: Given some type Point which (I guess) interacts with some type Graph you should be able to run the Plot method. Or something. And in this case, yeah you can abstract, but it's not what I'm calling "data abstraction." [Maybe my name is just not quite right.] Data abstraction would be getting some arbitrary Point object and then being able to look into the internals and do the right thing. Whether it's x and y or r and theta. Now you might say, "that's just bad programming if you do that," but the point is that often times we don't have a choice in the matter because either of the constraints of the project OR because the "do the right thing" part interacts with non-code. So for example, if you want to send your Point over the network, then you either 1) Need to know the internals, what they mean, and how they work or 2) have to send along code for the remote device to execute to handle your custom internals. Case 2 is generally not done (and presents some security issues regardless). But this isn't just a technical issue. Names are notoriously difficult because data abstraction doesn't exist. How many first, middle, and last names does someone have? Is there a canonical ordering for the names? Does someone always have a name? What do the prefixes mean? What do the postfixes mean? These questions and more all have to do with what you're trying to use the name for AND what culture the name comes from. There is nothing you can do to abstract away the problem of names. And if you try you'll just end up with a lot of messy, complex code, that breaks all the time.
short_sells_poo 5y ago
You may be missing the main point of the parent (no pun intended). Their proposition is that in reality the problem is not how you define a point, but that a "point" means different things to different people and thus cannot be abstracted. I deeply agree with this observation. There are exceptions of course, but my experience is that this holds in the general case.
ithkuil 5y ago
Are you abstracting over the data or over the behaviour?

indymike 5y ago

> thinking there would be vendors for "Car" or "Employee" objects. For car object: Tesla, Ford, GM For employee object: Randstad, Kelly, Trueblue Much better implementation than the C++ one, too.

majormajor 5y ago

Yeah, if we look at the real world "car" object, we've certainly over decades established some common requirements that you could call interfaces: turn signals, headlights, a rough common size, etc. We've abstracted it + restricted the interface (through laws and regulations) to the point that you can build a highway or an intersection by following well-understood principles. But if you want to do something more complicated... it breaks down. Imagine trying to write software to do things with a generic "Transmission" interface. All the complicated logic would still be the responsibility of the vendor so you would be out of luck trying to come up with something more granular than "check_status()" and "repair(parts: List<Object>)" as an interface. Which is so limited as to be pointless.