2 ms·
If what you claim were actually the case, the names we assign these "abstractions" wouldn't matter, they could be any arbitrary sequence of characters, since al
by mostlylurks 3y ago
If what you claim were actually the case, the names we assign these "abstractions" wouldn't matter, they could be any arbitrary sequence of characters, since all you'd be doing is grouping code into procedures for the sake of automation. But the names we assign things obviously do matter, not only to make the reader grasp what the abstraction is about, but to decouple the abstraction from its implementation; two different abstractions may have an identical implementation and still be different abstractions, and an abstraction may remain the same abstraction even if you alter its implementation.
- okaleniuk 3y agoI claim that what we call "an abstraction" in software is something else. E. g. while you state that "an abstraction may remain the same abstraction even if you alter its implementation", I insist that the right verb here is "must" and not "may". There is no such thing as "leaky abstraction", "good abstraction", or "an abstraction that only works on x86_64" anywhere else other than in software engineering. And I'm being nitpicky because the word "abstraction" brings in false connotations. It implies that you can reason about things on different levels as if they were equivalent. But in software, they never are. And I agree with the author in that this pretence of equivalency just doesn't hold and adding more and more abstractions on top of each other is not the way to go if you want to understand how things work and how to make them work predictably and efficiently. I don't see how my claim diminishes the importance of naming.