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

101–110 of 144 posts

Re: Abstraction is expensive

#101

Post by falcolas »

Arch-TK wrote: post #43
falcolas wrote: post #34

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 -…

It's unfortunate that you have only ever experienced abstractions which grow in size over time. The best abstractions out there are ones which operate well together to solve a large set of problems in the smallest amount of complexity (local to any given abstraction) as well as the smallest amount of total complexity at any given abstraction layer, as well as the smallest amount of total solution complexity. Now yes,…

You're right, I have never seen an abstraction which hasn't grown with time. I think that's because either an abstraction project either ends, or receives constant feature requests. Kind of a grow-or-die mentality as applied to software development.

Re: Abstraction is expensive

#102

Post by danielmarkbruce »

pclmulqdq wrote: post #87
danielmarkbruce wrote: post #74

Earlier quoted context omitted.

The material is good, nice going. But the title is misleading.

Thank you. I will add that the title is intentionally provocative. However, I want to encourage developers to think of an abstraction as something you pay a significant cost for rather than something you get for free, and use that logic to make good choices. In a sense, you hire abstractions a little like you hire employees. Interview them and make sure your values match.

An aside - if you haven't read any Michael Porter, you might find it interesting.

https://iqfystage.blob.core.windows.net/files/CUE8taE5QUKZf8...

Slightly different concept, but similar ideas around consistency given a set of explicit choices/constraints.

Re: Abstraction is expensive

#103

Post by agentultra »

a1369209993 wrote: post #78
agentultra wrote: post #24

Earlier quoted context omitted.

> 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…

> Case in point: type classes, the Monoid type class, and Monoids as the mathematical concept; [...] when implemented by a compiler behaves exactly as expected when the program is executed. Not true in general. For some specific instances (such as fixed-size Int under addition or multiplication[0]), it works[1], but in the general case (eg Integer under add or mul, [Foo] under concat) `a b` can fail with out-of-memor…

Isn't this why fixed, signed integer types don't have a Monoid instance?

https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-...

For arbitrary sized `Integer` type, which is basically a libgmp arbitrary integer, we also don't have a Monoid.

Re: Abstraction is expensive

#104

Post by agentultra »

adamrezich wrote: post #79
vlunkr wrote: post #27

Earlier quoted context omitted.

Agreed, they should probably include their definition of 'abstraction' in the post.

I would've thought that everyone who has done any programming at all would be familiar with the term as used in the article—why would this not be the case?

I think that's part of the problem with the use of the word in programming circles: it means different things depending on whose talking.

Re: Abstraction is expensive

#105

Post by danShumway »

danielmarkbruce wrote: post #96
danShumway wrote: post #92

Earlier quoted context omitted.

> But the content is mostly about making good/consistent choices given the situation. That's what I'm saying though. You need to make good/consistent choices about the given situation because abstractions are expensive, not free. If they were free, we'd just throw them everywhere with no thought.

What you are saying isn't wrong, but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it". To make an analogy: people shouldn't buy a sports car if they want to take their family of 5 skiing every weekend. A person might reasonably write an article on all the factors one should consider when buying a car. They shouldn't title said article "Cars are ex…

> but when someone reads "abstraction is expensive", they immediately assume the implication "and hence you shouldn't use it".

I suppose? But if someone's attitude is that expensive things should be universally avoided, that seems like a problem that's going to need to be addressed sooner or later.

Would we be having this conversation under an article titled "abstractions have benefits"? Would we be worried that someone is going to look at that title and think, "I should use them everywhere all the time then"?

I don't know. I'm not against phrasing something in a way that minimizes confusion, but on some level I think that internalizing that programming concepts aren't binary good/bad is arguably one of the most important lessons that a programmer can learn. And I regularly see a kind of pushback to the (correct) notion that abstractions have costs that I don't see in other contexts. But that could just be, and my experiences might be different than other people's.

This is largely a subjective take by me, so I understand if people disagree with it, but the prevailing attitude I personally see in software development is one where people do not realize that there is a cost to abstractions, and in fact sometimes bristle at the idea that they do have costs. At most, I can get people to agree that 'bad' abstractions have costs, but it is much harder to get them to say, "it's possible to abstract too much, and even good and necessary abstractions are still additional code with additional costs."

So I think the notion that it is not always correct to abstract every piece of code is weirdly controversial -- and the underlying idea behind that that I think people haven't internalized is "sometimes good things have a cost, and we should talk about the costs that they have."

But again, could just be me. If a bunch of people are confused over the title, then... I mean, I can't tell people what they should and shouldn't be confused about. If it's better to communicate with them in a different way, then it is what it is. It just worries me if on a programming site so many people interpret "is expensive" as "should never be used." That's not a good programming philosophy for people to have.

Re: Abstraction is expensive

#106

Post by another_devy »

LAC-Tech wrote: post #75

I know this is about back-end, but it partly describes my issues with front end - the industry standard abstractions save you very up front development time, but they increase the project complexity massively.

I think front end is possessed with abstraction and DRY. Everything has to be a library or npm module, People keep on writing their on versions of same stuff most of the times because they didn’t liked the name of the function or order of arguments. Complexity in front end is definitely increased by obsession of abstraction while it should’ve reduced it

