In most cases time and capital are more expensive and abstraction, well-used, is the cheapest technical debt.
Abstraction is expensive
21–30 of 144 posts
Re: Abstraction is expensive
#22One takeaway for dealing with what the author calls misalignment seems to be that abstractions should be reversible, that is, easily rolled back to the base layer, without disrupting other parts of the system. This facilitates swapping out one abstraction for another.
Another way of putting it is that if you lay out all the dependencies in a system, it should look more like a tree than a graph, with the abstractions closer to the leaves than to the root.
Re: Abstraction is expensive
#23I 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!
Re: Abstraction is expensive
#24Even 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 they understand what abstractions are and use a precise definition.
Unfortunately there exist many programmers in the world who do not use precise definitions and don't know how to state mathematical laws or invariant properties of relations. They too use the word "abstraction" and they often mean... whatever it is they mean. It differs from person to person and is often used when they're waving their hands and trying to make a point.
Update: The overwhelmingly vast majority of programmers don't think about integer representations and how arithmetic is implemented these days; some do and that's fine, but the software world continues to ship vastly complex programs and systems without having to care about it and everything still works. That's abstraction at work.
Re: Abstraction is expensive
#25Lack 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.
> 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.
Re: Abstraction is expensive
#26Earlier 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.
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.
Re: Abstraction is expensive
#27For 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.
Re: Abstraction is expensive
#28Earlier 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.
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.
Re: Abstraction is expensive
#29Earlier 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.
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.
Re: Abstraction is expensive
#30Earlier 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.
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.