12 ms·

Abstraction: Not what you think it is

163 points by tempodox 5y ago

Koshkin 5y ago
I think of an abstraction as a map from a model space into the problem domain. (A map that is not necessarily injective, and sure enough not surjective.) I am sure category theory can say much about this.
- UncleMeat 5y ago
  The whole point of the article is providing a rigorous definition rather than the wishy-washy stuff people usually use. This is independent of category theory. Cousot was working in a different space.
  - Koshkin 5y ago
    No, I thoroughly appreciate that, it's just that the functorial language of the "abstract nonsense" seems perfect for discussing modeling and abstraction.
smitty1e 5y ago
If asked, I'd've said: "Applied ontology[1]". When we code, we're philosophizing about information in some language (itself an applied ontology), for the decreasingly worse. Occasionally one arrives at a coherent, stable product. [1] https://en.wikipedia.org/wiki/Ontology https://en.wikipedia.org/wiki/Ontology
adamkl 5y ago
Reading this makes me think of "stratified"[0] design, which I think is a good example of abstraction done right. [0] - https://medium.com/clean-code-development/stratified-design-over-layered-design-125727c7e15 https://medium.com/clean-code-development/stratified-design-...
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".
andrewingram 5y ago
I've come to think of an abstraction as a potentially lossy transformation of a model into one better suited to the task at hand.
- busyant 5y ago
  Interesting. You've made me realize that models (in the scientific sense) are lossy transformations of reality.
  - andrewingram 5y ago
    Yeah, this is how I think about Newtonian Mechanics -- a useful abstraction.
    - Koshkin 5y ago
      Starting with “point particle.” (By the way, theoretical mechanics has long been considered part of mathematics.)
  - dTal 5y ago
    Moreover, the point of a model is to be lossy: https://en.wikipedia.org/wiki/On_Exactitude_in_Science https://en.wikipedia.org/wiki/On_Exactitude_in_Science
    - arethuza 5y ago
      Spherical cows being the obvious example - in some circumstances that might be a perfectly valid modelling assumption.
- ncmncm 5y ago
  ... to one somebody hoped was better suited to the task. That hope is not necessarily realized. If it is not lossy, it is likely not to be providing net value.
  - 5y ago
nathias 5y ago
This is a fairly common sense notion of abstraction (abstraction as abstracting away the details of something), but I don't think its the whole picture. I'm studying abstraction and the best formulation of this aspect I found was abstraction as the degree of complexity encapsulation.
- prionassembly 5y ago
  Yea, but this complexity is not inherent to code.
  - nathias 5y ago
    What do you mean? Of course it is, all code is leaky abstractions.
SPBS 5y ago
Basically functions are not abstractions, the data structures that functions act on are the real abstractions. Because the data structures have been planned out in a particular way, functions can manipulate them as if they were manipulating concrete entities in the business domain. Here's a bunch of relevant quotes talking about that idea (credits to https://medium.com/webdevops/data-structures-548cbea9c520 https://medium.com/webdevops/data-structures-548cbea9c520) "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - Linus Torvalds "Fold knowledge into data, so program logic can be stupid and robust." - Eric S. Raymond "Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." - Rob Pike "Representation is the Essence of Programming" - Fred Brooks "One of the key attributes of a "Good" representation, is the ease in which it is transformed into other valid information the computer can process." - https://www.cs.utah.edu/~germain/PPS/Topics/information_representation_and_transformations.html https://www.cs.utah.edu/~germain/PPS/Topics/information_repr...
- lobstey 5y ago
  cannot agree on that. Here you got the OO ways of thinking by combining the data and code logic. However, it's totally legitimate to say functions wrapped up the procedures or transformations l.
- dgb23 5y ago
  But this is more about shifting focus. You still need both, data and functions even if you make data richer and functions more general and simple. The latter still carry or encode an essential part about how you model information. Especially if we consider this quote here: "Syntax without representation is tyranny!" - Gerald Jay Sussman
- Diggsey 5y ago
  It seems like you missed the point the article was trying to make: an abstraction is a mapping from a complex world to a simpler world, which preserves the ability to perform many useful operations. Data structures can be used as part of an abstraction. So can functions. But neither one is the abstraction. In the case of data structures, you might use a particular data-structure as the domain of the simpler world, but it's the mapping itself that is the abstraction, and that mapping is not part of the code, it's a conceptual thing that must be documented. All of those quotes say how important data and its representation is to a programmer, but that doesn't equate to saying data structures are abstractions, because abstractions aren't the only important thing. I'm not sure they're even the most important thing.