Re: Abstraction is expensive

#107

Post by trashtester »

littlestymaar wrote: post #94
dlivingston wrote: post #25

Earlier quoted context omitted.

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

> 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. Assembly gives you a nice sequential list of instructions, completely hiding pipelining, speculative execution, and all the magic that modern (since the 90s at least) CPU do to do the job fast. And as the Spectre family of CPU vulnerabilities, these abstractions are in fa…

And cache management, thread switching optimization/prioritization, and so on.

If a CPU were to ONLY do the instructions that were written in the assembly code, the code could be maybe 5-10 times slower when using cached memory and 100x slower if accessing RAM constantly.

And this is part of the reason why it's hard to write assembly that is faster than a well optimized C/C++ program. The C compiler "knows" (to some extent) what the machine code leads to at the hardware level, and will often create machine code that is more liklely to allow the CPU to reap all such advantages in a way many assembly programmers wouldn't know about or think of.

Re: Abstraction is expensive

#108

Post by a1369209993 »

agentultra wrote: post #103
a1369209993 wrote: post #78

Earlier quoted context omitted.

> Case in point: type classes, the Monoid type class, and Monoids as the mathematical concept; [...] when implemented by a compiler behaves exactly as expected when the program is executed. Not true in general. For some specific instances (such as fixed-size Int under addition or multiplication[0]), it works[1], but in the general case (eg Integer under add or mul, [Foo] under concat) `a b` can fail with out-of-memor…

Isn't this why fixed, signed integer types don't have a Monoid instance? https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-... For arbitrary sized `Integer` type, which is basically a libgmp arbitrary integer, we also don't have a Monoid.

> Isn't this why fixed, signed integer types don't have a Monoid instance?

No. Integers (signed or unsigned, fixed or arbitrary-precision) don't have Monoid instances since Haskell requires a single class instance per type, and it's ambigous which instance should be the "canonical" one.

The types `Num a => Sum a` and `Num a => Product a` have Monoid instances, but it's not clear whether the "canonical" instance for a given integer type should have `()` defined as `(+)` or `(*)`... or `min`, `max`, `and`, `or`, `xor`, `lcm`, `gcd`, or any of several dozen other monoidal operations.

Conversely, `[a]` doesn't really have any resonable monoidal operation other then `concat`, and most of the existing Monoid instances (most conspicuously Sum and Product above) are even more nothing-else-is-reasonable, if only because of their names.

Re: Abstraction is expensive

#109

Post by trashtester »

fdgsdfogijq wrote: post #51
BlargMcLarg wrote: post #49

Earlier quoted context omitted.

I wish it was a meme. The things people complained about decades ago are still happening today, and the practitioners are all too eager to turn a 100 line program into a 1000 line one, while taking weeks to test if it does what it should. The average loud dev is a GoF fanatic in love with inaccessible reflection. Double points if their tools are still stuck in a time where stack traces weren't extended to deal with s…

Call me blunt, but ive come to the conclusion most people arent intelligent enough to create complex abstractions

Every person have a limit on how complex abstractions they're able to properly create. Then there is another, usually lower, limit for what kind of abstraction they're able to understand well enough to make use of it.

In a lot of cases, people try to leverage abstractions above that second level (for them), in which case they're simply imitating in a cargo cult manner some abstraction that will often not work well if not properly understood.

This is where the atrocities start, imo.

And the sad part is that many of these programmers do have a fairly good understanding of the business needs of the stuff they're making, and often those things are quite simple from a technical perspective.

Programmers that might have been able to create perfectly usable apps in VB or something similar 20 years ago, are now only churning out useless garbage in some moder cloud based stack. (Or, at bes,t are using 80% of their time struggling with their tech, while with a simpler setup, they could have spend only 20% on the tech and used 80% of their attention on addressing business needs.)

Re: Abstraction is expensive

#110

Post by anfilt »

cle wrote: post #13
nine_k wrote: post #5

Lack of abstraction is also expensive: try writing something large in assembly. I'd say that lack of a language / system of notions adequate to the subject area is expensive. The desire to describe things in a way that's efficient for a particular class of problems leads to invention of various frameworks. Say, Rails makes you hugely productive at solving a particular type of problems (see [Shopify]), though it's les…

IME the best abstractions hide the underlying complexity by default, but allow you to "pop the hood" when necessary. The more this exposes the guts of the underlying implementation details, the better (though obviously that comes with tradeoffs around changing underlying impl details, although I think as an industry that we over-index on that too much, which leads to exactly this problem). Go's compiler intrinsics im…

In my opinion good abstractions layers should also have a way to peel things back like layers of onion.

Taking the authors example of a TCP network stack you often can't do though since OS won't let you have that low level of access by default without using or writing some custom driver since the OS ends up trying to isolate usee-space completely.

Kinda makes me wish more research has been done on things like exo-kernels where the OS is mainly concerned with security and not the abstraction. All the abstraction runs in user space on such a kernel and you can choose what level is suitable for what your doing. https://en.wikipedia.org/wiki/Exokernel

Post reply on HN