5 ms·

The discussion about abstraction in this article is interesting and thought provoking. It's useful to think about the different things we call abstractions. Ver

by dgb23 5y ago

The discussion about abstraction in this article is interesting and thought provoking. It's useful to think about the different things we call abstractions. Very much worth a read. But I feel like it tries a bit too hard to re-define what abstraction means ("only this subset of abstractions are real abstractions"), instead of just putting "abstract interpretation" next to it. This idea can stand on its own without trying to re-define the world. Secondly I understand the discussed notion of abstraction as a domain model, which is information (data and functions) _about_ the world. I like the term model better here than "idealized mapping" because the former implies a bit more that there are assumptions about the data and usage context of said model (often implicit, unstated) and that it is incomplete.

mcaruso 5y ago
From the article: > But we've had a pretty good definition of abstraction since 1977, originally in the context of program analysis, and — I claim — it actually translates quite well into a precise definition of “abstraction” in engineering. So I don't think the author is saying that all these other people are "wrong", but rather that this one particular definition seems to capture the underlying essence of what we intuitively think of when we say "abstraction", and the rest of the "hodgepodge of different concepts" break down if you analyze them a bit deeper (as the author did in the "Not Abstraction" section).
- dgb23 5y ago
  Yes and I don't agree that this is particularly fruitful. I might have completely misunderstood it but here we go: The common theme in the Not Abstraction section is: These things are used to build abstractions and are not necessarily abstractions themselves. This is not only nitpicking but it's also false. Programming language features like functions and interfaces are already abstractions, even in the narrow sense that the article describes. They are an idealized mapping to something concrete (register machines, vms etc.) and provide precision, soundness and are based on specification. Again, I very much like the core idea presented here, but I think it is completely unnecessary to make the claims about what is and isn't "true" abstraction. Take this quote: "Abstractions are separate from the code, and even from the abstract domain. It does not make sense to say that the bookTable function or anything else in this file “is” the abstraction, (..)" The function _is_ not the abstraction because abstractions are entirely conceptual? Is it a way to communicate an abstraction then? What about the actual machine code the compiler produces from that function, is there some abstraction? None of this helps me. The interesting part is that code is used to model information, it's not the world itself or even tries to be. Then this: "Feel free to call numbers an abstraction of the hardware, but be prepared to switch to this precise terminology when there's tension on the horizon." Simple abstractions that are not discussed are names and signs. These are abstractions in the very real sense and they are very simple on their own. But they are entirely contextual and are allowed to mean different things. For example the term "abstraction".
  - agentultra 5y ago
    I think you've misunderstood it. Let's design a system that allows us to run virtual computers on a single hardware platform. In some part of this system we need to map real hardware addresses to virtual ones in order to isolate the different virtual computers. Now you might need a way to take a real, logical address to a memory location on this machine and get a virtual address. You might have to run this system on many different hardware platforms and you only know the platforms you will run on today (or the next few months). Almost without thinking about it you might choose to use a virtual method on a class to define a function signature for this operation. That way folks implementing this system for different hardware platforms can create a sub-class and fill in a concrete definition of the virtual method. Now users of the system can translate an address and don't have to think about the underlying hardware platform they're running on! Abstraction! Only it's not an abstraction. If you attempt to formalize what it means to map a hardware address to the virtual address you will find it quite difficult because your interface provides no information about hardware addresses. In other words the virtual method does not put in all of the details of the concrete implementation and so we cannot maintain an invariant in our specifications that would ensure that we only translate valid addresses, or that translation is deterministic -- properties that would be important for users of the abstraction to truly be able to ignore the underlying complex domain. If we could write such a specification for this virtual method though, it would be very complicated, and that is a good sign this is not a good abstraction. Abstractions are often separate from the code because they're much more general than a single program. If we came up with a better abstraction in a formal logic like separation logic or using Hoare logic -- we might be able to prove that the properties we care about hold and therefore any program that implements this specification will have the same properties. And there might be several such programs! So what industry programmers are often saying when they are talking about "abstraction" is "indirection and vagueness." What this article is trying to show is that we can give precise definitions to our abstractions so that we can build new _semantic_ layers that have precise meaning: when I translate a hardware address I get a valid, deterministic virtual address and nothing else.
    - dgb23 5y ago
      These are very useful properties to have. And I rather use an abstraction where these properties hold, rather than one that just takes care of some plumbing. There is a qualitative difference here.
