[dap]

I’m curious what you think an abstraction is. Even running “ls” involves several layers of abstraction: a shell, a process (abstracts memory), a thread (abstracts CPU)… you think it would be simpler if you had to deal with all that to list a directory (another abstraction)? Even bits are an abstraction over analog voltage levels.

[glitchc]

You're taking it out of context. I'm specifically referring to abstractions introduced in the codebase to maximize code reuse, as per the OP's comment.

[dap]

I don't think these things are as different as you think. I started at "ls" and worked down. If you work up, you get things like a "socket", an "object" within a programming language, a "linked list" in a standard library, an "HTTP client" within an application-level package. You can keep going up and rattle off lots of useful abstractions in application-level code.

There are certainly _bad_ abstractions that ought not to exist, which I think is what you're getting at. There are poorly built abstractions, and leaky abstractions. But abstraction itself isn't the problem -- abstraction is what allows us to build anything at all without being crushed by the sheer complexity.

[glitchc]

You're conflating system level abstractions with code-based abstractions. As a counter-example, introducing a factory constructor to handle object creation makes the codebase harder to understand.