4 ms·

What's the source of this idea that "abstraction" means "combining duplicated code"? An abstraction is a transformation between models that strips away informat

What's the source of this idea that "abstraction" means "combining duplicated code"? An abstraction is a transformation between models that strips away information not essential to the target model. This is an idea firmly planted in semantics, not code coincidence. The first example in the article is a nice demonstration of this happening well. You are transitioning from a model where geometry is unknown to one where at least simple geometry is known. It may not be the most compelling model change ever, but it at least captures the key point - there is a semantic operation going on: calculate the volume of a sphere. The actual formula for doing so isn't important at the level you want to think about your code, so replacing the formula with a function call simplifies the model in which you're working. Contrast that with the example of things going wrong in the next part, with the bad "average" function. What unnecessary details are being removed there? Being sure you're calling that function correctly actually takes more work than calculating an average without it. That's not an abstraction, it's an indirection. You still need to track it down and read the code to understand it. That's not something you have to do with sphere_volume in the preceding part. So how do you know whether duplicated code represents an opportunity for abstraction? You start thinking in terms of the semantics you want to be using. Is the code duplicated because it's doing the same thing, semantically, in your target model? Well then that's an opportunity for abstraction. Or is it just duplicated because it happens to share an implementation? Well then that's just a coincidence. Don't try to share code. Not to suggest that this is an easy test, of course. It's very possible that two things might be different instances of a common problem that you're unaware of, and you have no idea that they share code because they actually are the same. That's ok, and there's always more to learn. But I think if people put more thought into what abstraction is and why it exists, the questions of when and how to use it fade away.

jesseduffield 6y ago
In my mind, abstraction is finding a single representation for various things that share traits. If those things happen to be chunks of code all performing the same task in the same way, then factoring the code into a method would be an example of abstraction. I'm not sure that this definition conflicts with the idea of abstraction being about higher-orderness as another commenter suggests, but I don't think it does. I disagree with your claim that the 'bad' `average` method is an example of indirection rather than abstraction. Indirection, afaik, is about decoupling two things via an interface so that one isn't directly dependent on the implementation of the other. In this case you are still directly calling the method which will directly execute the code. Maybe the dispute here is around whether we should call these things 'the wrong abstraction' or 'a failed attempt at abstraction' but I think it's a spectrum where you can have a good abstraction but with some parts that don't really belong, and in that case it's still an abstraction.
- daviddaviddavid 6y ago
  Not the parent, but I think one of the main differences here is that your definition seems to imply that one abstracts from code where parent's definition seems to imply that one abstracts from the domain which one's computer program is modelling. I'd tend to think that the "chunks of code all performing the same task" aren't the thing you abstract from, rather they are just a poor abstraction of the same domain.
  - jesseduffield 6y ago
    I agree with your distinction, however I'd say that it's abstraction all the way down: the code you write is an abstraction of the business requirements, which is itself an abstraction of the business domain, and when you're dealing with legacy code that nobody understands, it ends up being treated as a defacto domain unto itself. So I don't think the term 'abstraction' should only be reserved for use in reference to the domain because abstraction is already happening at every level anyway.
teambayleaf 6y ago
> What's the source of this idea that "abstraction" means "combining duplicated code"? It's coming from the tradition of Sir Francis Bacon's Empiricism. Some people believe that abstract ideas are mostly acquired thorough empirical observation a.k.a. carefully watching a series of repetitive events. The point here is that "to know" is a synonym of "generalization" for them. So OP naturally puts emphasis on duplicated code as a good opportunity for abstraction. People from other camps have a very different view on human knowledge, and think that abstract ideas can indeed come from other sources, most importantly, from our reasoning function. For these people, the process of programming is to implement our innate idea into concrete code. For them, an actual piece of code is basically a "shadow" of our abstract concept. Hell, someone really should write a book titled "The Logic of Programmatic Discovery" ;)
NumberWangMan 6y ago
The way I've heard Sandi Metz talk about it is basically that Don't Repeat Yourself isn't the important thing, but it's what we tell beginners who don't realise that having 15 copies of the same logic all over their program isn't a good idea. It's a proxy for the idea of abstraction, because that takes much longer to develop a good taste for. And unfortunately, a lot of people learn the quick reminder "Don't Repeat Yourself" without ever hearing the actually definition of the principle: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system", which doesn't roll off the tongue as easily. The DRY principle is a bit easy to corrupt and mis-apply, if you don't ever learn what it really means.
twirlock 6y ago
It's a heuristic for just kind of hopefully involving abstraction. The source is countless blogs and books written confidently by authors who don't actually know what abstraction is, including the Wikipedia page.
proc0 6y ago
Yes, removing duplication is closer to refactoring, not abstracting, although I don't think they are mutually exclusive. Abstracting is hiding everything BUT the essential elements of something. Good abstraction only exposes what's necessary, and thus the epitome of abstraction are interfaces. Coding with good abstractions is about writing interfaces at every level, from the functions to the user. At the mathematical level, Category Theory is the math of abstraction and basically describes interfaces formally.

