Hacker News Reader

Comment by okaleniuk | Hacker News Reader

"Abstraction" is a misnomer. This word has its useful meaning in math and art, but in software engineering, all what we call "abstraction" is automation in disguise. When you write a piece of "abstract" code, you only delegate writing the piece of concrete code to your compiler or run-time type deduction.

And as soon as this is clear, the attitude follows. Should you know how every aspect of your code is compiled or interpreted? Not really. Should you realize that every automation takes resources, creates accidental knowledge, and introduces its own probability of failure? Yes.

View on HN

This is a useful insight, but I think that many automations really are based on solid, honest-to-goodness abstractions of the same type you would find in math. Furthermore, that's good and important!

It's true that a compiler is merely translating a high-level language into the actual machine code, but it's simultaneously true that you can (generally) talk sensibly about the high-level language, and maybe even prove theorems about it, without making any reference to how it will be realized on the machine. That's a good abstraction.

The better your abstractions, the more your automations make sense, and the more you can reason about them. Automation without abstraction gives you biology, which is a gnarly mess of accidental complexity that's very difficult to reason about and control.

That said, I'm going to start thinking of my code more in terms of creating efficient and low-risk automation, and less about creating nice abstractions.

Yes. I agree with you wholeheartedly, and that's exactly why I have to insist that the phenomena we're talking about is not an abstraction but something else.

You see, there is no such thing as a "good abstraction" or a "bad abstraction". In math, algebraic systems are either isomorphic or not. There is no qualitative quality to a fact. It is only in software, abstraction acquires this immeasurable quality of goodness, or leakyness, or even fashionability.

"Automation in disguise" is not a good term either. But I find it slightly less misleading and such as it brings less false promises in the connotations.

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.

I 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.

I disagree and believe "abstraction" is the correct term for wgat the author intended.

> Computer science commonly presents levels (or, less commonly, layers) of abstraction, wherein each level represents a different model of the same information and processes, but with varying amounts of detail.

See: https://en.m.wikipedia.org/wiki/Abstraction_(computer_scienc...

I think it’s very common for developers to mistake indirection for abstraction.

I don't challenge the author's use of the word "abstraction", I challenge the validity of the very word "abstraction" in the context of computer science. What we're dealing here is not abstraction, it is something else. But thinking of is as of abstraction brings us to the state of affairs the author criticises.

If you remember that there is very specific very concrete automation behind every abstraction, you don't stack them up until the pile becomes impossible to either control or understand.

Those terms go hand-in-hand. Like a compiler, abstraction in art is essentially delegating some of the work to the audience.

Don't get me started on compilers. Compilers don't compile. Linkers compile. Compilers should have been called translators from the start.

Reply on news.ycombinator.com