Hey talking heads.
Abstraction is expensive
41–50 of 144 posts
Re: Abstraction is expensive
#42Earlier quoted context omitted.
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.
Re: Abstraction is expensive
#43I 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, this end goal is an idealized world, when you build on top of crusty old APIs and crusty old software you inevitably end up with crusty abstractions, especially difficult to deal with is the real world. That being said, there are plenty of examples out there where complexity at all three levels of detail that I outlined above has been painstakingly minimized. It usually takes a lot more effort to produce a simple solution to a problem than a complex one. This really requires the "alignment" the article talks about.
Speaking of "alignment", ORM is one of the best examples of complete and total misalignment. The sets-of-tuples model of relational databases and the graph-of-objects model of object oriented systems are so seriously at odds with each other that there isn't a single ORM out there which successfully fully resolves the mismatch without severe abstraction leaks. (No, the fact that you can successfully use an ORM without abstraction leaks at the cost of severe performance degradation doesn't really matter.)
On the other hand, large parts of the design of a project such as Plan 9 are extremely aligned.
Re: Abstraction is expensive
#44I think many misunderstand/misinterpret abstraction with magic. Abstraction is naming things that share common properties and structures.
Magic is expensive because it adds debts in debugging.
Non-abstraction is also expensive because it adds debts in development and refactoring.
Good abstraction pays later, it reduces debts, but you need to buy it first. It's not expensive if it's well produced and consumed.
Re: Abstraction is expensive
#45I 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 implementation conflicts with the simplified model communicated by the interface, that'll also cause issues.
Re: Abstraction is expensive
#46I 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 technical leverage. Its a corporate engineering meme to pin tech workers into being replaceable cogs pumping out low abstraction widgets
Re: Abstraction is expensive
#47Earlier quoted context omitted.
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 howe…
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.
Re: Abstraction is expensive
#48Not if ChatGPT creates it.
Re: Abstraction is expensive
#49I 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 such practices better.
And with everything being sliced into pieces: the fun has only just begun
Re: Abstraction is expensive
#50One of my favorite quotes about software engineering, sorry not sure who to attribute it to: "First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer"
Junior, mid, senior? Explains why the mid phase is brief.