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

121–130 of 240 posts

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

#121

Post by scotty79 »

mrcsd wrote: post #114
scotty79 wrote: post #108

Earlier quoted context omitted.

Not really. Usually during the deduction you have some steps that pull surprising knowledge from the rest of math to support the reasoning or create and prove interesting lemmas. If you can prove a theorem without any of that, that's a little boring theorem to prove.

I agree with the spirit of your comment, but not the literal fact of it. Sure, interesting proofs require pulling out some interesting knowledge in the reasoning, but notions like "surprising" or "interesting" are about human subjectivity and don't really exist as a property of a deduction. Surprising or interesting knowledge is not somehow new knowledge that wasn't there before, it's just that we didn't see it previ…

Sure, but it's humans that do the deduction. So "surprising" and "interesting" still matters. Especially when you are treating deduction as a parallel to a piece of prose that one might reasonably hope to be surprising and interesting not just repeated rephrasing of main thesis.

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

#122

Post by 0x696C6961 »

mattmanser wrote: post #104
zelphirkalt wrote: post #98

Earlier quoted context omitted.

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…

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 ...

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

#124

Post by moomin »

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…

Generalisation is definitely a good approach, but it’s not the only one. Another is “conceptualisation” or reducing repetition: if you find that large numbers of functions are taking the same three parameters, especially if they’re using them in similar ways, that’s a good sign there’s a concept you can introduce that makes those observations explicit.

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

#125

Post by chthonicdaemon »

mattmanser wrote: post #104
zelphirkalt wrote: post #98

Earlier quoted context omitted.

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…

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 effort in the future without forcing yourself to see the repetition before you do. Not only that but Hamming's advice has rung true in my career. Solving the general problem is often easier than solving a specific case and can be re-used for later instances, too.

[1] https://jamesclear.com/great-speeches/you-and-your-research-...

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

#126

Post by nyrikki »

mattmanser wrote: post #104
zelphirkalt wrote: post #98

Earlier quoted context omitted.

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…

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.

Protecting yourself from technologies, vendors, etc... are all very very worth making abstractions for.

The silly "only after # Times" type rules stolen from the DRY for DRY reasons is part of the problem and far from the solution.

"Abstraction" could be anything from keeping code in different but adjacent files to an entire anti-corruption layer etc....

The costs are different, as are the benefits.

It is horses for courses, not 'one rule that the government doesn't want you to know about'

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

#128

Post by voiceofunreason »

zdragnar wrote: post #45
danparsonson wrote: post #2

Perhaps this is a minor nitpick, but > Abstractions are also the enemy of simplicity. Each new abstraction is supposed to make things simpler—that’s the promise, right? Not exactly, no. The purpose of abstraction is to hide implementation detail, and thereby insulate one part of the codebase/application/system from variations in another. Graphics APIs for example - yes your code may be simpler for not having to deal…

> The purpose of abstraction is to hide implementation detail Technically, that's encapsulation, though the sentiment is close, I think. I rather view it as a matter of semantics. At one low level, you have operations that deal with some concrete interface or API, etc. You bundle those operations up behind an abstraction, providing methods whose names involve your application domain. Perhaps they are still at a techn…

Berard 1993 offers a good survey of the meanings of Abstrasction, Encapsulation, and Information Hiding

https://web.archive.org/web/20071214085409/http://www.itmweb...

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

#129

Post by Gehinnn »

A good abstraction shouldn't make its usage shorter, it should make the proof that the usage is correct shorter.

This usually means the total amount of assumptions needed to prove everything correct is decreased. (when the code is not actually formally verified, think of "proof length" as mental capacity needed to check that some unit of code behaves as intended)

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

#130

Post by jcelerier »

mattmanser wrote: post #104
zelphirkalt wrote: post #98

Earlier quoted context omitted.

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…

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.

At no point in my life my code has been made worse because I've used an existing sort function instead of writing a buggy one
Post reply on HN