2 ms·
> To successfully use an abstraction, you need to understand the problem the abstraction is trying to solve and also understand how the abstraction has solved t
by ethanbond 3y ago
> To successfully use an abstraction, you need to understand the problem the abstraction is trying to solve and also understand how the abstraction has solved the problem.
What? This seems like the exact wrong way to view abstractions and in fact, you view it the right way even if you think you view it the (silly) way above.
The whole point of abstraction -- not just in software but in everything in the universe -- is that you do not have to know or care about the underlying facts.
The whole stack is abstractions all the way down to the sub-atomic level, so it's obviously untenable for "correct usage" to require knowing the lower levels. Just like you (correctly) don't need to understand structural engineering or wood's growth patterns to sit in a chair made of wood.
It's very useful to know a few layers below the layer at which you primarily operate, but that is a very different from the claim up top.
- michaelfeathers 3y agoObligatory reference to the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... Layers work to the degree that they are trivial, but we really only need them when they are non-trivial.
- ethanbond 3y agoLayers work to the degree that you don't need to be a subatomic particle physicist to write this comment. There are good abstractions and bad ones, all with varying degrees of leakiness and sharp corners. The good ones definitionally prevent you from needing to understand much about what they're abstracting.
- gonational 3y agoAbstraction is real. So is bad code that pretends to be an abstraction. Small leaks in an abstraction are survivable. Small leaks in many layers of abstraction are ruinous.
- vhiremath4 3y agoThis depends on responsibility. If you are working within a service you own, you might be working with a bunch of abstractions you need to know because it's your responsibility to. Layers that bifurcate responsibility (and usually team boundaries) should be readable without needing to intimately understand what problem the abstraction is trying to solve. To say you never need to understand what problem the abstraction is trying to solve (or you always need to) doesn't quite strike the practicality of how teams work together in my experience. That said, in my experience, there are a ton of leaky abstractions that really shouldn't be too.