Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

That's not an abstraction, that's a layer of indirection

fhur.me

Post reply on HN
Print view View original

161–170 of 240 posts

Re: That's not an abstraction, that's a layer of indirection

#161

Post by 9rx »

zharknado wrote: post #72
necovek wrote: post #37

Earlier quoted context omitted.

> Using an ORM allows my program to easily work against multiple sql databases. A curious example, since most developers who've worked on any project with significant amount of data in a database would likely disagree. IMO, ORMs mostly allow using programming-language-of-choice as a syntax for relational queries instead of constructing it by hand on top of serialization and deserialization of objects into rows and vi…

Yes, ORMs came to mind for me as an example of indirection without abstraction. If you accept OP’s litmus test of “how often do I have to peek under the hood” I think ORMs generally don’t score particularly well.

If enabling the ablity to think of the database as the rich native data structures provided by the host programming language, and not the tables (rows and columns) that the underlying database service wants to think of the data as is not an abstraction, what is?

Re: That's not an abstraction, that's a layer of indirection

#162

Post by sgarland »

crabmusket wrote: post #28
cpeterso wrote: post #15

Earlier quoted context omitted.

“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger Dijkstra But sometimes a new semantic level isn’t needed. Abstraction gets so much press when you might just need some good ol’ fashioned information hiding and separation of concerns.

This is such a great quote, and helps explain what is a good abstraction. Because CRDTs have been in the zeitgeist a lot lately, I want to pick them as an example of a "good" abstraction. CRDTs have mathematical properties which can be described and understood independently of a specific implementation. And importantly, you can judge whether an implementation is correct with reference to these abstract rules. This me…

CRDTs are also an excellent example because of how their supporting infrastructure is impacted by their design, namely that Postgres’ method of dealing with updates makes for massive write amplification.

I wrote this [0] previously, but it still applies. IMO, as a dev, there are times where you really do need to think somewhat deeply about infrastructure choices. Unfortunately, knowing when you need to care practically requires you to already understand it.

[0]: https://news.ycombinator.com/item?id=40834759

Re: That's not an abstraction, that's a layer of indirection

#163

Post by baobabKoodaa »

mkoubaa wrote: post #148
rauljara wrote: post #144

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance. I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I t…

The way to tell whether an abstraction is good or bad is to develop good taste. Engineers with good taste have intuition about these things. You are not going to acquire good taste from reading an article.

Maybe not, but you can still move the needle one way or another based on reading an article. For those readers who recognize themselves as erring on the side of adding too many abstractions, they might move the needle a bit towards the other side.

Re: That's not an abstraction, that's a layer of indirection

#164

Post by layer8 »

mkoubaa wrote: post #148
rauljara wrote: post #144

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance. I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I t…

The way to tell whether an abstraction is good or bad is to develop good taste. Engineers with good taste have intuition about these things. You are not going to acquire good taste from reading an article.

Relying on mere “taste” is bad engineering. Engineers do need experience to make good decisions, yes. But surely we are able to come up with objective criteria of what makes a good abstraction vs. a bad abstraction. There will be trade-offs, as depending on context, some criteria will be more important than other (opposing) criteria. These are sometimes called “forces”. Experience is what leads an engineer in assessing and weighing the different present forces in the concrete situation.

Re: That's not an abstraction, that's a layer of indirection

#165

Post by epolanski »

rauljara wrote: post #144

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance. I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I t…

I second this, such posts are very generic, they are hard to disagree with, but also to agree with empathically as there are no clear examples of what is too much.

As someone who uses lots of layers and dependency injection I would like to be poked on where is that too much abstraction but I end up being no wiser.

Re: That's not an abstraction, that's a layer of indirection

#166

Post by CalChris »

rauljara wrote: post #144

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance. I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I t…

The article did start off giving TCP as a good abstraction but then didn't follow up with examples of bad abstractions.

Dynamic typing is an example of an indirection masquerading as an abstraction. You end up carrying around an object and occasionally asking it whether it's an int64_t or a banana. You maybe think your type luggage will take you on exotic vacations when really in fact you take it on exotic vacations.

Re: That's not an abstraction, that's a layer of indirection

#167

Post by marginalia_nu »

While I think it's good the pendulum is swinging toward a more restrictive approach to abstractions, we've (and I've) certainly been leaning a bit too much toward just solving every problems by adding a layer of indirection around it, and such onion-layered designs tend to (as the metaphor implies) cause a lot of tears when you cut through them. That said, it's not like abstraction itself is bad.

A big part of the problem is arguably that IDEs make code navigation easier, which has us adding all these indirections and discover only when it's too late what a horrible maze we've built. Being more judicious about adding indirection really does help force better designs.

Re: That's not an abstraction, that's a layer of indirection

#168

Post by layer8 »

voidhorse wrote: post #43

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…

To put it in slightly simpler terms, abstractions are generally to separate the “what” from the “how”.

Functions are the fundamental mechanism for abstraction in computing, which demonstrate that very well, in their separation between interface and implementation. The function signature and associated interface contract represent the “what”, and the function’s implementation the “how”. If the effective (often non-explicit) interface contract relies on most aspects of the actual implementation, then the “what” is almost the same as the “how”, and there is little abstraction. The greater the difference between the “what” and the “how”, the more of an actual abstraction you have.

This relates to Ousterhout’s notion of “deep modules”, which are modules whose interface is much simpler than their implementation. In other words, the “what” is much simpler than the “how”, which makes for a good abstraction.

It’s true that often one has to first implement the “how”, possibly multiple times, to get a good notion of which aspects are also still important to the “what”, and which aren’t.

Note also that generalizations go two ways: The caller needs less knowledge about the implementation, but it also means that the caller can rely less on the properties of a concrete implementation. This is again well reflected in function types. A (pure) function g: A –> B is a generalization of a function f: C –> D only if A is a subtype (specialization) of C and B is a supertype (generalization) of D. Here D could expose properties of the function’s implementation (f) that g wants to hide, or abstract from.

Re: That's not an abstraction, that's a layer of indirection

#169

Post by javcasas »

bruce511 wrote: post #111
javcasas wrote: post #76

Earlier quoted context omitted.

> allows my program to easily work against multiple sql databases How many times have you required that your program runs against different sql databases without modification? I mean, how many times have you required your plane to be able to fly in the different atmospheres of different planets of the Solar System? Unless you are NASA, I suggest you cut the complexity and just make a plane that can fly well on Earth'…

>> How many times have you required that your program runs against different sql databases without modification? Our main commercial product currently supports 2 database engines, and we'll be offering a 3rd next year. For enterprise offerings it's pretty common for the client to prefer, or outright specify, the engine. Commodotizing your complementary technology is a good way to not become dependent on any specific…

Yes, yes, you are NASA.

The rest of us go with Postgres, or SQL server, or Oracle, but definitely don't have to prepare our systems to run in PostgreSQL on Mondays, on SQL server on Tuesdays and so on.

Re: That's not an abstraction, that's a layer of indirection

#170

Post by brunorb8 »

rauljara wrote: post #144

I wish articles like this had more examples in them. In between “this thin wrapper adds no value but a lot of complexity”, and “this thin wrapper clarified the interface and demonstrably saved loads of work last time requirements changed” is an awful lot of grey area and nuance. I did like the advice that if you peak under the abstraction a lot, it’s probably a bad one, tho even this I feel could use some nuance. I t…

I believe that the place to find detailed examples and deep analysis is in books, not one-off web articles.
Post reply on HN