jakelazaroff 5y ago
He’s talking about what this article calls “anti-unification”, but this Bret Victor post really changed the way I think about abstraction: http://worrydream.com/LadderOfAbstraction/ http://worrydream.com/LadderOfAbstraction/
- avgcorrection 5y ago
  Looks more like parameterization.
Garlef 5y ago
> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." That's catchy. But: The practice of programming is about manipulating a special kind of data (code). And so: "Good programmers worry about code structures and their relationships." (Even more so in the age of devops, infrastructure as code, etc.)
ChrisMarshallNY 5y ago
I don’t mind the basic interpretation of abstraction that the article mentions, but I generally extend it to also mean that code (not just the coder) doesn’t have to deal with the underlying complexity. For example, I consider most SDKs to be abstractions. It’s really just semantics, as I guess we could argue that the “classic” definition applies to code, as well as to coders.
ncmncm 5y ago
Religious devotion to abstraction is a common failing in younger coders. Abstraction performs a valuable service when it reliably masks details irrelevant to your task. It is actively harmful when it conceals from you details important to your task. A common example of a harmful abstraction, in C and C++, is a typedef of a pointer to an opaque name. The typedef conceals, when you read code using it, that the type is really a pointer, and so subject to all the excess operations provided for pointers in those languages. But one thing every C and C++ programmer always needs to know about a type they are working with is whether it is a pointer. Every abstraction has an unavoidable cost. The value it provides has to exceed that cost for it not to be a liability. Usually the main cost is that it is not as comprehensively documented as its creator imagines (if at all), and the user cannot trust what it will do without tracing through and understanding what details and pitfalls it hides. The more comprehensive its documentation, the more time it takes to read and understand, and the more likely it is to be, or later become, inaccurate. Thus, part of the job of every programmer is to distrust abstractions. An abstraction works on cases it has been seen to work on, but often cannot be trusted otherwise. This is what makes Standard Library abstractions valuable: you have confidence the implementation has been verified to match the specification, and the specification (1) has been carefully designed to avoid pitfalls and (2) documents them, where it cannot. J. Random Abstraction in your local library rarely gets that much attention. Make your abstractions earn their keep.
- userbinator 5y ago
  In my experience, beginners tend to underabstract, and it's the intermediately-experienced ones that go too far in the other direction. The most experienced ones are somewhere in the middle and closer to using abstractions where they make sense. Unfortunately, the majority of the community and industry is in the middle group.
  - ratww 5y ago
    Yep, my experience as well. I'd say (in keeping with the article's terms) that the intermediately-experienced tend to overuse indirection, but underuse abstraction.
  - 5y ago
Helloyello 5y ago
userbinator 5y ago
Its opposite is unification, which is comparatively never used in programming. Isn't that just what people usually refer to as "inlining"?
vjust 5y ago
You could fill pages on the subject of abstraction. While on the subject it would've been apt for the Author to quote or give a nod to the one of the pioneers in this field : Barbara Liskov, and the Liskov substitution principle. Not that I've anything against Joel Spolsky - but I'd read Liskov any day over Joel's. So easy to get wrapped up in all the syntactic sugar.
dustingetz 5y ago
The lambda calculus definition of abstraction as lambda i think matches the idea that abstractions are not found in code. Performance constraints IRL are the key operational gap that mathematical lambda does not account for – as lambda cannot effectively account for hardware execution and network – and the sole reason (AFAICT) that the implementing code of an IRL software system running on hardware cannot contain true abstraction, and thus as software practitioners we should not seek them. Instead, we should seek to minimize LOC which has direct tangible impact on costs and outcome.
Kalanos 5y ago
This is an abstraction: https://medium.com/towards-data-science/hypertuning-for-tensorflow-pytorch-a6e117e4655e https://medium.com/towards-data-science/hypertuning-for-tens...
theknocker 5y ago
btbuildem 5y ago
I've come to understand abstraction as a reduction of something complex into something symbolic that captures the bare minimum / absolute essence of the reduced thing, and not necessarily in an obvious way. In programming, it could be the boundaries of a concept independent of implementation. In visual art, it could be a few lines on canvas that evoke the spirit of the thing referenced. In jazz, it could be strange notes on the peripheries and askew of rhythm that by being what is not, circumscribe what is.
hzhou321 5y ago
> Abstraction in general is usually said to be something which helps readers understand code without delving into the details. I agree with this. And to me, this means a good abstraction is necessary to be ambiguous. For example, number is an abstraction. But a type that is int32 is not an abstraction. In fact, we are not using a meta-layer that allow ambiguity is the reason that most abstractions force readers to be concerned with details in order to understand code. Math abstractions are good and rigorous. That is because math is never concerned with reality. As soon as you deal with reality, math is ambiguous from start to end. For example, what is one? Math throw away all the physical details, that is what allows it to be useful -- one can understand math without ever concerned with physical details. The current popular programming language are not suitable for abstractions. Our natural language are good for abstractions. But I think we probably can have something in-between, like what we come up with math.
- Koshkin 5y ago
  These are all very abstract statements. (And you are not wrong.)
