The most expensive abstractions are usually do to bad layering, leading to abstraction inversion. This is the phenomenon where a layer of the system ends up reimplementing the abstractions of a lower level that have been imprudently hidden by a layer in-between. This is why considering all layers together needs to be a constant consideration.
Abstraction is expensive
121–130 of 144 posts
Re: Abstraction is expensive
#122Bad title.
The article clearly says : Abstraction *misalignment* is expensive.
Re: Abstraction is expensive
#123Earlier quoted context omitted.
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”.
Re: Abstraction is expensive
#124I 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…
> Abstraction done poorly is where technical debt/bad technology comes from.
I agree, but it is not the only source of technical debt. I tried to work on a batch job that ran a company one time, it was just a top to bottom script, if-statements, loops, etc... nested 17 (!) deep in places: an if inside a for loop inside a while loop inside an if inside an if inside a while loop inside an if inside a for loop inside a while loop inside an if, etc. The guy who wrote it didn't know what a function was.
Believe me, you can have technical debt even without abstraction.
One of my frustrations is that it takes a lot of skill to rise above "big pile of if-statements" programming, and it's so easy for a good abstraction to crumble back into a "pile of if-statements" if even one developer working on it doesn't understand the abstraction.
Re: Abstraction is expensive
#125The most expensive abstractions are usually do to bad layering, leading to abstraction inversion . This is the phenomenon where a layer of the system ends up reimplementing the abstractions of a lower level that have been imprudently hidden by a layer in-between. This is why considering all layers together needs to be a constant consideration.
I hit that when working with NHibernate (an early ORM in C# that was a port of Java's Hibernate.)
I found that it was easier to write the ^%$#$^ query myself than to deal with that monster. What was crazier was that the senior members of the team were so afraid of a database that they couldn't conceive of writing a SQL query.
I got stuck on trying to store an enum as an int in a column for about 3 days. Eventually I decided to read the book; and walked away realizing that it was only really useful for extremely complicated schemas. For simple schemas the learning curve was so high that writing boring SQL code was easier / faster.
(Now, Microsoft's entity framework is often "good enough" as an ORM, and has a rather gentle learning curve. It helps that C# has a way to express SQL-like queries on a collection of objects and translate them into SQL.)
Re: Abstraction is expensive
#126no duh. now lets get back to the real world where all the "abstractions" are poor abstractions AND inefficient.
Re: Abstraction is expensive
#127Lack 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…
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.
Re: Abstraction is expensive
#128Earlier 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.
That's why real programmers write binary object code directly.
Binary is an abstraction. I tap the clock and data lines line manually with a battery. Boy are my fingers tired.
Re: Abstraction is expensive
#129No post body was provided.
Re: Abstraction is expensive
#130Earlier quoted context omitted.
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…
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. A…
You wrote: > 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.