That's not an abstraction, that's a layer of indirection • Hacker News Board

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

#131

Post by Darmani » Sat, Dec 28, 2024, 1:30 PM UTC

blue_pants wrote: post #85

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…

Very interesting indeed. +1 for more explanations For example, in the "TV -> serial number" abstraction, if I were to define only one operation (checking whether two TV's are the same), would it make it a good abstraction, as now it is both sound and precise? And what are the practical benefits of using this definition of abstraction? Even if I were to accept this definition, my colleagues might not necessarily do th…

> if I were to define only one operation (checking whether two TV's are the same), would it make it a good abstraction, as now it is both sound and precise?

It would!

> And what are the practical benefits of using this definition of abstraction?

Uhhh...that it's actually a coherent definition, and it's hard to think or speak clearly without coherent definitions?

If you're talking about using it in communication, then yeah, if you can't educate your coworkers, you have to find a common language. They should understand all the words for things that aren't abstraction except maybe "concept," and when they use the word "abstraction," you'll have to deduce or ask which of the many things they may be referring to.

If you're talking about using it for programming: you kinda can't not use it. It is impossible to reason or write about code without employing abstraction somewhere. What you can do is get better about finding good abstractions, and more consistent about making behavior well defined on abstract states. If you're able to write in a comment "If this function returns success, then a table has been reserved for the requesting user in the requested time slot," and the data structures do not organize the information in that way, and yet you can comment this and other functions in terms of those concepts and have them behave predictably, then you are programming with true abstraction.

In this case, not programming with true abstraction would mean one of two things:

1. You instead write "If this function returns success, then a new entry has been created in the RESERVATIONS table that....", or

2. You have another function that says "Precondition: A table has been reserved for the user in this timeslot," and yet it doesn't work in all cases where the first function returns success

I think it's pretty clear that both ways to not use true abstraction make for a sadder programming life.

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

#132

Post by Darmani » Sat, Dec 28, 2024, 1:36 PM UTC

cloogshicer wrote: post #68

Darmani wrote: post #32

TCP is great. Long chains of one-line functions that just permute the arguments really suck. These both get called abstraction, and yet they're quite different. But then you hear people describe abstraction ahem abstractly. "Abstraction lets you think at a higher level," "abstraction hides implementation detail," and it's clear that neither of those things are really abstractions. As the OP mentions, we have a great…

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 examples of true abstraction — written in English, rather than code, in accordance with the above. It's normally reserved for our paying students, but, if you E-mail me, I'll send it to you anyway — my contact information easy to find.

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

#133

Post by mitch-crn » Sat, Dec 28, 2024, 1:41 PM UTC

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. -Doug McIlroy

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

#134

Post by II2II » Sat, Dec 28, 2024, 1:56 PM UTC

0x696C6961 wrote: post #122

mattmanser wrote: post #104

Earlier quoted context omitted.

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

The rule of three should obviously not be applied to well known data structures and algorithms ...

Well known data structures and algorithms are well know because they have been used more than three times. That said: if you are dealing with a situation where you have to implement them yourself, you may want to consider whether the rule of three applies. (Clearly this depends upon the situation.)

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

#135

Post by mightyham » Sat, Dec 28, 2024, 2:01 PM UTC

oftenwrong wrote: post #51

mightyham wrote: post #6

I forget which programming talk I watched which pointed this out, but one extremely common example of this in Java is recreating subsets of the Collections API. I've done this before, heck even the Java standard library is guilty of this problem. When a class has a full set of get/put/has/remove methods, it is often not actually hiding the complexity of its component data structures.

Rich Hickey on HttpServletRequest? https://www.youtube.com/watch?v=aSEQfqNYNAc

Yup that's the one. Thanks for linking it.

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

#136

Post by malfist » Sat, Dec 28, 2024, 2:12 PM UTC

chthonicdaemon wrote: post #125

mattmanser wrote: post #104

Earlier quoted context omitted.

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

Tell that to Richard Hamming: "Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class." [1] I have seen this "premature abstraction" warning creep through our discourse lately, but I don't clearly understand it. I feel like I'm making calls all the time about when to introduce functions or classes that will save you time or…

To your point, we use abstractions all the damn time. They're everywhere. Even programming languages are an abstraction (especially high level ones). You and I, and everybody else here doesn't pick a cylinder and a block to write to and tell the hard drive to move it's arm into place and record the magnetic data, no we all talk about inserting a row into the DB.

Abstractions are essential to productivity or you'll never get out of the "make it from scratch" trap

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

#137

Post by fnqi8ckfek » Sat, Dec 28, 2024, 2:13 PM UTC

zelphirkalt wrote: post #98

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…

Although of course solving the abstract problem does not have to be 10 times as much code. The best solutions are often those, that recognize the more general problem, solve it with little and elegant code, then turn to the specific problem, expressing it in terms of the abstract problem and thereby solving it in just a few lines of code. Such an approach should usually be accompanied by some documentation. To give a…

[dead]

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

#138

Post by coliveira » Sat, Dec 28, 2024, 2:18 PM UTC

chthonicdaemon wrote: post #125

mattmanser wrote: post #104

Earlier quoted context omitted.

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

Tell that to Richard Hamming: "Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class." [1] I have seen this "premature abstraction" warning creep through our discourse lately, but I don't clearly understand it. I feel like I'm making calls all the time about when to introduce functions or classes that will save you time or…

> Solving the general problem is often easier than solving a specific case and can be re-used for later instances, too.

You and the other person are both correct. What you're saying makes sense and it is what everybody is trained to do. However, it leads to a lot of useless code exactly because you're applying an abstraction that is used only once. That's why most codebases are bloated and have a huge number of dependencies.

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

#139

Post by laserlight » Sat, Dec 28, 2024, 2:27 PM UTC

xtracto wrote: post #119

mattmanser wrote: post #104

Earlier quoted context omitted.

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

I am wondering where the "generalize code after doing it for the 3rd time" rule of thumb comes from? I also subscribe to it, and read it somewhere 15/20 years ago. Was it the Mythical Man Month book Maybe?

See the C2 Wiki article: https://wiki.c2.com/?ThreeStrikesAndYouRefactor

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

#140

Post by alexvitkov » Sat, Dec 28, 2024, 2:29 PM UTC

While I wholeheartedly agree with the premise, the article doesn't really say anything other than "TCP good, your abstraction bad, don't use abstraction".