5 ms·

I wrote the piece. The argument I tried to get across is: "You must use abstractions. Find the ones whose values align with your interests." I find people fr

I wrote the piece. The argument I tried to get across is: "You must use abstractions. Find the ones whose values align with your interests." I find people frequently torturing their problems into abstractions they like rather than finding abstractions that work for their applications, and this is very much wrong. Edit: By the way, the examples are fairly low-level databases because that's what I know about. If I knew about web frameworks, I would have used those instead.

danielmarkbruce 4y ago
The material is good, nice going. But the title is misleading.
- danShumway 4y ago
  I would argue that abstractions are usually expensive. It's just that sometimes not doing something expensive is also expensive. Getting your car regularly maintained is expensive, so is not doing that. The issue with abstractions is that people have not internalized them as "an expensive thing we do to prevent ourselves from running into expensive problems later"; they're internalized them as a zero/low-cost process that has no downsides and thus should be pursued all the time. It's like if people said, "not getting your oil changed will be more expensive, and therefore I get my oil changed every other week." I kind of think that the only reason that the phrase "abstractions are expensive" sounds like a controversial take is precisely because people have not internalized that abstractions are not a binary good/bad thing and that they should be applied situationally, because they do have maintenance costs and development costs.
  - danielmarkbruce 4y ago
    Sure, the statement isn't wrong. But the content is mostly about making good/consistent choices given the situation.
    - danShumway 4y ago
      > But the content is mostly about making good/consistent choices given the situation. That's what I'm saying though. You need to make good/consistent choices about the given situation because abstractions are expensive, not free. If they were free, we'd just throw them everywhere with no thought.
      - danielmarkbruce 4y ago
        What you are saying isn't wrong, but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it". To make an analogy: people shouldn't buy a sports car if they want to take their family of 5 skiing every weekend. A person might reasonably write an article on all the factors one should consider when buying a car. They shouldn't title said article "Cars are expensive", even though the reason they wrote the article is because cars are expensive and hence the choice is important.
        danShumway 4y ago
        > but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it". I suppose? But if someone's attitude is that expensive things should be universally avoided, that seems like a problem that's going to need to be addressed sooner or later. Would we be having this conversation under an article titled "abstractions have benefits"? Would we be worried that someone is going to look at that title and think, "I should use them everywhere all the time then"? I don't know. I'm not against phrasing something in a way that minimizes confusion, but on some level I think that internalizing that programming concepts aren't binary good/bad is arguably one of the most important lessons that a programmer can learn. And I regularly see a kind of pushback to the (correct) notion that abstractions have costs that I don't see in other contexts. But that could just be, and my experiences might be different than other people's. This is largely a subjective take by me, so I understand if people disagree with it, but the prevailing attitude I personally see in software development is one where people do not realize that there is a cost to abstractions, and in fact sometimes bristle at the idea that they do have costs. At most, I can get people to agree that 'bad' abstractions have costs, but it is much harder to get them to say, "it's possible to abstract too much, and even good and necessary abstractions are still additional code with additional costs." So I think the notion that it is not always correct to abstract every piece of code is weirdly controversial -- and the underlying idea behind that that I think people haven't internalized is "sometimes good things have a cost, and we should talk about the costs that they have." But again, could just be me. If a bunch of people are confused over the title, then... I mean, I can't tell people what they should and shouldn't be confused about. If it's better to communicate with them in a different way, then it is what it is. It just worries me if on a programming site so many people interpret "is expensive" as "should never be used." That's not a good programming philosophy for people to have.
  - pclmulqdq 4y ago
    That's very well-phrased, and you beat me to this comment. :) I wanted to get across that an abstraction is an expensive thing you should use to solve a difficult problem, not a cheap thing you use to solve a simple problem.
    - infogulch 4y ago
      > abstraction is an expensive thing you should use to solve a difficult problem, not a cheap thing you use to solve a simple problem Nailed it.
