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

The Cost of Abstraction (2016)

250bpm.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: The Cost of Abstraction (2016)

#51

Post by afarrell »

coldtea wrote: post #40
afarrell wrote: post #39

Earlier quoted context omitted.

I think its better to give feedback explicitly rather than sneering. The latter just feels bad to read (even as a third party) but doesn't really espouse some better active social norms to follow. > to add a cost (the possibility of being dismissed/sneered back) to such dismissals. Given the fact that this is a conversation among strangers, I would assert that it isn't really that effective to just add costs by makin…

> I think its better to give feedback explicitly rather than sneering. The latter just feels bad to read (even as a third party) but doesn't really espouse some better active social norms to follow. I guess so. Sometimes I'm just pissed from the easy dismissal, as in "This 5 second basic retort is all you've came up with, and you think you've taken down TFA?".

It's not an unreasonable thing to get ticked-off by

Re: The Cost of Abstraction (2016)

#52

Post by dang »

coldtea wrote: post #22
JoeSmithson wrote: post #12

Earlier quoted context omitted.

Your comment reads just as well without the condescending "It's almost like" at the beginning

Yeah, but the condescension was put in to counter-balance the parent's facile dismissal of the author/TFA. In other words, to add a cost (the possibility of being dismissed/sneered back) to such dismissals.

But please don't. Doing that adds a cost to the community, by toxifying it. Because of that, your pro-community intention is not only not fulfilled, it's actively damaged.

I find facile dismissals irritating as well, and lord knows this site gets a lot of them. But the way to push back is with a clear, positive defense of whatever was unfairly dismissed. Venting doesn't help; it only invites more venting.

Re: The Cost of Abstraction (2016)

#53

Post by karmakaze »

There's a difference between deduplication/extraction and abstraction which often seems to get lost. Abstraction is not about the mechanical reorganization of code. It is the structuring the code to follow a natural/logical abstraction that exists outside of the code. The first clue is the name of the abstraction. If it describes how the 'abstraction' works or what is going on inside it, then it's best to leave it. An abstraction should be able to opaquely represent what it is. This is the value of abstractions, it let's you not think about what's inside while working at a higher level.

A similar issue I have is with people constantly 'refactoring'. I choose to say I'm 'factoring' code instead. If you can't name the factors that you're separating then it's likely you'll change your mind an end up 'refactoring' it. Sometimes you take factored code and factor it further, which I don't have a different name for, just more factoring.

Re: The Cost of Abstraction (2016)

#54

Post by Tarean »

hu3 wrote: post #5

I've seen excessive abstraction kill projects time and time again. The crime scene is similar in every case: - What if we ever need to change database server or driver? Proceeds to write a layer to abstract data access - We might have different login forms one day? LoginFormFactory it is - This code hits our KV Redis/memcache/NoSQL by calling the driver lib directly? Can't have that, I'll write a CacheStorage or Docu…

I don't see the issue with an interfave between the app and the database. As long as the interface is getUserById and not compileSQLQuery.

Re: The Cost of Abstraction (2016)

#55

Post by Tarean »

ken wrote: post #46
hu3 wrote: post #5

I've seen excessive abstraction kill projects time and time again. The crime scene is similar in every case: - What if we ever need to change database server or driver? Proceeds to write a layer to abstract data access - We might have different login forms one day? LoginFormFactory it is - This code hits our KV Redis/memcache/NoSQL by calling the driver lib directly? Can't have that, I'll write a CacheStorage or Docu…

I confess I've never seen that happen, but I do think excessive abstraction is killing the argument this article is trying to make. When would anyone ever make an inc_pair function? Or a hierarchy of 'animals that lay eggs'? I guess these are supposed to be examples of something, but I'm not sure what. I wouldn't even call them "abstraction". They seem like completely hypothetical examples of how to apply programming…

On the other hand, the lens library in haskell is extremely abstract. Libraries obviously have different tradeoffs but using lens can increase the onboarding cost significantly for new team members.

I am mentioning lens because it has a both function:

    incBoth = both += 1
Which has a fun type signature:

    incBoth :: (Bitraversal p, MonadState (p a a) m,  Num a) => m ()

Re: The Cost of Abstraction (2016)

#56