- lalaithion 5y ago
  What? How is int32 not an abstraction? There's no such thing as a "real" int32; it's just a bunch of metal in a box with electricity in it.
  - hzhou321 5y ago
    Abstraction is about the core idea without distracting details. Your core idea is likely to either have a finite bound (if the core idea includes bound) or have no bound (if your core idea is just about number). `int32` have the detail of signedness, minimum and maximum bound, underflow and overflow behaviors. Those are distracting details. And those are precise details. Thus, it is not a abstraction at all. It's like a specific 3-lb hammer, is that an abstraction of your hammer?
    - lalaithion 5y ago
      But an int32 is an abstraction over even lower details: alignment, endianness, and all of the compiler and hardware implementations of signedness, boundedness, and overflow behaviors. There are multiple layers of abstraction. int32 is just one layer lower than you're used to.
pete_nic 5y ago
Non-developer here that likes to try to understand CS. I have latched onto this definition from Stanford: “But fundamentally, computer science is a science of abstraction — creating the right model for thinking about a problem and devising the appropriate mechanizable techniques to solve it.” http://infolab.stanford.edu/~ullman/focs/ch01.pdf http://infolab.stanford.edu/~ullman/focs/ch01.pdf
alfonsodev 5y ago
for me to abstract, is to elevate a concept to a parent category so that operations are interchangeable with other siblings. Wether to know if something is an abstraction, could be tested by asking, is this thing useful to operate with different child categories in just one place ? When you have an abstraction with just one child category, rather than useful is just confusing. For example if in your universe would exist just on type of Vehicle called Car, but you would use Vehicle abstraction.
waffletower 5y ago
Abstraction is not what you think it is if you think it is not what I think it is.
eternityforest 5y ago
This is really interesting! Encapsulation might be a more appropriate word in most cases, since abstraction doesn't tell you what specifically you're abstracting away from. Coming from OOP, I've always thought of abstraction as just "A thing that hides the real nature of something and presents it as a standard and simplified model, and lets you ignore more things than the non-abstract truth allows". drawImage(file, x, y) is an abstraction, because I don't need to know how it works or how it knows what decoder to use. One might even say a toilet is an abstraction because what goes into it is(Presumably) dealt with in a sanitary manner by professionals. Things like monads and composition are abstractions in the colloquial sense, objects far from some concrete thing like a car or a pen, but using them effectively requires understanding the logic, so in a sense they are leaky, because the act of using them "leaks" the mathematical logic, and subjectively nothing like that comes to mind when I think of abstractions in programming. They're definitely abstractions, but they are used to reveal and illuminate a program's structure, not to hide it in a black box.
- reidjs 5y ago
  > They're definitely abstractions, but they are used to reveal and illuminate a program's structure, not to hide it in a black box. In my mind, abstractions are used to reveal the program's interface and intent more than its structure. The functions, data structures, variables, and ultimately the source code reveal the program's true structure.
skybrian 5y ago
This seems like an ultimately doomed attempt to redefine the suitcase term "abstraction" to be something more mathematical. But you aren't going to change how people use the word "abstraction" by telling them they're using it wrong. If you need a more precise terminology, it would be better to come up with some different words or phrases and popularize them.
- Koshkin 5y ago
  > something more mathematical It has been done. Category Theory (a.k.a. "abstract nonsense") has been pretty successful describing abstraction using the language of functors.