- pclmulqdq 4y ago
  Thank you. I will add that the title is intentionally provocative. However, I want to encourage developers to think of an abstraction as something you pay a significant cost for rather than something you get for free, and use that logic to make good choices. In a sense, you hire abstractions a little like you hire employees. Interview them and make sure your values match.
  - danielmarkbruce 4y ago
    "abstraction in expensive" makes people think you are implying one shouldn't use abstraction. It's all well and good that the content doesn't say that, but as journalists say: "don't bury the lede".
    - lll-o-lll 4y ago
      Nah, it’s perfect. Provocative, technically true, and when you come back to the title it’s “I have a new insight into this now”.
  - danielmarkbruce 4y ago
    An aside - if you haven't read any Michael Porter, you might find it interesting. https://iqfystage.blob.core.windows.net/files/CUE8taE5QUKZf8ujfYlS_Reading+1.4.pdf https://iqfystage.blob.core.windows.net/files/CUE8taE5QUKZf8... Slightly different concept, but similar ideas around consistency given a set of explicit choices/constraints.
btilly 4y ago
One point about abstractions that you might want to make in a future article is that developers tend to discount the cost of all abstractions that they have internalized. Therefore when they get to a new environment, they immediately try to recreate and incorporate the abstractions that they used previously. However these abstractions are not free. They are not free for performance. They are not free for debugging. And they are especially not free for any future developer who is not familiar with them. The joke I grew up with was, "Andy giveth, and Bill taketh away." It is no longer Intel under Andrew Grove who gives us better performance. It is no longer Microsoft under Bill Gates who gives us slower software. But the basic phenomena is still true. Hardware improves over time. But developers happily introduce abstractions with no awareness of the associated costs.
- throwaway2037 4y ago
  You wrote: <<They are not free for debugging.>> Thank you. Finally, someone acknowledges this important point! I have literally been told that adding extra local variables was "increasing stack size; must be slower". But what about debugging? And, yes, there is a balance to be had between maintenance and speed. Example: Breaking down a critical path section of code into a bunch of tiny non-inline functions may slow down the code unacceptably. In other cases, it may make the code much easier to read, maintain and debug... so the trade-off is acceptable.
- dandelany 4y ago
  Hard agree. On the flipside, devs also tend to overestimate the cost of already-implemented abstractions that they haven’t yet internalized, leading to complaints and lengthy refactors when they could have just spent the time to learn the abstraction…
a_c 4y ago
The same can be said about organization. Too much abstraction, managers and teams, is harming performance. Too little abstraction is hard to coordinate. Putting abstraction in front of problem, throwing problem to previously arbitrarily setup team with or without the right mix of expertise for the current problem. Spinning up libraries/framework automatically when starting a new project, forming teams that worked for previous company. Abstraction that's so leaky that either require code change to the library or "octopus" code that link up functionality from 7 different other libraries, team formed without regarding a problem boundary where each problem need cross team coordination of seven department. Software engineering and organization design have very much in common

danielmarkbruce 4y ago

The material is good, nice going. But the title is misleading.

danShumway 4y ago
I would argue that abstractions are usually expensive. It's just that sometimes not doing something expensive is also expensive. Getting your car regularly maintained is expensive, so is not doing that. The issue with abstractions is that people have not internalized them as "an expensive thing we do to prevent ourselves from running into expensive problems later"; they're internalized them as a zero/low-cost process that has no downsides and thus should be pursued all the time. It's like if people said, "not getting your oil changed will be more expensive, and therefore I get my oil changed every other week." I kind of think that the only reason that the phrase "abstractions are expensive" sounds like a controversial take is precisely because people have not internalized that abstractions are not a binary good/bad thing and that they should be applied situationally, because they do have maintenance costs and development costs.
- danielmarkbruce 4y ago
  Sure, the statement isn't wrong. But the content is mostly about making good/consistent choices given the situation.
  - danShumway 4y ago
    > But the content is mostly about making good/consistent choices given the situation. That's what I'm saying though. You need to make good/consistent choices about the given situation because abstractions are expensive, not free. If they were free, we'd just throw them everywhere with no thought.
    - danielmarkbruce 4y ago
      What you are saying isn't wrong, but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it". To make an analogy: people shouldn't buy a sports car if they want to take their family of 5 skiing every weekend. A person might reasonably write an article on all the factors one should consider when buying a car. They shouldn't title said article "Cars are expensive", even though the reason they wrote the article is because cars are expensive and hence the choice is important.
      - danShumway 4y ago
        > but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it". I suppose? But if someone's attitude is that expensive things should be universally avoided, that seems like a problem that's going to need to be addressed sooner or later. Would we be having this conversation under an article titled "abstractions have benefits"? Would we be worried that someone is going to look at that title and think, "I should use them everywhere all the time then"? I don't know. I'm not against phrasing something in a way that minimizes confusion, but on some level I think that internalizing that programming concepts aren't binary good/bad is arguably one of the most important lessons that a programmer can learn. And I regularly see a kind of pushback to the (correct) notion that abstractions have costs that I don't see in other contexts. But that could just be, and my experiences might be different than other people's. This is largely a subjective take by me, so I understand if people disagree with it, but the prevailing attitude I personally see in software development is one where people do not realize that there is a cost to abstractions, and in fact sometimes bristle at the idea that they do have costs. At most, I can get people to agree that 'bad' abstractions have costs, but it is much harder to get them to say, "it's possible to abstract too much, and even good and necessary abstractions are still additional code with additional costs." So I think the notion that it is not always correct to abstract every piece of code is weirdly controversial -- and the underlying idea behind that that I think people haven't internalized is "sometimes good things have a cost, and we should talk about the costs that they have." But again, could just be me. If a bunch of people are confused over the title, then... I mean, I can't tell people what they should and shouldn't be confused about. If it's better to communicate with them in a different way, then it is what it is. It just worries me if on a programming site so many people interpret "is expensive" as "should never be used." That's not a good programming philosophy for people to have.