Post by hyperpallium »

Abstraction should be based on whether the abstraction makes it easier or harder to reason about: to see, to predict consequences of decisions, to diagnose causes of behaviour.

Usually, the established abstractions of the domain are an excellent guide. Even if you think they are sub-optimal objectively, they are easier to reason about for experts in that field.

I like the article's language of comtaining the "damage" code can do. A C-style modularizarion technique I haven't seen used is long functions, with sections' variables' visibility limited by braces.

Re: The Cost of Abstraction (2016)

#57

Post by [deleted] »

drawkbox wrote: post #41
z3t4 wrote: post #34

Earlier quoted context omitted.

Even if you have wrapped it you still have to update your code when there are breaking changes. If you follow "don't repeat yourself" (DRY) there will not really be more work updating, compared to if you had wrapped it. (You should however not follow DRY slavishly - but that is a discussion on it's own.)

If the wrapper/library is generic enough then it can be less work across projects and codebase and won't need to change with an actively updated library that is wrapped. If the abstraction wrapper is tightly coupled, uses third party library types that can change or leaky then yeah, the effort is moot and you end up with more work. Another case is where you have some sort of messaging system where you want responses/…

[deleted]

Re: The Cost of Abstraction (2016)

#58

Post by Nursie »

mntmoss wrote: post #49
Nursie wrote: post #13

Earlier quoted context omitted.

> Which is not to say that we shouldn't wrap dependencies. We absolutely should. Why? If I'm writing something for a known environment that's unlikely to change, it seems like a waste of time.

There's case for having a "convenience" or "easy mode" wrapper where the amount of configuration is lower, hence the underlying dependency is more straightforward to reuse. For example, I would point to 3D graphics APIs as a reasonable case for this. All the ones in use today assume a lot of low-level detail about buffers and pointers and strides and attribute flags, which makes building up test cases challenging: yo…

I wouldn't necessarily consider that a wrapper, personally, but a reasonable set of functionality behind an interface to said functionality. The only thing I'm really arguing with is the insistence that one should wrap everything as a matter of course.

Reduction of complexity, like your example, is great. Increasing levels of indirection thoughtlessly is adding to it, IMHO.

Re: The Cost of Abstraction (2016)

#59

Post by Nursie »

jstimpfle wrote: post #50
Nursie wrote: post #48

Earlier quoted context omitted.

I think this is nonsense and leads to enterprise-y type patterns and hard to understand code. Wrapping things for the sake of it is a recipe for unnecessary verbosity and a hard to learn codebase as things are obfuscated and take longer to trace through. In C, your point 1 makes me think your code is unsafe, if you're having trouble keeping track of types and signedness. Point 2 is fair enough, but I think a lot of C…

Hmm, I think I should put that in context. I'm not saying write a wrapper for the sake of it. I don't wrap everything in three layers of OO giftwrap. I'm saying one should follow basic rules of hygiene. For example, I have a FreeType backend in my code, and I have a single file which implements a font interface (open font file, choose font size, draw to texture in the format of my app) by interfacing with Freetype. I…

> How would you know?

You have a target system, and no current plans to change it. You can't predict every change that might happen down, and neither should you try - you'll waste a ton of engineering effort and if there is change, it's almost always change in ways you didn't anticipate.

Re: The Cost of Abstraction (2016)

#60

Post by jstimpfle »

Nursie wrote: post #59
jstimpfle wrote: post #50

Earlier quoted context omitted.

Hmm, I think I should put that in context. I'm not saying write a wrapper for the sake of it. I don't wrap everything in three layers of OO giftwrap. I'm saying one should follow basic rules of hygiene. For example, I have a FreeType backend in my code, and I have a single file which implements a font interface (open font file, choose font size, draw to texture in the format of my app) by interfacing with Freetype. I…

> How would you know? You have a target system, and no current plans to change it. You can't predict every change that might happen down, and neither should you try - you'll waste a ton of engineering effort and if there is change, it's almost always change in ways you didn't anticipate.

I absolutely agree with your statement, but I don't think it applies in this situation. I'm not trying to predict future changes. It's the opposite. I'm codifying the current state. I make sure that there are no misconceptions about the extent to which the library is used.
Post reply on HN