3 ms·

You talk as if that's a bad thing. As a developer I don't want to wade into the details of systems I'm using, I want to spend my time writing code that solves

You talk as if that's a bad thing. As a developer I don't want to wade into the details of systems I'm using, I want to spend my time writing code that solves the business problems I'm tasked with solving. If there is a system that allows me to do that by abstracting away the details I don't care about, why wouldn't I use that system?

jschwartzi 7y ago
Because frequently the devil is in the details.
- bluGill 7y ago
  But only some of the details. I still need to ignore most of the details even while I need control of the ones that matter. This is easier said than done.
  - justanotherc 7y ago
    Exactly. The large project I'm working on has 100k LOC that I've personally written. However out od curiosity once I ran CLOC on the vendor folder... and it gave up after 2.5 million LOC. I could never possibly understand all the details going on in there lol.
  - jschwartzi 7y ago
    The devil is in the details of the details.
ben509 7y ago
I do want to wade into the details, so I'd put it more that I need to try many things, and by necessity I have to be a user before I can become an expert. I know a good deal about how Docker works from having hammered at it. I'm not remotely an expert in it yet, but as I go I'm learning more details about cgroups and namespaces, and this is stuff I've been able to fit in while solving problems.
legulere 7y ago
Abstractions usually only work within a boundary. If you understand the underlying implementation you know its limitations. Abstractions help you to not think about the implementation all the time and to have your own code work in a coherent way.
- TeMPOraL 7y ago
  Abstractions are almost never self-contained enough. It's much easier to work within the bounds of an abstraction if you have at least a basic idea about the thing that's being abstracted.
- justanotherc 7y ago
  > If you understand the underlying implementation you know its limitations Maybe in some cases, but then I could probably make a case for that being a poorly built abstraction. All you really need to understand about an abstraction is the required inputs, and the expected output. Having knowledge about what's going on in the black box inside doesn't really serve a functional purpose IMO. This is the very purpose of abstractions. If we sat and reflect on all the abstractions we utilize every day, we would realize we can't possible have intimate knowledge of how they all work. We just don't have enough space in our brains. I have no idea how my OS runs under the hood. I don't care as long as the inputs I provide yield the expected output. Same goes for how my phone connects me on a call, or how my car manages air/fuel ratio in order to control engine power.

jschwartzi 7y ago

Because frequently the devil is in the details.

bluGill 7y ago
But only some of the details. I still need to ignore most of the details even while I need control of the ones that matter. This is easier said than done.
- justanotherc 7y ago
  Exactly. The large project I'm working on has 100k LOC that I've personally written. However out od curiosity once I ran CLOC on the vendor folder... and it gave up after 2.5 million LOC. I could never possibly understand all the details going on in there lol.
- jschwartzi 7y ago
  The devil is in the details of the details.

ben509 7y ago

I do want to wade into the details, so I'd put it more that I need to try many things, and by necessity I have to be a user before I can become an expert. I know a good deal about how Docker works from having hammered at it. I'm not remotely an expert in it yet, but as I go I'm learning more details about cgroups and namespaces, and this is stuff I've been able to fit in while solving problems.

legulere 7y ago

Abstractions usually only work within a boundary. If you understand the underlying implementation you know its limitations. Abstractions help you to not think about the implementation all the time and to have your own code work in a coherent way.

TeMPOraL 7y ago
Abstractions are almost never self-contained enough. It's much easier to work within the bounds of an abstraction if you have at least a basic idea about the thing that's being abstracted.
justanotherc 7y ago
> If you understand the underlying implementation you know its limitations Maybe in some cases, but then I could probably make a case for that being a poorly built abstraction. All you really need to understand about an abstraction is the required inputs, and the expected output. Having knowledge about what's going on in the black box inside doesn't really serve a functional purpose IMO. This is the very purpose of abstractions. If we sat and reflect on all the abstractions we utilize every day, we would realize we can't possible have intimate knowledge of how they all work. We just don't have enough space in our brains. I have no idea how my OS runs under the hood. I don't care as long as the inputs I provide yield the expected output. Same goes for how my phone connects me on a call, or how my car manages air/fuel ratio in order to control engine power.