hathawsh 5y ago
The concept of abstraction is simple and clear when you think about programming as primarily the act of teaching other people (future maintainers, other contributors, and my forgetful self) rather than writing instructions for a computer. An abstraction is simply a grouping of human-level concepts. Good abstractions are generally easy to teach and learn. Some abstractions are more useful/helpful/powerful than others. The usefulness of an abstraction often depends on the domain. Much of the time, the best way to find out the right abstractions is to first create multiple things with no new abstractions, then decide that everyone will save time if you merge some of the concepts you created. It's good to use well-known, tested abstractions early on, but it's risky to create new abstractions prematurely. Sometimes a function, data structure, interface, or API happens to embody an abstraction very cleanly. When that works out, the abstraction is easy to teach and tends to be more useful. Most abstractions are a bit messier than that, though, which is why abstraction is really a human-level teaching/learning construct rather than any element of programming languages.
CoastalCoder 5y ago
A tangent about writing conventions: It pisses me off when a headline tells me that I'm understanding / doing something wrong. I realize this is subjective, but I hear it as the author arrogantly assuming that their insight or approach is objectively better than those of their entire audience. Without even knowing their audience members are. They just know they're more correct than you, and they're happy to advertise that. I'm sure it drives engagement, but it definitely reduce the chance of me reading the article.
layer8 5y ago
What the article describes as the true meaning of "abstraction" is very close to (if not the same) as "interface contract", and it’s correct that the important quality is to enable precise reasoning (of which “abstract interpretation” is one possible form) about the program behavior along that abstraction/interface boundary. Functions have an interface contract, classes have an interface contract, data types have an interface contract, things like REST APIs have an interface contract, and so on. The fact that some languages, as mentioned in the article, have a language feature called “interface” is somewhat unfortunate, because it makes unclear when someone says “interface” whether they refer to the language feature or to the more general meaning. (For example, every Java class has an interface-in-the-general-sense, just like every class has an implementation, regardless of whether the class happens to implement an interface-the-language-feature or not.) Prior to that, it was always understood that “interface” implies a certain contract, usually one that imposes conditions beyond the mere type signature of the respective entity. Incidentally, that’s also one benefit of nominal typing (as opposed to structural typing), because it expresses the fact that the interface is usually more than its type signature, and therefore two entities having compatible type signatures are not necessarily compatible in terms of their interface contract, and thus shouldn’t be implicitly convertible/assignable to each other.

163 points by tempodox 5y ago

I think of an abstraction as a map from a model space into the problem domain. (A map that is not necessarily injective, and sure enough not surjective.) I am sure category theory can say much about this.

UncleMeat 5y ago
The whole point of the article is providing a rigorous definition rather than the wishy-washy stuff people usually use. This is independent of category theory. Cousot was working in a different space.
- Koshkin 5y ago
  No, I thoroughly appreciate that, it's just that the functorial language of the "abstract nonsense" seems perfect for discussing modeling and abstraction.

smitty1e 5y ago

If asked, I'd've said: "Applied ontology[1]". When we code, we're philosophizing about information in some language (itself an applied ontology), for the decreasingly worse. Occasionally one arrives at a coherent, stable product. [1] https://en.wikipedia.org/wiki/Ontology https://en.wikipedia.org/wiki/Ontology

adamkl 5y ago

Reading this makes me think of "stratified"[0] design, which I think is a good example of abstraction done right. [0] - https://medium.com/clean-code-development/stratified-design-over-layered-design-125727c7e15 https://medium.com/clean-code-development/stratified-design-...

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

andrewingram 5y ago

I've come to think of an abstraction as a potentially lossy transformation of a model into one better suited to the task at hand.

busyant 5y ago
Interesting. You've made me realize that models (in the scientific sense) are lossy transformations of reality.
- andrewingram 5y ago
  Yeah, this is how I think about Newtonian Mechanics -- a useful abstraction.
  - Koshkin 5y ago
    Starting with “point particle.” (By the way, theoretical mechanics has long been considered part of mathematics.)
- dTal 5y ago
  Moreover, the point of a model is to be lossy: https://en.wikipedia.org/wiki/On_Exactitude_in_Science https://en.wikipedia.org/wiki/On_Exactitude_in_Science
  - arethuza 5y ago
    Spherical cows being the obvious example - in some circumstances that might be a perfectly valid modelling assumption.
ncmncm 5y ago
... to one somebody hoped was better suited to the task. That hope is not necessarily realized. If it is not lossy, it is likely not to be providing net value.
- 5y ago

