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.

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.

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.

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.

the thing about abstractions is that nothing implies that they aren’t leaky abstractions, which may be worse than no abstraction for future bug hunters