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

171–180 of 240 posts

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

#171

Post by miki123211 »

CalChris wrote: post #166
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.

To me, it ties in with John Ousterhout's concept of "deep, small interfaces"

TCP is a good abstraction because it's essentially 4 operations (connect, disconnect, send, receive), but there's a lot going on inside to make these operations work. So are TLS, filesystems, optimizing compilers and JITs, modern CPUs, React (or rather the concept of "reactive UI" in general), autograd and so on.

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

#172

Post by cloogshicer »

Darmani wrote: post #132
cloogshicer wrote: post #68

Earlier quoted context omitted.

Hey Jimmy, I've read your comment and also your article in the past with great interest. This topic is absolutely fascinating to me. I just re-read your article but unfortunately I still struggle to really understand it. I believe you have a lot of experience in this, so I'd love to read a more dumbed down version of it with less math and references to PL concepts and more practical examples. Like, this piece of code…

Thanks! I'll have to muse about what the more dumbed down version would look like (as this version is already quite dumbed down compared to the primary sources). It wouldn't be quite a matter of saying "This code contains an abstraction, this other code doesn't," because (and this is quite important) abstraction is a pattern imposed on code, and not part of the code itself. We do have a document with a number of exam…

Thanks a lot for the offer, I just emailed you :)

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

#173

Post by lokar »

layer8 wrote: post #164
mkoubaa wrote: post #148

Earlier quoted context omitted.

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 assessi…

That’s seems like it should be true, and it would be great if it was.

But in my many years of experience working with Jr engineers, I have found no substitute other then practice guided by someone more Sr (who has good taste).

There are just too many different situations and edge cases. Everything is situational. You can come up with lists of factors to consider (better versions of this post often have them), but no real firm rules.

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

#174

Post by lebuffon »

Sesse__ wrote: post #142
astrobe_ wrote: post #79

Earlier quoted context omitted.

Yes, abstraction and generalization are properties you'd rather look for the second time around . Someone was already warning about this 25 years ago [1]: You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the…

Have you ever looked at how useless Chuck Moore's stuff is? Like, the chip designs are of the type “384 independent Forth chips with tiny amounts of RAM and mediocre interconnects, and if you want to actually do anything with them, you'll need to use 128 of them to program your own DDR3 controller”. Or, he demonstrates how awesome Forth is by showing that you can do “the guts of a disk driver” in five lines, except t…

IMHO that is a failed example of "Chuck Moore's stuff". He went down a rabbit hole to an extreme level because that's what he does. His earlier CPU experiments like the 4016 and Shboom were excellent examples of ultra-RISC architectures.

The thing Chuck explored, related to abstraction, which I don't see much in conventional machines was reducing calling overhead. (1 cycle call and intrinsic return on many instructions ie: free return)

Some of the decisions we make today have a lot to do with what happens at the hardware level when we add abstraction. It just costs more than we are prepared to pay so it is avoided ... but for the wrong reason.

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

#175

Post by JadeNB »

astrobe_ wrote: post #82
29athrowaway wrote: post #52

Earlier quoted context omitted.

Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.

You are confusing too many things. "10" is the representation of a data; "0xA" is another representation of the same data. Not being able to touch something doesn't make it an abstraction. Light is not an abstraction, a contract is not an abstraction. 10 is not an abstraction, it is an ordinal [1]. "Isomorphism" is an abstraction. It doesn't name a particular data or value, but a class of functions that share common…

> Light is not an abstraction, a contract is not an abstraction. 10 is not an abstraction, it is an ordinal [1].

It seems to me that all of those things very much are abstractions. They are not the utmost level of abstraction, but they are abstractions!

(Actually "a contract," which at first I thought was the clearest win, I'm now not sure about. On reflection, it seems like a concretization, turning abstract ideas of trust and reliability into concrete conditions under which the contract has or has not been met.)

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

#176

Post by layer8 »

lokar wrote: post #173
layer8 wrote: post #164

Earlier quoted context omitted.

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 assessi…

That’s seems like it should be true, and it would be great if it was. But in my many years of experience working with Jr engineers, I have found no substitute other then practice guided by someone more Sr (who has good taste). There are just too many different situations and edge cases. Everything is situational. You can come up with lists of factors to consider (better versions of this post often have them), but no…

I wouldn’t call that “taste”. It’s not a matter of taste which solution is better. If different engineers disagree about which solution to choose, then it’s fundamentally a different assessment of the relevant factors, and not about taste. Or at least, it shouldn’t be the latter.

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

#177

Post by lokar »

layer8 wrote: post #176
lokar wrote: post #173

Earlier quoted context omitted.

That’s seems like it should be true, and it would be great if it was. But in my many years of experience working with Jr engineers, I have found no substitute other then practice guided by someone more Sr (who has good taste). There are just too many different situations and edge cases. Everything is situational. You can come up with lists of factors to consider (better versions of this post often have them), but no…

I wouldn’t call that “taste”. It’s not a matter of taste which solution is better. If different engineers disagree about which solution to choose, then it’s fundamentally a different assessment of the relevant factors, and not about taste. Or at least, it shouldn’t be the latter.

Perhaps there is a better word. But there is a real skill that you pretty much have to learn through experience and mentorship.

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

#178

Post by marcosdumay »

layer8 wrote: post #164
mkoubaa wrote: post #148

Earlier quoted context omitted.

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 assessi…

No kind of engineering ever gets into that "taste-independent" level of formalization.

Yes, it should be this way. But it's not.

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

#179

Post by layer8 »

lokar wrote: post #177
layer8 wrote: post #176

Earlier quoted context omitted.

I wouldn’t call that “taste”. It’s not a matter of taste which solution is better. If different engineers disagree about which solution to choose, then it’s fundamentally a different assessment of the relevant factors, and not about taste. Or at least, it shouldn’t be the latter.

Perhaps there is a better word. But there is a real skill that you pretty much have to learn through experience and mentorship.

Yes, this is what I mentioned in my original comment about experience being needed to weigh the trade-offs. That doesn’t mean that we can’t very concretely speak about the objective factors in play for any given decision. We can objectively say that x, y, z are good about this abstraction and a, b, c are bad, and then discuss which might outweigh the other in the specific context.

Needing experience to regularly make good decisions doesn’t mean that an article explaining the important factors in deciding about an abstraction is useless.

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

#180

Post by vacuity »

noduerme wrote: post #112
ramblerman wrote: post #107

Earlier quoted context omitted.

> Don't marry your display code to your business logic. > It's the reason I never went for JSX or other frameworks that put logical code into templates or things like that That's not mixing business logic with display code, your confusing (or conflating) 2 entirely different things here.

I don't think I'm conflating things. Any time you insert sugar into your HTML that makes your end user see output that's been inserted by how your framework interprets that sugar, you may be binding your business logic to your display code. Possibly in subtle ways you don't realize until later. A common case is rounding decimals to a user that aren't rounded in the system. Letting any control flow into your HTMX/JSX…

As someone who has little experience in this topic but has come to a similar conclusion, I think the main downside of this strict separation you're recommending is performance/efficiency. Have you noticed that to be a problem in practice? It's not always clear whether the simplest solution can actually be feasible, or perhaps that is just a reflection of still untapped understanding of the problem domain.
Post reply on HN