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

91–100 of 144 posts

Re: Abstraction is expensive

#91

Post by kenjackson »

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…

Right. Abstraction has cost. It may or may not be expensive. Know the cost and then decide if it's worth the cost.

Re: Abstraction is expensive

#92

Post by danShumway »

danielmarkbruce wrote: post #84
danShumway wrote: post #82

Earlier quoted context omitted.

I would argue that abstractions are usually expensive. It's just that sometimes not doing something expensive is also expensive. Getting your car regularly maintained is expensive, so is not doing that. The issue with abstractions is that people have not internalized them as "an expensive thing we do to prevent ourselves from running into expensive problems later"; they're internalized them as a zero/low-cost process…

Sure, the statement isn't wrong. But the content is mostly about making good/consistent choices given the situation.

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

Re: Abstraction is expensive

#93

Post by unwind »

pclmulqdq wrote: post #69
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.

This is true. Ignoring the labels, macros, and directives, there are many ways in machine code to encode most common x86 instructions (zeroing a register even has many possible assembly instructions!). Assemblers pick the best encoding.

Is that true? They swap actual instruction mnemonics as written in the assembly source into different instructions, for performance? I hope that is controlled by some flag or something, seems like a strange thing for an assembler to be doing unless asked.

I seem to remember the venerable combined assembler/monitor/editor ASM-One [1] on the Amiga having a mode to do that, an "optimizing assembler", but I think it mainly worked with instruction and data sizes, i.e. optimizing short jumps into branches which were cheaper on the 68k.

[1]: https://en.wikipedia.org/wiki/ASM-One_Macro_Assembler

Re: Abstraction is expensive

#94

Post by littlestymaar »

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.

> 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 fact more leaky than most people assume.

Re: Abstraction is expensive

#95

Post by fdgsdfogijq »

adamrezich wrote: post #88
fdgsdfogijq wrote: post #86

Earlier quoted context omitted.

complex != overengineered and/or overgeneralized one some technical problems are actually just complex

sure, but it's easier to solve a complex problem by building an abstraction that is more complex than the problem requires, that to build an abstraction that is as simple as possible (given the complexity inherent to the problem). then, once you have your too-complex abstraction, it can be difficult to restrain yourself, especially as an eager junior developer, to not take your amazing feat of abstraction engineering…

right, but my point is thats what we call a bad software developer. and most software developers are warned, because real abstraction is beyond their capability. a world class software engineer knows that maxim, but also is capable of building an abstraction that lasts.

Re: Abstraction is expensive

#96

Post by danielmarkbruce »

danShumway wrote: post #92
danielmarkbruce wrote: post #84

Earlier quoted context omitted.

Sure, the statement isn't wrong. But the content is mostly about making good/consistent choices given the situation.

> 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 expensive", even though the reason they wrote the article is because cars are expensive and hence the choice is important.

Re: Abstraction is expensive

#97

Post by ChicagoDave »

Abstractions are at their worst when they cross bound contexts. A customer in a billing system is not the same as a customer in a sales pipeline system. By merging disparate purposes for seemingly technical benefit, we often create complexity where none need exist.

Domain Driven Design helps wall off inappropriate and costly abstractions.

Re: Abstraction is expensive

#98

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.

"abstraction in expensive" makes people think you are implying one shouldn't use abstraction. It's all well and good that the content doesn't say that, but as journalists say: "don't bury the lede".

Re: Abstraction is expensive

#99

Post by pclmulqdq »

unwind wrote: post #93
pclmulqdq wrote: post #69

Earlier quoted context omitted.

This is true. Ignoring the labels, macros, and directives, there are many ways in machine code to encode most common x86 instructions (zeroing a register even has many possible assembly instructions!). Assemblers pick the best encoding.

Is that true? They swap actual instruction mnemonics as written in the assembly source into different instructions, for performance? I hope that is controlled by some flag or something, seems like a strange thing for an assembler to be doing unless asked. I seem to remember the venerable combined assembler/monitor/editor ASM-One [1] on the Amiga having a mode to do that, an "optimizing assembler", but I think it main…

I believe that there are some assemblers that will swap "mov rax, 0" for "xor eax, eax" (which is smaller and faster), if you let them, but not all of them. Some instructions like "jmp LABEL" correspond to many different options (short relative jumps, long relative jumps, absolute jumps, etc.) and the assembler picks the best one.

As another example, almost all of the vector instructions have an encoding with a VEX prefix (an AVX encoding) as well as the older SSE encoding. If you mix the VEX and SSE encoded instructions, there can be a big slowdown, so an assembler will give you VEX encodings if you have AVX-only instructions in the stream, and default to SSE encodings if you don't (they are often smaller).

Some instructions, like LEAs and ADDs, have several different encoding options corresponding to different operand orderings, and an assembler will pick the best one - some of these encodings will force an extra SIB byte when you use R12 as an operand, for example.

This is kind of assembler-specific in terms of how smart it is. I'm not sure that the dumber assemblers do this for you.

Re: Abstraction is expensive

#100

Post by kenjackson »

1vuio0pswjnm7 wrote: post #81
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." What about writing something small.

And then using that small thing as a subroutine that you can call into to repeat that same functionality...
Post reply on HN