- pclmulqdq 4y ago
  That's very well-phrased, and you beat me to this comment. :) I wanted to get across that an abstraction is an expensive thing you should use to solve a difficult problem, not a cheap thing you use to solve a simple problem.
  - infogulch 4y ago
    > abstraction is an expensive thing you should use to solve a difficult problem, not a cheap thing you use to solve a simple problem Nailed it.
pclmulqdq 4y ago
Thank you. I will add that the title is intentionally provocative. However, I want to encourage developers to think of an abstraction as something you pay a significant cost for rather than something you get for free, and use that logic to make good choices. In a sense, you hire abstractions a little like you hire employees. Interview them and make sure your values match.
- danielmarkbruce 4y ago
  "abstraction in expensive" makes people think you are implying one shouldn't use abstraction. It's all well and good that the content doesn't say that, but as journalists say: "don't bury the lede".
  - lll-o-lll 4y ago
    Nah, it’s perfect. Provocative, technically true, and when you come back to the title it’s “I have a new insight into this now”.
- danielmarkbruce 4y ago
  An aside - if you haven't read any Michael Porter, you might find it interesting. https://iqfystage.blob.core.windows.net/files/CUE8taE5QUKZf8ujfYlS_Reading+1.4.pdf https://iqfystage.blob.core.windows.net/files/CUE8taE5QUKZf8... Slightly different concept, but similar ideas around consistency given a set of explicit choices/constraints.

btilly 4y ago

One point about abstractions that you might want to make in a future article is that developers tend to discount the cost of all abstractions that they have internalized. Therefore when they get to a new environment, they immediately try to recreate and incorporate the abstractions that they used previously. However these abstractions are not free. They are not free for performance. They are not free for debugging. And they are especially not free for any future developer who is not familiar with them. The joke I grew up with was, "Andy giveth, and Bill taketh away." It is no longer Intel under Andrew Grove who gives us better performance. It is no longer Microsoft under Bill Gates who gives us slower software. But the basic phenomena is still true. Hardware improves over time. But developers happily introduce abstractions with no awareness of the associated costs.

throwaway2037 4y ago
You wrote: <<They are not free for debugging.>> Thank you. Finally, someone acknowledges this important point! I have literally been told that adding extra local variables was "increasing stack size; must be slower". But what about debugging? And, yes, there is a balance to be had between maintenance and speed. Example: Breaking down a critical path section of code into a bunch of tiny non-inline functions may slow down the code unacceptably. In other cases, it may make the code much easier to read, maintain and debug... so the trade-off is acceptable.
dandelany 4y ago
Hard agree. On the flipside, devs also tend to overestimate the cost of already-implemented abstractions that they haven’t yet internalized, leading to complaints and lengthy refactors when they could have just spent the time to learn the abstraction…

a_c 4y ago

The same can be said about organization. Too much abstraction, managers and teams, is harming performance. Too little abstraction is hard to coordinate. Putting abstraction in front of problem, throwing problem to previously arbitrarily setup team with or without the right mix of expertise for the current problem. Spinning up libraries/framework automatically when starting a new project, forming teams that worked for previous company. Abstraction that's so leaky that either require code change to the library or "octopus" code that link up functionality from 7 different other libraries, team formed without regarding a problem boundary where each problem need cross team coordination of seven department. Software engineering and organization design have very much in common