3 ms·

Abstractions make things more complicated? I think you're missing the basic definition and purpose of abstractions. So how do you define "almost"?

calgoo 10y ago
I think the correct term is complex. Abstractions make things more complex, as there are more moving parts. This normally leads to complications when trying to debug some obscure error that you will get when the project gets bigger. At that point you feel for calling on some ancient deity to spite the developer who decided to use this framework 6 months, until you remember that you proposed it as replacement for the last pile of abstractions to hide the failings of the platform. (Yes there is plenty of sarcasm in here :P )
- afarrell 10y ago
  Which is more complex - an apple or an internal combustion engine? Tis a trick question. The actual complexity experienced by humans depends on the job they are trying to do with the object. If you are a botanist/arborist driving to work, then clearly it is the apple. If you are a mechanic on your lunch break, then clearly it is the engine.
  - Retric 10y ago
    Inherent complexity is often ignorable, but bugs can and will sit anywhere. So, yea the fact an apple is vastly more complex than an engine is not always relevant, but when it is relevant you have real issues.
    - dllthomas 10y ago
      Bugs are much more likely to be in the apple.
- philplckthun 10y ago
  A good abstraction hides complexity without adding major tradeoffs. Presumably an abstraction makes it easier for a developer to reason about what is going on. It's true that abstractions can lead to a lot of trouble when they are failing to work correctly. But when they are good they add a lot of good value. When did you last have to debug a system call, because you couldn't open a file? There are really good, old abstractions that no one thinks about anymore, since they're just really good. A framework in web development is of course another matter, where complexity can sometimes be staggering. I believe that the lifecycle of React components is really nice. Instead of initialising X things you can think about how a single component will change over time. There are endless examples of good and bad abstractions, I guess. But at the end of the day, we have to choose abstractions when we need them to reason about what we're doing, despite adding more points of failures. After all, if an abstraction just enables us to think faster and more clearly about a problem, AND allows us to write less code, that means that less bugs will be in the final product, assuming that the density of bugs is constant. ;)

calgoo 10y ago

I think the correct term is complex. Abstractions make things more complex, as there are more moving parts. This normally leads to complications when trying to debug some obscure error that you will get when the project gets bigger. At that point you feel for calling on some ancient deity to spite the developer who decided to use this framework 6 months, until you remember that you proposed it as replacement for the last pile of abstractions to hide the failings of the platform. (Yes there is plenty of sarcasm in here :P )

afarrell 10y ago
Which is more complex - an apple or an internal combustion engine? Tis a trick question. The actual complexity experienced by humans depends on the job they are trying to do with the object. If you are a botanist/arborist driving to work, then clearly it is the apple. If you are a mechanic on your lunch break, then clearly it is the engine.
- Retric 10y ago
  Inherent complexity is often ignorable, but bugs can and will sit anywhere. So, yea the fact an apple is vastly more complex than an engine is not always relevant, but when it is relevant you have real issues.
  - dllthomas 10y ago
    Bugs are much more likely to be in the apple.
philplckthun 10y ago
A good abstraction hides complexity without adding major tradeoffs. Presumably an abstraction makes it easier for a developer to reason about what is going on. It's true that abstractions can lead to a lot of trouble when they are failing to work correctly. But when they are good they add a lot of good value. When did you last have to debug a system call, because you couldn't open a file? There are really good, old abstractions that no one thinks about anymore, since they're just really good. A framework in web development is of course another matter, where complexity can sometimes be staggering. I believe that the lifecycle of React components is really nice. Instead of initialising X things you can think about how a single component will change over time. There are endless examples of good and bad abstractions, I guess. But at the end of the day, we have to choose abstractions when we need them to reason about what we're doing, despite adding more points of failures. After all, if an abstraction just enables us to think faster and more clearly about a problem, AND allows us to write less code, that means that less bugs will be in the final product, assuming that the density of bugs is constant. ;)