specialist 5y ago
Ya. My brain is all thumbs when trying to handle the philosophy parts of software. Both this OC and the wiki article on 'abstraction', wrt to software design (eg OOAD) make me think of generalization and specialization. -- My own working definition of 'abstraction' vs 'mental models', because I lack more proper terms: - abstractions hide details, aka black box - mental models explain how something works, even if over simplified An example of a good (quite useful) abstraction is the initial Java Virtual Machine. Its 'interface' (per this OC) is quite good, meaning comparatively small impedance mismatch, and acceptable 'leakiness'. As we've seen over time, driven by optimization, that abstraction is necessarily bypassed or mitigated with JMM, FFI, unsafe stuff, intrinsics, direct memory, etc. Using an example of a mental model from my prior works, because I'm precaffeinated, and I can't think of a better example than Newtonian mechanics, already mentioned. I used to work in print production, like books and magazines. For bookwork, I created an algorithm for the folding of big sheets of paper into 'signatures' containing printed pages. My app accounted for folds, binding, and cutting. It revealed the manufacturing process, so there could be no mistake. It reduced an Illustrator-like application (ScenicSoft' Preps imposition app) to a simple form. This simplification was possible because I had invented a better mental model. -- My working definition of abstraction doesn't jive with anyone else's. I'm open to alternate suggestions. https://en.wikipedia.org/wiki/Abstraction https://en.wikipedia.org/wiki/Abstraction
- chousuke 5y ago
  I think of things in terms of abstractions and models. Abstractions generalize commonalities into a vocabulary that can be used on any entity that is covered by the abstraction. A sequence is an abstraction, but data structures themselves aren't as far as software is concerned. Data structures can be sequences, but you can't create a sequence. A (logical) model is a simplified representation of the real thing that is still complete enough that it can be used to successfully reason about and accomplish goals with a system. A linked list datastructure is a real thing with a number of possible implementation details, but it still has a straightforward, concrete model of what it is. It's not an abstraction. A model does not have to be abstract at all; it can be very concrete, even if it in practice hides some underlying details. It seems common in software to either get lost in abstraction so that you forget the model, or consider the model so rigid that you miss useful, simplifying abstractions.
undecisive 5y ago
It reminds me of a concept I've been hearing a lot recently: Dictionaries do not define words. They tell you what a word is being used for, but nothing about a dictionary gives any moral or philosophical credence to any particular definition. In other words, the definition of a word depends on its real-world usage; dictionaries attempt to capture common usages, but no definition of a word can be considered the "true" definition more than any other used and understood application of the word. So in this case, calling these definitions "imposters" or "not-abstractions" is absolutely wrong. That said, I like the attempt to introduce names for different flavours of abstraction to make discussion easier. That's definitely useful. Just wish it wasn't off the back of incorrectly telling people that their use of the language is incorrect.
- dgb23 5y ago
  Fully agreed! And this: > That said, I like the attempt to introduce names for different flavours of abstraction to make discussion easier. That's definitely useful. Is the real value of this article.
- fluoridation 5y ago
  There's actually two different schools of linguistics: prescriptive ("language is this") and descriptive ("language is used like this"). A dictionary can be written in one or the other, or some mixture of the two. To say that all dictionaries are purely descriptive is incorrect.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - brimble 5y ago
    Even descriptive dictionaries imply a certain amount of prescription, as: "prefer using words as they are herein defined, if you care about others being able to understand you".
deleted 5y ago
[deleted]

by dgb23 5y ago

mcaruso 5y ago

From the article: > But we've had a pretty good definition of abstraction since 1977, originally in the context of program analysis, and — I claim — it actually translates quite well into a precise definition of “abstraction” in engineering. So I don't think the author is saying that all these other people are "wrong", but rather that this one particular definition seems to capture the underlying essence of what we intuitively think of when we say "abstraction", and the rest of the "hodgepodge of different concepts" break down if you analyze them a bit deeper (as the author did in the "Not Abstraction" section).

dgb23 5y ago
Yes and I don't agree that this is particularly fruitful. I might have completely misunderstood it but here we go: The common theme in the Not Abstraction section is: These things are used to build abstractions and are not necessarily abstractions themselves. This is not only nitpicking but it's also false. Programming language features like functions and interfaces are already abstractions, even in the narrow sense that the article describes. They are an idealized mapping to something concrete (register machines, vms etc.) and provide precision, soundness and are based on specification. Again, I very much like the core idea presented here, but I think it is completely unnecessary to make the claims about what is and isn't "true" abstraction. Take this quote: "Abstractions are separate from the code, and even from the abstract domain. It does not make sense to say that the bookTable function or anything else in this file “is” the abstraction, (..)" The function _is_ not the abstraction because abstractions are entirely conceptual? Is it a way to communicate an abstraction then? What about the actual machine code the compiler produces from that function, is there some abstraction? None of this helps me. The interesting part is that code is used to model information, it's not the world itself or even tries to be. Then this: "Feel free to call numbers an abstraction of the hardware, but be prepared to switch to this precise terminology when there's tension on the horizon." Simple abstractions that are not discussed are names and signs. These are abstractions in the very real sense and they are very simple on their own. But they are entirely contextual and are allowed to mean different things. For example the term "abstraction".
- agentultra 5y ago
  I think you've misunderstood it. Let's design a system that allows us to run virtual computers on a single hardware platform. In some part of this system we need to map real hardware addresses to virtual ones in order to isolate the different virtual computers. Now you might need a way to take a real, logical address to a memory location on this machine and get a virtual address. You might have to run this system on many different hardware platforms and you only know the platforms you will run on today (or the next few months). Almost without thinking about it you might choose to use a virtual method on a class to define a function signature for this operation. That way folks implementing this system for different hardware platforms can create a sub-class and fill in a concrete definition of the virtual method. Now users of the system can translate an address and don't have to think about the underlying hardware platform they're running on! Abstraction! Only it's not an abstraction. If you attempt to formalize what it means to map a hardware address to the virtual address you will find it quite difficult because your interface provides no information about hardware addresses. In other words the virtual method does not put in all of the details of the concrete implementation and so we cannot maintain an invariant in our specifications that would ensure that we only translate valid addresses, or that translation is deterministic -- properties that would be important for users of the abstraction to truly be able to ignore the underlying complex domain. If we could write such a specification for this virtual method though, it would be very complicated, and that is a good sign this is not a good abstraction. Abstractions are often separate from the code because they're much more general than a single program. If we came up with a better abstraction in a formal logic like separation logic or using Hoare logic -- we might be able to prove that the properties we care about hold and therefore any program that implements this specification will have the same properties. And there might be several such programs! So what industry programmers are often saying when they are talking about "abstraction" is "indirection and vagueness." What this article is trying to show is that we can give precise definitions to our abstractions so that we can build new _semantic_ layers that have precise meaning: when I translate a hardware address I get a valid, deterministic virtual address and nothing else.
  - dgb23 5y ago
    These are very useful properties to have. And I rather use an abstraction where these properties hold, rather than one that just takes care of some plumbing. There is a qualitative difference here.

