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

61–65 of 65 posts

Re: The Cost of Abstraction (2016)

#61

Post by jstimpfle »

Nursie wrote: post #58
mntmoss wrote: post #49

Earlier quoted context omitted.

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.

But that's exactly what I was describing all the time...

Re: The Cost of Abstraction (2016)

#62

Post by Nursie »

jstimpfle wrote: post #61
Nursie wrote: post #58

Earlier quoted context omitted.

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.

But that's exactly what I was describing all the time...

I got the impression you were saying every dependency should always be wrapped, regardless.

I was a C coder for many years, these days I seem to be doing java. There are dependencies in my recent projects that just do what I need, no particular domain translation required. Particularly things like the Apache commons libraries, which provide well formed utilities for common operations. It would be a waste of time and energy to wrap them simply for the sake of having a wrapper.

If this sort of thing isn't what you were driving at, then we've just been miscommunicating. I am 100% for encapsulation of functionality into good, discrete modules which provide sensible interfaces and minimal (but expressive APIs). I just don't like the blind application of "this isn't our code therefore we must provide an interface"

Re: The Cost of Abstraction (2016)

#63

Post by tome »

Tarean wrote: post #55
ken wrote: post #46

Earlier quoted context omitted.

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

Hmm, don't you use it as a monadic action like

    do
        ...
        both += 1

Re: The Cost of Abstraction (2016)

#64

Post by jstimpfle »

Nursie wrote: post #62
jstimpfle wrote: post #61

Earlier quoted context omitted.

But that's exactly what I was describing all the time...

I got the impression you were saying every dependency should always be wrapped, regardless. I was a C coder for many years, these days I seem to be doing java. There are dependencies in my recent projects that just do what I need, no particular domain translation required. Particularly things like the Apache commons libraries, which provide well formed utilities for common operations. It would be a waste of time and…

Yes I wouldn't wrap a Hashmap or anything I can write myself in less than 100 lines. Particularly if it has a simple and familiar interface.

Re: The Cost of Abstraction (2016)

#65

Post by dllthomas »

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…

> completely hypothetical examples of how to apply programming language features to non-problems in bad ways.

If that were Randall Munroe's next book, I'd buy a copy.

Post reply on HN