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

91–100 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#91

Post by christophilus »

Rohansi wrote: post #21
christophilus wrote: post #5

Yes. I’m dealing with a graphql, urql, Next, Prisma stack at the moment. Something that would be a handful of lines of code in a different stack ends up being hundreds in this one. The Node ecosystem is full of wrong abstractions.

The problem is self-inflicted. You do not need to keep jumping to the next trendy framework.

I inherited this one. My preferred SPA stack these days involves Porsager’s Postgres library, a simple RPC stack with Zod schemas, and Preact.

Even better is an old school MPA with progressive enhancement.

Re: Prefer duplication over the wrong abstraction (2016)

#92

Post by nfw2 »

dofm wrote: post #25

No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a…

Over-engineering and "abstraction hell" are very much not iconoclastic concepts

Re: Prefer duplication over the wrong abstraction (2016)

#93

Post by davidee »

dofm wrote: post #63
coldtea wrote: post #47

Earlier quoted context omitted.

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.

Good faith question: would it?

Wouldn't most large codebases with poor abstractions just have engineers engineer around them with their own solutions? In a large enough codebase you'd have both the bad abstractions and all the not-quite-duplicate implementations ignoring the bad abstraction?

I'm using bad here loosely, it could be buggy, incorrect, incomplete, insufficient and more; while being owned by someone or some team that's a challenge to work with for various reasons (overloaded, under-resourced, overbearing, etc., etc.).

Re: Prefer duplication over the wrong abstraction (2016)

#95

Post by rpdillon »

dofm wrote: post #63
coldtea wrote: post #47

Earlier quoted context omitted.

Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…

> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.

In your mind, what's the cost of the wrong abstraction?

Re: Prefer duplication over the wrong abstraction (2016)

#96

Post by ChrisMarshallNY »

dofm wrote: post #25

No it's not. This has always been a needlessly iconoclastic rather than sensible suggestion. At the very least it is not once you're working at the wrong kind of scale. Once you have an awkward number of customers (more than five and less than a hundred), maintaining duplicated code that should have been abstracted and modularised will only seem cheap if you don't mind that you burn through even junior employees at a…

In my experience, the answer is always "It Depends." That's about the only thing that I can hang "always" on.

It really depends on the exact type of code we're working with, and what our objectives are.

In my case, I often use object inheritance. It's a damn cheap way to DRY. However, when people hear "inheritance," they often think "polymorphism." There's a really big difference between the two, but popular culture has jammed them into one ball, and it's not worth the agita, to try to explain the difference.

But if you are doing optimization, long stacks can be your enemy, and inheritance tends to have long, windy stacks.

In these cases, the copy/pasta method may well be the best approach.

Like I said, "It Depends."

Re: Prefer duplication over the wrong abstraction (2016)

#97

Post by vlunkr »

dofm wrote: post #90
mytydev wrote: post #82

Earlier quoted context omitted.

It sounds to me like you are describing a good abstraction. This article does not claim that code duplication is better than any abstraction. It claims that code duplication is better than the wrong abstraction. I'm sure this author would agree that a good abstraction is better than code duplication.

I'm afraid this comment reads in a rather gnomic way. Of course it's a truism if you just say any abstraction that works is a good abstraction. That is not what I am saying at all. Bullshit abstractions at least let you control the problem. Duplication doesn't.

But it’s never going to be 1:1 duplication is it? Sometimes it’s better to copy code as a template for something new, rather than try to immediately force a new abstraction.

I agree with you that it’s a truism, but it’s useful advice for people who have a habit of trying too hard to DRY their code. IIRC the author comes from the Ruby world, where DRY was a big thing, and this talk was part of the pendulum swinging back away from this DRY obsession that sometimes just resulted in convoluted code.

Re: Prefer duplication over the wrong abstraction (2016)

#98

Post by cpursley »

christophilus wrote: post #5

Yes. I’m dealing with a graphql, urql, Next, Prisma stack at the moment. Something that would be a handful of lines of code in a different stack ends up being hundreds in this one. The Node ecosystem is full of wrong abstractions.

Nextjs in particular is a dumpster fire, it's a shame that it's the default stack many LLMs slop out.

Re: Prefer duplication over the wrong abstraction (2016)

#99

Post by chuckadams »

lokar wrote: post #68
irishloop wrote: post #51

Too many abstractions are bad. Too many code duplication is bad. Part of being a good engineer is finding the right balance. I know engineers who would gladly duplicate code all over the code base to avoid creating a new abstraction. I know engineers who create polymorphic abstractions for a single caller with a very obvious set of parameters. So much of wisdom is in finding balance and not being dogmatic about rules…

I feel like the balance has shifted over the last 30 years, and is speeding up. Semi-automatic and fully automatic re-factoring has made dealing with duplicated code much faster, cheaper and safer. Changing abstraction is still high risk.

I have regularly watched agents forget to update one duplicated pattern after changing it somewhere else. If it's within a single file or related class, it'll catch it, but if it's off in some other package in the monorepo, it's a crapshoot.

Re: Prefer duplication over the wrong abstraction (2016)

#100

Post by chairmansteve »

dofm wrote: post #69
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.

I disagree. But also it's very possible to not realise you needed an abstraction until it catches fire in multiple places. And quite often it's not you that got the codebase to a hundred customers, is it? Sometimes it is a sequence of fresh-faced young developers who didn't have the authority to say "this duplication is bullshit" and were instead compelled to repeat it. I think a lot of these discussions happen in ni…

> I disagree.

So... the wrong abstraction, no matter how bad, is better than code duplication?

Post reply on HN