Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abstraction is expensive

specbranch.com

Post reply on HN
Print view View original

31–40 of 144 posts

Re: Abstraction is expensive

#31

Post by constantcrying »

dlivingston wrote: post #25
ghaff wrote: post #8

Earlier quoted context omitted.

The headline is sort of misleading. It is (appropriately) primarily about inappropriate abstractions. As you say, some abstractions are unavoidable. Even assembly language is an abstraction.

> Even assembly language is an abstraction Is this true? I thought assembly mapped 1-to-1 with actual HW instructions. If so, assembly wouldn't be an abstraction, it would be an interface.

>I thought assembly mapped 1-to-1 with actual HW instructions.

Assembly encodes a wide varity of abstractions (it is a human readable format after all) and lots of assembly instructions have a clear relation to an instruction on the hardware, but definitely not all. E.g. a CPU does not understand what a "label" is and the semantics of a labels and jumping to them is removed by the assembler.

But not even the assembled binary actually maps to executed instructions. The CPU is actually a virtual machine which presents itself as e.g. an x86 ISA interpreter, but internally it uses microcode executed in various performance enhancing ways to speed up the process.

Re: Abstraction is expensive

#32

Post by cwzwarich »

agentultra wrote: post #24
cloogshicer wrote: post #17

Even though many people call abstraction 'the essence of programming', it is rarely fully understood. Maybe no human on the planet really understands it. I've long had an essay in me about this topic that I really need to put to paper soon. Here is the brief version of that essay: * Programming is about building theories/models of the problem. Source code largely has no value by itself [1] * It is very difficult, if…

> it is rarely fully understood I beg to differ. Case in point: type classes, the Monoid type class, and Monoids as the mathematical concept; all well understood, proofs of their existence and properties are stated exactly, and when implemented by a compiler behaves exactly as expected when the program is executed. This is precisely what people mean when they say "abstraction is the essence of progamming"... ... when…

Those abstractions are still leaky, e.g. it's entirely possible that an optimizing compiler could apply correct monoid laws and end up with a program that has vastly different space usage.

Re: Abstraction is expensive

#33

Post by yason »

Abstraction has a slight cost but doesn't inherently mean it's very expensive. The cost of abstraction is generally worth buying because it allows you to write code in more independent blobs which reduces complexity and thus bugs and potential bugs.

But using abstractions to "solve" a hard problem is dearly expensive. By "solving" I mean pushing up the hard parts one layer at a time until you eventually can't avoid solving it for real. At best, maybe you're lucky and someone else has to solve it, by working through all the layers of abstractions you built on your way to negotiate yourself out of the hard spot. But those abstractions are expensive because they don't reduce complexity nor offer any tangible benefit except keeping their creators in their comfort zones.

Re: Abstraction is expensive

#34

Post by falcolas »

I don't know if this will help (or even resonate) with anyone else, but it's helpful to me to view abstractions as a form of DRY.

All developers have created functions to de-duplicate their code. And all developers have consequently seen how the more code a function de-duplicates, the larger and more cumbersome a function becomes; how many more if statements and safety checks come into play.

Now imagine how complex - how many if statements and safety checks and introspection - have to go in to replacing hand-written SQL with custom constructors with an ORM.

Re: Abstraction is expensive

#35

Post by agentultra »

I’d argue that abstraction is cheap. You should do it more. As often as possible.

Consider a world where the software industry state-of-the-art is completely nascent and isolated to every owner of a computing system. You buy these huge refrigerator-sized machines and get a bunch of manuals with them but nothing else. You have no operating system. No compiler. Nothing. The expense for this project can only be funded by a large university or government. The timeline to deliver is measured in years.

In todays world? We write programs that generate new programs, that emulate entire classes of machines, and we ship software projects in days, weeks, and months.

It’s so vastly complex that it’s a wonder it works at all let alone so well.

Abstraction is what makes it all work without toppling over when someone, somewhere in the stack, makes a slight change.

Re: Abstraction is expensive

#36

Post by cloogshicer »

agentultra wrote: post #24
cloogshicer wrote: post #17

Even though many people call abstraction 'the essence of programming', it is rarely fully understood. Maybe no human on the planet really understands it. I've long had an essay in me about this topic that I really need to put to paper soon. Here is the brief version of that essay: * Programming is about building theories/models of the problem. Source code largely has no value by itself [1] * It is very difficult, if…

> it is rarely fully understood I beg to differ. Case in point: type classes, the Monoid type class, and Monoids as the mathematical concept; all well understood, proofs of their existence and properties are stated exactly, and when implemented by a compiler behaves exactly as expected when the program is executed. This is precisely what people mean when they say "abstraction is the essence of progamming"... ... when…

I'm one of those programmers you mentioned. Could you help me? I'm genuinely trying to learn more about this. What is the precise mathematical definition of the term abstraction?

Any links to good resources are appreciated.

Re: Abstraction is expensive

#37

Post by uvdn7 »

And no abstraction is perfect, as by definition an abstraction hides some details from the layer beneath. A good abstraction is one that allows you to not look under the hood most of the time. One can be happily writing code in their favorite programming language until you want better performance and started looking into cpu caches, branch prediction, etc. which are "breaks" the nice abstractions provided by the OS and high level programming languages.

Re: Abstraction is expensive

#38

Post by gavinray »

ScyllaDB is, ironically, maybe one of the worst examples the author could have come up with for "abstraction" in the article.

If folks aren't familiar with their work/internal tech, go check out some of their repos like Seastar. They have some of the most talented systems programmers on the planet writing thin veneers over kernel and hardware API's to squeeze every ounce out of performance.

https://github.com/scylladb/seastar

You want to talk about getting nerd-sniped to work somewhere if you're into performance/low-latency systems and databases =P

I know it's beside the point, but I just had to share because I thought that was funny

Re: Abstraction is expensive

#40

Post by vlovich123 »

photochemsyn wrote: post #22

One takeaway for dealing with what the author calls misalignment seems to be that abstractions should be reversible, that is, easily rolled back to the base layer, without disrupting other parts of the system. This facilitates swapping out one abstraction for another. Another way of putting it is that if you lay out all the dependencies in a system, it should look more like a tree than a graph, with the abstractions…

Path dependency makes that often difficult / impractical.
Post reply on HN