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

Prefer duplication over the wrong abstraction (2016)

sandimetz.com

Post reply on HN
Print view View original

221–230 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#221

Post by the_af »

dasil003 wrote: post #218
the_af wrote: post #202

Earlier quoted context omitted.

This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This…

This smells more like the fluidity of what people mean by “junior” more than anything else. Journeymen engineers in their over-engineering phase, or even very “senior” expert programmers can suffer over fitting the product to their own mental model. The most senior judgment is to understand when an abstraction makes sense at a customer level, because that defines the durability of a business-logic abstraction.

I do agree this happens with the senior overengineering phase, but the comment I replied to mentioned "especially juniors" and I've heard this trope specifically about juniors, with the implication they want to apply what they learned in college, but this hasn't been my experience at all.

Re: Prefer duplication over the wrong abstraction (2016)

#222

Post by tomjakubowski »

locknitpicker wrote: post #134
fny wrote: post #35

Earlier quoted context omitted.

Code duplication is cheaper than the wrong abstraction. If you have a good abstraction, you should run with it. If you haven't figured out a good abstraction at 5-100 customers, God help you.

> If you haven't figured out a good abstraction at 5-100 customers, God help you. This blend of opinion is very naive. Every single project is a business requirement away from having the wrong abstraction in place. https://xkcd.com/1425/

Reminds me of the Taskmaster interview of Sam Campbell, where (Little) Alex Horne is changing the requirements on his portrait up to the last second.

https://www.youtube.com/watch?v=VG0btgXY_D0

Re: Prefer duplication over the wrong abstraction (2016)

#223

Post by Akronymus »

platz wrote: post #38
bhouston wrote: post #13

I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well. So code duplication because of abstraction issues is rare. Code du…

what exactly is 'calling a function in two parts'

I assume to split the overall behaviour (loop through all elements, transform some value, etc) and the specific one (apply this function to all elements, transform it in this way, etc) into multiple functions and combine those to achieve the actual intended behaviour.

At least that's my interpretation

Re: Prefer duplication over the wrong abstraction (2016)

#224

Post by alberto467 »

lg5689 wrote: post #55

I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…

Code duplication differs from single source of truth applied to data in the sense that data is data but two pieces of code may functionally be the same (they do the same thing) but they might be semantically different in their usage (they’re advertised to achieve different things), in that case coupling them together with deduplication and forcing them to do the same thing doesn’t really make sense, and may make the codebase more difficult to work on in the future (especially in companies where different teams have responsibilities over different parts).

Re: Prefer duplication over the wrong abstraction (2016)

#225

Post by aftbit »

Similarly, I've seen some developers who seem to think that any inline string or numeric constant is evil. In one PR, I saw:

    HTTPS_SCHEME = 'https'
    DOMAIN = 'www.example.com'
    
    url = HTTPS_SCHEME + '://' + DOMAIN
I don't understand what they think this is buying, other than just cargo culting "don't embed constants." And of course, the constant definitions were at the top of the file and the url building code was hundreds of lines away.

Re: Prefer duplication over the wrong abstraction (2016)

#226

Post by tosh »

platz wrote: post #38
bhouston wrote: post #13

I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well. So code duplication because of abstraction issues is rare. Code du…

what exactly is 'calling a function in two parts'

apparently it is not what the author meant but:

using projection you can "call a function in two parts"

  add: {x+y}
  add4: add[4] / gives {4+x} by fixing 4 as first argument to {x+y}
  add4[2]      / gives 6
this is a useful pattern that you can use to first 'fix' data or behaviour to produce another function

https://en.wikipedia.org/wiki/Partial_application

Re: Prefer duplication over the wrong abstraction (2016)

#227

Post by dofm »

jbeninger wrote: post #162
dofm wrote: post #85

Earlier quoted context omitted.

> I agree that LLMs are naturally anti abstraction machines.. I'm often trying to find way to reverse that. I am a bit of an LLM cynic but I am trying to learn it all, and I have to say I have spent most time trying to work out: how do you explain how a brown-field codebase actually works, in such a way that the LLM won't pervert it through misunderstanding. It does encourage you towards the "conventional" coding sta…

The gold standard is code samples. I've got 1000-line convention documents with very simple rules like "Early returns on a single line". Llms sometimes ignore these or misinterpret them in unusual ways. But if I tell it "read these files that use the same conventions" first, there's no misunderstanding, and the agent also picks up the general "tone" of the code. I have very little to tweak if I've defined the problem…

> But if I tell it "read these files that use the same conventions" first, there's no misunderstanding, and the agent also picks up the general "tone" of the code. I have very little to tweak if I've defined the problem well.

Oh that is a bloomin' great idea, and I can fully see how it might work better.

Can't tell you how valuable this comment has been to me and now I feel so much better about evidently kicking a hornet's nest ;-) Thank you so much.

Re: Prefer duplication over the wrong abstraction (2016)

#230

Post by preg_match »

aftbit wrote: post #225

Similarly, I've seen some developers who seem to think that any inline string or numeric constant is evil. In one PR, I saw: HTTPS_SCHEME = 'https' DOMAIN = 'www.example.com' url = HTTPS_SCHEME + '://' + DOMAIN I don't understand what they think this is buying, other than just cargo culting "don't embed constants." And of course, the constant definitions were at the top of the file and the url building code was hundr…

I’m a big fan of closeness in code. I prefer defining things as closely to where it’s used as possible. This is a big pet peeve for me!

Do not put regex at the top of the file either! Put it where you use it. Languages are smart, they’ll probably be able to tell that it’s constant anyway.

Also for tiny functions just use a lambda. Please don’t make a one line function a million miles away that you use once or twice.

Post reply on HN