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

51–60 of 144 posts

Re: Abstraction is expensive

#51

Post by fdgsdfogijq »

BlargMcLarg wrote: post #49
fdgsdfogijq wrote: post #46

I think its a meme now to hate abstraction. In big tech I see it as a justification to build parallel systems that do almost the same thing. Abstraction done well is where technical leverage comes from. Abstraction done poorly is where technical debt/bad technology comes from. Management prefers the safe route of gating their engineers from abstraction to get the work done with certainty, the trade off being less tec…

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

Re: Abstraction is expensive

#52

Post by taeric »

ghaff wrote: post #8
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…

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.

I think arguing that assembly is an abstraction is going the wrong direction on why it is hard. Assembly largely forces numerical abstraction on your problem. Which is a lot harder to reason about than folks want to acknowledge.

That is, higher level languages let you get farther away from the abstraction that is the computer itself. As such, you can have a less abstract program in a language that has higher abstraction away from the execution environment.

Re: Abstraction is expensive

#53

Post by chacham15 »

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.

It is true. Abstraction means that you dont have to worry about some lower level concerns. With computers, the rabbit hole goes quite deep.

High-level language (C/python) Assembly language (att/intel) Byte code Micro code

So, with assembly code, you dont care about what the actual bytes that get generated are (they can change and you'd never know if the system was backwards compatible). Similarly, if the microcode that the CPU generates to implement the instruction changes youd also never know.

Re: Abstraction is expensive

#54

Post by taeric »

chousuke wrote: post #45

I like abstractions when they are transparent enough that it's easy to tell how it could be implemented one layer down. There might be many implementation details that you hide under the abstraction, but if the interface is so abstract that I can't envision a straightforward implementation of it just based on the interface, there's probably something wrong with the abstraction. Additionally, if the behaviour of the i…

Similar to liking them for being easy to see what they mean one layer down, it is also nice to know what they mean one layer up. Your program has to inhabit a middle layer between what it is you want, and how it is that it will be executed.

Sometimes, we can get lucky and a declarative statement of what we want works. Often, that isn't the case.

Re: Abstraction is expensive

#55

Post by BlargMcLarg »

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 don't think intelligence or lack thereof is the problem. Rather, it seems people are paralyzing themselves by enjoying the endless discussions, stakeholder indecision, or boredom. All leading to these grotesque things which lack words in the right places, but have plenty in the wrong places.

The average web dev CRUD job isn't interesting enough to warrant that much intelligence.

Re: Abstraction is expensive

#56

Post by gpspake »

Abstractions are inevitable in software so the important thing is to think about, recognize, identify, and manage them. Sometimes it's appropriate to "unroll" bad abstractions in a codebase.

quotes I live by (Mostly accurate from my memory):

Repeated code is better than the wrong abstraction - Sandi Metz. Always know what the abstraction is, its value, and its cost - Kent Dodds.

Re: Abstraction is expensive

#58

Post by eterm »

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.

If you're not manually setting voltages on different pins then at some level it's an abstraction.

Re: Abstraction is expensive

#60

Post by agentultra »

cwzwarich wrote: post #32
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…

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.

Without abstraction it would be difficult to write a proof that your implementation of the monoid laws stay within specified bounds.

It's not "leaky" if the specification doesn't say anything about the space bounds. That's a separate concern from "abstraction" itself.

Update The idea of a monoid is divested of any real-world implementation and that's what makes it useful (and consequently also hard to explain). The important thing is that there are laws to how the operations on monoids compose and relate to one another that must be maintained no matter how they're implemented in an actual computer.

Post reply on HN