specialist 5y ago

Ya. My brain is all thumbs when trying to handle the philosophy parts of software. Both this OC and the wiki article on 'abstraction', wrt to software design (eg OOAD) make me think of generalization and specialization. -- My own working definition of 'abstraction' vs 'mental models', because I lack more proper terms: - abstractions hide details, aka black box - mental models explain how something works, even if over simplified An example of a good (quite useful) abstraction is the initial Java Virtual Machine. Its 'interface' (per this OC) is quite good, meaning comparatively small impedance mismatch, and acceptable 'leakiness'. As we've seen over time, driven by optimization, that abstraction is necessarily bypassed or mitigated with JMM, FFI, unsafe stuff, intrinsics, direct memory, etc. Using an example of a mental model from my prior works, because I'm precaffeinated, and I can't think of a better example than Newtonian mechanics, already mentioned. I used to work in print production, like books and magazines. For bookwork, I created an algorithm for the folding of big sheets of paper into 'signatures' containing printed pages. My app accounted for folds, binding, and cutting. It revealed the manufacturing process, so there could be no mistake. It reduced an Illustrator-like application (ScenicSoft' Preps imposition app) to a simple form. This simplification was possible because I had invented a better mental model. -- My working definition of abstraction doesn't jive with anyone else's. I'm open to alternate suggestions. https://en.wikipedia.org/wiki/Abstraction https://en.wikipedia.org/wiki/Abstraction

chousuke 5y ago
I think of things in terms of abstractions and models. Abstractions generalize commonalities into a vocabulary that can be used on any entity that is covered by the abstraction. A sequence is an abstraction, but data structures themselves aren't as far as software is concerned. Data structures can be sequences, but you can't create a sequence. A (logical) model is a simplified representation of the real thing that is still complete enough that it can be used to successfully reason about and accomplish goals with a system. A linked list datastructure is a real thing with a number of possible implementation details, but it still has a straightforward, concrete model of what it is. It's not an abstraction. A model does not have to be abstract at all; it can be very concrete, even if it in practice hides some underlying details. It seems common in software to either get lost in abstraction so that you forget the model, or consider the model so rigid that you miss useful, simplifying abstractions.

undecisive 5y ago

It reminds me of a concept I've been hearing a lot recently: Dictionaries do not define words. They tell you what a word is being used for, but nothing about a dictionary gives any moral or philosophical credence to any particular definition. In other words, the definition of a word depends on its real-world usage; dictionaries attempt to capture common usages, but no definition of a word can be considered the "true" definition more than any other used and understood application of the word. So in this case, calling these definitions "imposters" or "not-abstractions" is absolutely wrong. That said, I like the attempt to introduce names for different flavours of abstraction to make discussion easier. That's definitely useful. Just wish it wasn't off the back of incorrectly telling people that their use of the language is incorrect.

dgb23 5y ago
Fully agreed! And this: > That said, I like the attempt to introduce names for different flavours of abstraction to make discussion easier. That's definitely useful. Is the real value of this article.
fluoridation 5y ago
There's actually two different schools of linguistics: prescriptive ("language is this") and descriptive ("language is used like this"). A dictionary can be written in one or the other, or some mixture of the two. To say that all dictionaries are purely descriptive is incorrect.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- brimble 5y ago
  Even descriptive dictionaries imply a certain amount of prescription, as: "prefer using words as they are herein defined, if you care about others being able to understand you".

deleted 5y ago

[deleted]