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

71–80 of 144 posts

Re: Abstraction is expensive

#71

Post by bbkane »

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

I'm certainly not. I try to compensate when I can by aggressively rewriting until an abstraction stops breaking things and feels natural

Re: Abstraction is expensive

#72

Post by danielmarkbruce »

BurningFrog wrote: post #23

I find this seemingly trivial insight very useful: Everything has costs and benefits, and they need to be weighed against each other. If you look for it, you'll see tons of arguments like "this has costs, so it's bad" and "this had benefits, so it's good". Both are missing half of the analysis!

Absolutely. Most political "debates" suffer from this.

"Everything is a trade-off" is similar - trivial yet profound.

Re: Abstraction is expensive

#74

Post by danielmarkbruce »

pclmulqdq wrote: post #67
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…

I wrote the piece. The argument I tried to get across is: "You must use abstractions. Find the ones whose values align with your interests." I find people frequently torturing their problems into abstractions they like rather than finding abstractions that work for their applications, and this is very much wrong. Edit: By the way, the examples are fairly low-level databases because that's what I know about. If I knew…

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

Re: Abstraction is expensive

#75

Post by LAC-Tech »

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.

Re: Abstraction is expensive

#76

Post by LAC-Tech »

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…

Lack of abstraction is also expensive: try writing something large in assembly.

I can't think of a single "best practice" abstraction we have in web development are anywhere near as watertight and useful as what C offers over assembly.

React VS The DOM is more like CFront over C.

Re: Abstraction is expensive

#77

Post by LAC-Tech »

cryptonector wrote: post #9
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.

That's why real programmers write binary object code directly.

Ah yes, the All Abstractions Are Equal fallacy.

Re: Abstraction is expensive

#78

Post by a1369209993 »

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…

> 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-memory if a and b are large enough. (This debateably violates closure of `` (you could say `undefined`/`error "out of memory"`/etc is a valid element), but indirectly breaks all the other Monoid laws like `(ab)c==a(bc)`, since the result is `undefined`(/etc), rather than `True`.)

0: Actually, I'm not sure it's true even then: does Haskell actually guarantee 2s-complement truncation on overflow?

1: Give or take "How many bits does Int truncate to?".

Re: Abstraction is expensive

#79

Post by adamrezich »

vlunkr wrote: post #27
agentultra wrote: post #16

For the mathematically minded, this is not about abstractions. This is about technology choices! One more interpretation of an overloaded word that means a very specific thing.

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?

Re: Abstraction is expensive

#80

Post by btilly »

pclmulqdq wrote: post #67
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…

I wrote the piece. The argument I tried to get across is: "You must use abstractions. Find the ones whose values align with your interests." I find people frequently torturing their problems into abstractions they like rather than finding abstractions that work for their applications, and this is very much wrong. Edit: By the way, the examples are fairly low-level databases because that's what I know about. If I knew…

One point about abstractions that you might want to make in a future article is that developers tend to discount the cost of all abstractions that they have internalized. Therefore when they get to a new environment, they immediately try to recreate and incorporate the abstractions that they used previously.

However these abstractions are not free. They are not free for performance. They are not free for debugging. And they are especially not free for any future developer who is not familiar with them.

The joke I grew up with was, "Andy giveth, and Bill taketh away." It is no longer Intel under Andrew Grove who gives us better performance. It is no longer Microsoft under Bill Gates who gives us slower software. But the basic phenomena is still true. Hardware improves over time. But developers happily introduce abstractions with no awareness of the associated costs.

Post reply on HN