jesseduffield 6y ago

In my mind, abstraction is finding a single representation for various things that share traits. If those things happen to be chunks of code all performing the same task in the same way, then factoring the code into a method would be an example of abstraction. I'm not sure that this definition conflicts with the idea of abstraction being about higher-orderness as another commenter suggests, but I don't think it does. I disagree with your claim that the 'bad' `average` method is an example of indirection rather than abstraction. Indirection, afaik, is about decoupling two things via an interface so that one isn't directly dependent on the implementation of the other. In this case you are still directly calling the method which will directly execute the code. Maybe the dispute here is around whether we should call these things 'the wrong abstraction' or 'a failed attempt at abstraction' but I think it's a spectrum where you can have a good abstraction but with some parts that don't really belong, and in that case it's still an abstraction.

daviddaviddavid 6y ago
Not the parent, but I think one of the main differences here is that your definition seems to imply that one abstracts from code where parent's definition seems to imply that one abstracts from the domain which one's computer program is modelling. I'd tend to think that the "chunks of code all performing the same task" aren't the thing you abstract from, rather they are just a poor abstraction of the same domain.
- jesseduffield 6y ago
  I agree with your distinction, however I'd say that it's abstraction all the way down: the code you write is an abstraction of the business requirements, which is itself an abstraction of the business domain, and when you're dealing with legacy code that nobody understands, it ends up being treated as a defacto domain unto itself. So I don't think the term 'abstraction' should only be reserved for use in reference to the domain because abstraction is already happening at every level anyway.

teambayleaf 6y ago

> What's the source of this idea that "abstraction" means "combining duplicated code"? It's coming from the tradition of Sir Francis Bacon's Empiricism. Some people believe that abstract ideas are mostly acquired thorough empirical observation a.k.a. carefully watching a series of repetitive events. The point here is that "to know" is a synonym of "generalization" for them. So OP naturally puts emphasis on duplicated code as a good opportunity for abstraction. People from other camps have a very different view on human knowledge, and think that abstract ideas can indeed come from other sources, most importantly, from our reasoning function. For these people, the process of programming is to implement our innate idea into concrete code. For them, an actual piece of code is basically a "shadow" of our abstract concept. Hell, someone really should write a book titled "The Logic of Programmatic Discovery" ;)

NumberWangMan 6y ago

The way I've heard Sandi Metz talk about it is basically that Don't Repeat Yourself isn't the important thing, but it's what we tell beginners who don't realise that having 15 copies of the same logic all over their program isn't a good idea. It's a proxy for the idea of abstraction, because that takes much longer to develop a good taste for. And unfortunately, a lot of people learn the quick reminder "Don't Repeat Yourself" without ever hearing the actually definition of the principle: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system", which doesn't roll off the tongue as easily. The DRY principle is a bit easy to corrupt and mis-apply, if you don't ever learn what it really means.

twirlock 6y ago

It's a heuristic for just kind of hopefully involving abstraction. The source is countless blogs and books written confidently by authors who don't actually know what abstraction is, including the Wikipedia page.

proc0 6y ago

Yes, removing duplication is closer to refactoring, not abstracting, although I don't think they are mutually exclusive. Abstracting is hiding everything BUT the essential elements of something. Good abstraction only exposes what's necessary, and thus the epitome of abstraction are interfaces. Coding with good abstractions is about writing interfaces at every level, from the functions to the user. At the mathematical level, Category Theory is the math of abstraction and basically describes interfaces formally.