Hacker News Reader

Comment by nine_k | Hacker News Reader

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 less than helpful if you try to apply it to unfitting problems (see [Twitter]).

[Shopify]: https://tomaszs2.medium.com/how-shopify-handled-1-27-million... (Sorry for a Medium link)

[Twitter]: https://www.theregister.com/2012/11/08/twitter_epic_traffic_...

View on HN

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 about web frameworks, I would have used those instead.

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

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 that has no downsides and thus should be pursued all the time.

It's like if people said, "not getting your oil changed will be more expensive, and therefore I get my oil changed every other week."

I kind of think that the only reason that the phrase "abstractions are expensive" sounds like a controversial take is precisely because people have not internalized that abstractions are not a binary good/bad thing and that they should be applied situationally, because they do have maintenance costs and development costs.

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.

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

You shouldn’t use any abstraction unless you have a good reason to do so.

Why? Because it has costs which are most heavily paid by those who come after you and read or modify the code later.

A small amount of the right abstraction helps understanding, too many irrelevant abstractions just gets in the way (BeanFactoryFactory etc).

I’ve only seen people use too much abstraction, not too little, so the title makes perfect sense as it is to me and has the right message IMO.

That's very well-phrased, and you beat me to this comment. :)

I wanted to get across that an abstraction is an expensive thing you should use to solve a difficult problem, not a cheap thing you use to solve a simple problem.

> abstraction is an expensive thing you should use to solve a difficult problem, not a cheap thing you use to solve a simple problem

Nailed it.

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

Nah, it’s perfect. Provocative, technically true, and when you come back to the title it’s “I have a new insight into this now”.

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.

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.

You wrote: <<They are not free for debugging.>> Thank you. Finally, someone acknowledges this important point! I have literally been told that adding extra local variables was "increasing stack size; must be slower". But what about debugging? And, yes, there is a balance to be had between maintenance and speed. Example: Breaking down a critical path section of code into a bunch of tiny non-inline functions may slow down the code unacceptably. In other cases, it may make the code much easier to read, maintain and debug... so the trade-off is acceptable.

Hard agree. On the flipside, devs also tend to overestimate the cost of already-implemented abstractions that they haven’t yet internalized, leading to complaints and lengthy refactors when they could have just spent the time to learn the abstraction…

The same can be said about organization. Too much abstraction, managers and teams, is harming performance. Too little abstraction is hard to coordinate. Putting abstraction in front of problem, throwing problem to previously arbitrarily setup team with or without the right mix of expertise for the current problem. Spinning up libraries/framework automatically when starting a new project, forming teams that worked for previous company. Abstraction that's so leaky that either require code change to the library or "octopus" code that link up functionality from 7 different other libraries, team formed without regarding a problem boundary where each problem need cross team coordination of seven department. Software engineering and organization design have very much in common

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 immediately come to mind here. They allow you to easily write Go functions in native assembly, without CGo, for hot code paths. We get the benefits of a high-level language with a fat runtime, but can easily drop down to assembly when we need to.

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

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.

Don't tell them about the lost art of loading microcode on boot.

I wire my magnetic core with artisanal copper.

You use copper? These kids today...

Relevant xkcd:

https://xkcd.com/378/

Dammit, emacs!

Ah yes, the All Abstractions Are Equal fallacy.

Binary is an abstraction. I tap the clock and data lines line manually with a battery. Boy are my fingers tired.

I pick only the best artisinal integer representations for my programs. Only fools use abstractions.

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

Nope, the CPU presents you an interface of the available instructions but those instructions are a complete fiction on modern processors and don't have to match at all what the underlying hardware does. The CPU guarantees that the observable effects of the instructions are consistent (i.e if the processor wants to do some fuckery it can't change the instruction semantics) but beyond that is free to run your code however it wants.

Simpler RISC designs, like simpler ARM cores, more or less directly execute instructions; same for old 8-bit cores you can still widely find in MCUs. Complex high-performance cores, with pipelining, instruction fusion, and OoO execution, turn instruction stream into a microcode lava.

So maybe the right thing to say is that assembly is a contract between you and the processor and the underlying implementation can map directly to hardware when appropriate but it doesn't have to. It is an abstraction over different underlying hardware implementations.

First of all, you normally use symbolic labels, not offsets for jumps; the assembler will calculate them for you, and a linker will possibly build a relocation table based on them. Then, any good assembler has macros. Also, data / text blocks, etc that are not code but an abstraction which the linker later uses.

Writing machine code directly, as a byte stream, is fun, but is exhausting.

Arguably it's more of translation layer not abstraction. You're not abstacting away any concepts or code blocks here, you still have to write every single instruction, you just get a bit of a help with math.

Assemblers like nasm have an entire macro language. Of course that isn't part of the ISA. But in the end even the ISA is fiction.

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

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.

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

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

on x86 it's a 1-to-many relationship. There are, for example, many different MOV instructions that can be encoded based on the parameters used. All assemblers I know of hide this from the user, as well as featuring labels, macros, etc. which are not defined by the hardware at all. For the most part, the x86 assembler hides the details of prefix bytes and ModR/M+SIB from the user. Some assemblers are quite advanced and if you took them just a few logical steps beyond where they are you would end up with C.

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

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.

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

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.

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.

ruby is a poor abstraction AND inefficient. text based manipulations and crap like IFS are terrible abstractions. languages like standard ML were made SPECIFICALLY for abstracting. they literally were meticulously designed to provide proper abstractions (think, for example how the elements of a union type are abstract objects, and can be built up to model coherent ideas, while in ruby any variable probably requires a lookup at runtime in ascii^Wunicode^wunicode-minus-whatever-feature-was-found-to-be-harmful-in-this-context)

what im saying is that the academic idea of abstraction is far better and less leaky than ruby (dynamic name resolution and such "scripting language" crap) or java (data structures are intended to be used once or twice per program (exaggerating) instead of fluently like you would make trees in a functional language); its just obscured but if everyone understood the motivation it would have replaced stuff like ruby in all use cases.

i see ruby and java as a little shop where the owner will let you instantiate one or two objects according to some terms, and then let you maybe make your own class, but it will essentially just be a wrapper around a few of the shop's objects. whereas in ML you can model anything from the ground up, even numbers, and it will still be nicely implemented and the abstractions will be almost perfect.

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

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

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.

Reply on news.ycombinator.com