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

31–40 of 65 posts

Re: The Cost of Abstraction (2016)

#31

Post by c22 »

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.

This whole pointless sub-discussion has had a small cost for me because for some reason I bothered reading it. A simple downvote of the original comment could have provided feedback to the author while sparing the rest of us.

Re: The Cost of Abstraction (2016)

#32

Post by Pxtl »

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…

To me the value of abstractjng out those services is testability - if they're abstracted, they can be mocked. The smaller the abstraction, the smaller the surface area you have to mock.

Re: The Cost of Abstraction (2016)

#33

Post by z3t4 »

jstimpfle wrote: post #28
z3t4 wrote: post #17

Earlier quoted context omitted.

Dependencies should be treated like if it was your own code. After you have replaced some API for the third time you can start thinking about wrapping it.

> Dependencies should be treated like if it was your own code Only a Node.js developer could say that. Maybe it's true when the dependency is left-pad or something. Experienced developers in other languages will acknowledge that (non-trivial) code that is not your own code, is not your own code. You seldom have a very good understanding of the underlying models, and the library has absolutely no understanding of your…

If you find an issue in a dependency it's better to fix the dependency, assuming it's open source, rather then wrapping it. Then everyone using it will profit, and don't have to write wrappers.

You can abstract the platform layer. It's a lot of work, but might be less work then maintaining a code-base for each platform.

If you are working with a very low level API it might be a good idea to abstract it though. You always want to go up one abstraction level, not abstract "sideways". And be aware of the trade-offs like performance, and also being able to understand the code. for example: Developers might know the low level API because it's common knowledge, if you then have made a (leaky) abstraction it might make it much harder to understand.

Re: The Cost of Abstraction (2016)

#34

Post by z3t4 »

drawkbox wrote: post #23
z3t4 wrote: post #17

Earlier quoted context omitted.

Dependencies should be treated like if it was your own code. After you have replaced some API for the third time you can start thinking about wrapping it.

Or if you start with multiple wrapped dependencies from the start, the library is frequently updated and/or you touch the library in many places in your code across multiple projects especially, those are good places for wrappers/facades/adapters. An example would be in games when you submit an achievement or leaderboard score to a third party such as Apple GameCenter, Google Play Game Services, or other systems like…

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

Re: The Cost of Abstraction (2016)

#35

Post by jstimpfle »

z3t4 wrote: post #33
jstimpfle wrote: post #28

Earlier quoted context omitted.

> Dependencies should be treated like if it was your own code Only a Node.js developer could say that. Maybe it's true when the dependency is left-pad or something. Experienced developers in other languages will acknowledge that (non-trivial) code that is not your own code, is not your own code. You seldom have a very good understanding of the underlying models, and the library has absolutely no understanding of your…

If you find an issue in a dependency it's better to fix the dependency, assuming it's open source, rather then wrapping it. Then everyone using it will profit, and don't have to write wrappers. You can abstract the platform layer. It's a lot of work, but might be less work then maintaining a code-base for each platform. If you are working with a very low level API it might be a good idea to abstract it though. You al…

You cannot fix the dependency. It's not broken. Libraries are not designed just for your application. That's the point of libraries. And that's why you need a thin layer that translates from the library's less concrete and more complex model to your application's more concrete and less complex model.

> You always want to go up one abstraction level

I don't think there is such a thing as "abstraction levels". As it says in the Dijkstra quote, abstractions are semantic models. Interfacing means translating between models.

Translations between abstractions might or might not be fully realizable. Very often there's a mismatch and the translation is not possible perfectly, in which case it's a leaky translation. And that's ok. Often the only way to deal with reality is to ignore some difficult parts of it, since otherwise the project couldn't be completed. For example, RPC is an abstraction for network requests to be modelled as function calls. This ignores the reality of the unreliability, throughput, and latency, of real world networks.

And that's ok. There might be some situations in which the program does not work in the real world. But mathematically speaking, at least the program is correct (in a very obvious way) with regards to the simpler model which, unrealistically, assumes that RPC works just like function calls.

So, RPC is not an abstraction that is somehow built on top of network infrastructure abstractions. It's only typically translated to the semantic world of networks. That's an important difference.

Re: The Cost of Abstraction (2016)

#36

Post by pdpi »

taneq wrote: post #25
base698 wrote: post #21

Earlier quoted context omitted.

The "Simple Made Easy" talk describes this as the root of complexity in an application. Mixing and tying various subcomponents that shouldn't have to know each other exist.

> Mixing and tying various subcomponents that shouldn't have to know each other exist. And this is the real trap when dealing with abstractions - maybe the implementations of two different operations are the same, but if the semantics are different then de-duplicating them creates an unnecessary dependency between the two. The more cross-links in your application structure, the harder it is to do anything without bre…

> And this is the real trap when dealing with abstractions - maybe the implementations of two different operations are the same, but if the semantics are different then de-duplicating them creates an unnecessary dependency between the two.

One of the truly remarkable things about Haskell is that its approach to structural abstractions allows you to break out of this problem (though you end up paying a different cost for it)

Re: The Cost of Abstraction (2016)

#37

Post by slack3r »

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…

Abstraction is useful when the resulting code is logically simpler, much like say category theory makes certain results in algebraic topology seem obvious.

Perhaps, you simply mean a different thing when you say "abstraction".

Re: The Cost of Abstraction (2016)

#38

Post by sorokod »

Introducing an abstraction is a way of extending the "base" language into the domain of the problem being solved. Viewed in this way, creating an inc_pair() function does not make sense beyond applications that deal with incrementing stuff. On the other hand, if we are moving a player on a grid, move_diagonaly_up() makes sense and is worth introducing into the extended language vocabulary.

Re: The Cost of Abstraction (2016)

#39

Post by afarrell »

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.

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 making discourse less pleasant.

--

In general, I think a community is healthier when we treat people 25% better than you expect to be treated, to account for the Fundamental Attribution Error and other misinterpretations.

Re: The Cost of Abstraction (2016)

#40

Post by coldtea »

afarrell wrote: post #39
coldtea wrote: post #22

Earlier quoted context omitted.

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.

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

Post reply on HN