nathias 5y ago

This is a fairly common sense notion of abstraction (abstraction as abstracting away the details of something), but I don't think its the whole picture. I'm studying abstraction and the best formulation of this aspect I found was abstraction as the degree of complexity encapsulation.

prionassembly 5y ago
Yea, but this complexity is not inherent to code.
- nathias 5y ago
  What do you mean? Of course it is, all code is leaky abstractions.

SPBS 5y ago

Basically functions are not abstractions, the data structures that functions act on are the real abstractions. Because the data structures have been planned out in a particular way, functions can manipulate them as if they were manipulating concrete entities in the business domain. Here's a bunch of relevant quotes talking about that idea (credits to https://medium.com/webdevops/data-structures-548cbea9c520 https://medium.com/webdevops/data-structures-548cbea9c520) "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - Linus Torvalds "Fold knowledge into data, so program logic can be stupid and robust." - Eric S. Raymond "Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." - Rob Pike "Representation is the Essence of Programming" - Fred Brooks "One of the key attributes of a "Good" representation, is the ease in which it is transformed into other valid information the computer can process." - https://www.cs.utah.edu/~germain/PPS/Topics/information_representation_and_transformations.html https://www.cs.utah.edu/~germain/PPS/Topics/information_repr...

lobstey 5y ago
cannot agree on that. Here you got the OO ways of thinking by combining the data and code logic. However, it's totally legitimate to say functions wrapped up the procedures or transformations l.
dgb23 5y ago
But this is more about shifting focus. You still need both, data and functions even if you make data richer and functions more general and simple. The latter still carry or encode an essential part about how you model information. Especially if we consider this quote here: "Syntax without representation is tyranny!" - Gerald Jay Sussman
Diggsey 5y ago
It seems like you missed the point the article was trying to make: an abstraction is a mapping from a complex world to a simpler world, which preserves the ability to perform many useful operations. Data structures can be used as part of an abstraction. So can functions. But neither one is the abstraction. In the case of data structures, you might use a particular data-structure as the domain of the simpler world, but it's the mapping itself that is the abstraction, and that mapping is not part of the code, it's a conceptual thing that must be documented. All of those quotes say how important data and its representation is to a programmer, but that doesn't equate to saying data structures are abstractions, because abstractions aren't the only important thing. I'm not sure they're even the most important thing.

jakelazaroff 5y ago

He’s talking about what this article calls “anti-unification”, but this Bret Victor post really changed the way I think about abstraction: http://worrydream.com/LadderOfAbstraction/ http://worrydream.com/LadderOfAbstraction/

avgcorrection 5y ago
Looks more like parameterization.

Garlef 5y ago

> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." That's catchy. But: The practice of programming is about manipulating a special kind of data (code). And so: "Good programmers worry about code structures and their relationships." (Even more so in the age of devops, infrastructure as code, etc.)

ChrisMarshallNY 5y ago

I don’t mind the basic interpretation of abstraction that the article mentions, but I generally extend it to also mean that code (not just the coder) doesn’t have to deal with the underlying complexity. For example, I consider most SDKs to be abstractions. It’s really just semantics, as I guess we could argue that the “classic” definition applies to code, as well as to coders.

ncmncm 5y ago

Religious devotion to abstraction is a common failing in younger coders. Abstraction performs a valuable service when it reliably masks details irrelevant to your task. It is actively harmful when it conceals from you details important to your task. A common example of a harmful abstraction, in C and C++, is a typedef of a pointer to an opaque name. The typedef conceals, when you read code using it, that the type is really a pointer, and so subject to all the excess operations provided for pointers in those languages. But one thing every C and C++ programmer always needs to know about a type they are working with is whether it is a pointer. Every abstraction has an unavoidable cost. The value it provides has to exceed that cost for it not to be a liability. Usually the main cost is that it is not as comprehensively documented as its creator imagines (if at all), and the user cannot trust what it will do without tracing through and understanding what details and pitfalls it hides. The more comprehensive its documentation, the more time it takes to read and understand, and the more likely it is to be, or later become, inaccurate. Thus, part of the job of every programmer is to distrust abstractions. An abstraction works on cases it has been seen to work on, but often cannot be trusted otherwise. This is what makes Standard Library abstractions valuable: you have confidence the implementation has been verified to match the specification, and the specification (1) has been carefully designed to avoid pitfalls and (2) documents them, where it cannot. J. Random Abstraction in your local library rarely gets that much attention. Make your abstractions earn their keep.

