Item — HN Reader

I'm not sure what this has to do with abstractions. What I call abstraction is a cognitive pattern that allows me to model a specific entity with a semantic that foregoes any implementation specific details.

Example of abstraction: file descriptors. I can open()/read()/write()/close() [to/from] a file descriptor and I can model and understand the semantics of it without knowing what's "behind" the file descriptor. Is it a pipe? Is it a network socket? Is it a file on the drive? a partition? a whole drive? a logical volume across many drives? perhaps encrypted? I don't care! That's what the abstraction brings to me: not needing to care.

Not needing to care reduces the cognitive load on me, which means it reduces complexity. Since our propensity to make mistakes increases very quickly with complexity, keeping it low is key to success.

What the article describes instead is breaking down code into individual functions, and the common trap associated with imaginary requirements ("You can imagine a case where someone would like to call it from elsewhere").

1 comments

> “Not needing to care reduces the cognitive load on me, which means it reduces complexity. Since our propensity to make mistakes increases very quickly with complexity, keeping it low is key to success.”

I actually have come to disagree strongly with this beyond a very, very tiny amount of basic attribute encapsulation, over my career.

Inevitably, 99% of your time becomes dealing with the headache of how the abstraction hides the underlying details at the next reductive step down the chain. You quickly realize that the “win” you get from being able to express a program more concisely in terms of a layer of intermediate abstractions is pretty meaningless, because the number one thing you and all future code readers will need is immediate visibility into how properties of the implementation result in certain resource usage, running time, etc. The number one day to day activity will be performing surgery at some layer below the top line abstraction, to such a degree that the abstraction is nothing more than a nuisance.

This is also one reason why a functional style tends to work so well. You separate data encapsulation (in dumb no-method, no-inheritance record types) from instruction encapsulation (just functions), and the abstraction does not have much effect on visibility of the primitives it relies on from the next lower reductive layer of components.