userbinator 5y ago
In my experience, beginners tend to underabstract, and it's the intermediately-experienced ones that go too far in the other direction. The most experienced ones are somewhere in the middle and closer to using abstractions where they make sense. Unfortunately, the majority of the community and industry is in the middle group.
- ratww 5y ago
  Yep, my experience as well. I'd say (in keeping with the article's terms) that the intermediately-experienced tend to overuse indirection, but underuse abstraction.
- 5y ago

Helloyello 5y ago

userbinator 5y ago

Its opposite is unification, which is comparatively never used in programming. Isn't that just what people usually refer to as "inlining"?

vjust 5y ago

You could fill pages on the subject of abstraction. While on the subject it would've been apt for the Author to quote or give a nod to the one of the pioneers in this field : Barbara Liskov, and the Liskov substitution principle. Not that I've anything against Joel Spolsky - but I'd read Liskov any day over Joel's. So easy to get wrapped up in all the syntactic sugar.

dustingetz 5y ago

The lambda calculus definition of abstraction as lambda i think matches the idea that abstractions are not found in code. Performance constraints IRL are the key operational gap that mathematical lambda does not account for – as lambda cannot effectively account for hardware execution and network – and the sole reason (AFAICT) that the implementing code of an IRL software system running on hardware cannot contain true abstraction, and thus as software practitioners we should not seek them. Instead, we should seek to minimize LOC which has direct tangible impact on costs and outcome.

Kalanos 5y ago

This is an abstraction: https://medium.com/towards-data-science/hypertuning-for-tensorflow-pytorch-a6e117e4655e https://medium.com/towards-data-science/hypertuning-for-tens...

theknocker 5y ago

btbuildem 5y ago

I've come to understand abstraction as a reduction of something complex into something symbolic that captures the bare minimum / absolute essence of the reduced thing, and not necessarily in an obvious way. In programming, it could be the boundaries of a concept independent of implementation. In visual art, it could be a few lines on canvas that evoke the spirit of the thing referenced. In jazz, it could be strange notes on the peripheries and askew of rhythm that by being what is not, circumscribe what is.

hzhou321 5y ago

> Abstraction in general is usually said to be something which helps readers understand code without delving into the details. I agree with this. And to me, this means a good abstraction is necessary to be ambiguous. For example, number is an abstraction. But a type that is int32 is not an abstraction. In fact, we are not using a meta-layer that allow ambiguity is the reason that most abstractions force readers to be concerned with details in order to understand code. Math abstractions are good and rigorous. That is because math is never concerned with reality. As soon as you deal with reality, math is ambiguous from start to end. For example, what is one? Math throw away all the physical details, that is what allows it to be useful -- one can understand math without ever concerned with physical details. The current popular programming language are not suitable for abstractions. Our natural language are good for abstractions. But I think we probably can have something in-between, like what we come up with math.

Koshkin 5y ago
These are all very abstract statements. (And you are not wrong.)
lalaithion 5y ago
What? How is int32 not an abstraction? There's no such thing as a "real" int32; it's just a bunch of metal in a box with electricity in it.
- hzhou321 5y ago
  Abstraction is about the core idea without distracting details. Your core idea is likely to either have a finite bound (if the core idea includes bound) or have no bound (if your core idea is just about number). `int32` have the detail of signedness, minimum and maximum bound, underflow and overflow behaviors. Those are distracting details. And those are precise details. Thus, it is not a abstraction at all. It's like a specific 3-lb hammer, is that an abstraction of your hammer?
  - lalaithion 5y ago
    But an int32 is an abstraction over even lower details: alignment, endianness, and all of the compiler and hardware implementations of signedness, boundedness, and overflow behaviors. There are multiple layers of abstraction. int32 is just one layer lower than you're used to.

pete_nic 5y ago

Non-developer here that likes to try to understand CS. I have latched onto this definition from Stanford: “But fundamentally, computer science is a science of abstraction — creating the right model for thinking about a problem and devising the appropriate mechanizable techniques to solve it.” http://infolab.stanford.edu/~ullman/focs/ch01.pdf http://infolab.stanford.edu/~ullman/focs/ch01.pdf

alfonsodev 5y ago

for me to abstract, is to elevate a concept to a parent category so that operations are interchangeable with other siblings. Wether to know if something is an abstraction, could be tested by asking, is this thing useful to operate with different child categories in just one place ? When you have an abstraction with just one child category, rather than useful is just confusing. For example if in your universe would exist just on type of Vehicle called Car, but you would use Vehicle abstraction.

waffletower 5y ago

Abstraction is not what you think it is if you think it is not what I think it is.

eternityforest 5y ago

This is really interesting! Encapsulation might be a more appropriate word in most cases, since abstraction doesn't tell you what specifically you're abstracting away from. Coming from OOP, I've always thought of abstraction as just "A thing that hides the real nature of something and presents it as a standard and simplified model, and lets you ignore more things than the non-abstract truth allows". drawImage(file, x, y) is an abstraction, because I don't need to know how it works or how it knows what decoder to use. One might even say a toilet is an abstraction because what goes into it is(Presumably) dealt with in a sanitary manner by professionals. Things like monads and composition are abstractions in the colloquial sense, objects far from some concrete thing like a car or a pen, but using them effectively requires understanding the logic, so in a sense they are leaky, because the act of using them "leaks" the mathematical logic, and subjectively nothing like that comes to mind when I think of abstractions in programming. They're definitely abstractions, but they are used to reveal and illuminate a program's structure, not to hide it in a black box.

reidjs 5y ago
> They're definitely abstractions, but they are used to reveal and illuminate a program's structure, not to hide it in a black box. In my mind, abstractions are used to reveal the program's interface and intent more than its structure. The functions, data structures, variables, and ultimately the source code reveal the program's true structure.

skybrian 5y ago

This seems like an ultimately doomed attempt to redefine the suitcase term "abstraction" to be something more mathematical. But you aren't going to change how people use the word "abstraction" by telling them they're using it wrong. If you need a more precise terminology, it would be better to come up with some different words or phrases and popularize them.

Koshkin 5y ago
> something more mathematical It has been done. Category Theory (a.k.a. "abstract nonsense") has been pretty successful describing abstraction using the language of functors.

hathawsh 5y ago

The concept of abstraction is simple and clear when you think about programming as primarily the act of teaching other people (future maintainers, other contributors, and my forgetful self) rather than writing instructions for a computer. An abstraction is simply a grouping of human-level concepts. Good abstractions are generally easy to teach and learn. Some abstractions are more useful/helpful/powerful than others. The usefulness of an abstraction often depends on the domain. Much of the time, the best way to find out the right abstractions is to first create multiple things with no new abstractions, then decide that everyone will save time if you merge some of the concepts you created. It's good to use well-known, tested abstractions early on, but it's risky to create new abstractions prematurely. Sometimes a function, data structure, interface, or API happens to embody an abstraction very cleanly. When that works out, the abstraction is easy to teach and tends to be more useful. Most abstractions are a bit messier than that, though, which is why abstraction is really a human-level teaching/learning construct rather than any element of programming languages.

CoastalCoder 5y ago

A tangent about writing conventions: It pisses me off when a headline tells me that I'm understanding / doing something wrong. I realize this is subjective, but I hear it as the author arrogantly assuming that their insight or approach is objectively better than those of their entire audience. Without even knowing their audience members are. They just know they're more correct than you, and they're happy to advertise that. I'm sure it drives engagement, but it definitely reduce the chance of me reading the article.

layer8 5y ago

What the article describes as the true meaning of "abstraction" is very close to (if not the same) as "interface contract", and it’s correct that the important quality is to enable precise reasoning (of which “abstract interpretation” is one possible form) about the program behavior along that abstraction/interface boundary. Functions have an interface contract, classes have an interface contract, data types have an interface contract, things like REST APIs have an interface contract, and so on. The fact that some languages, as mentioned in the article, have a language feature called “interface” is somewhat unfortunate, because it makes unclear when someone says “interface” whether they refer to the language feature or to the more general meaning. (For example, every Java class has an interface-in-the-general-sense, just like every class has an implementation, regardless of whether the class happens to implement an interface-the-language-feature or not.) Prior to that, it was always understood that “interface” implies a certain contract, usually one that imposes conditions beyond the mere type signature of the respective entity. Incidentally, that’s also one benefit of nominal typing (as opposed to structural typing), because it expresses the fact that the interface is usually more than its type signature, and therefore two entities having compatible type signatures are not necessarily compatible in terms of their interface contract, and thus shouldn’t be implicitly convertible/assignable to each other.