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

191–200 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#191

Post by mdavid626 »

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…

Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.

Re: Prefer duplication over the wrong abstraction (2016)

#193

Post by more-coffee »

alkhimey wrote: post #180

The disadvantages of duplication are greatly reduced in the world of AI. From my experience it can easily detect the duplicates and refactor code safely. On the other hand, code without abstractions is easier to read and easier for AI. With AI, we really need to rethink the clean code principles.

Seems to me like the last thing you want to do is worry whether the LLM has a large enough context window to keep an eye on all duplicates. So I'd argue to deduplicate directly, where possible.

Re: Prefer duplication over the wrong abstraction (2016)

#194

Post by cluckindan »

fpoling wrote: post #189
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…

With LLMs the cost of duplication is much lower and LLMs

> and LLMs

… sometimes duplicate things unnecessarily.

Re: Prefer duplication over the wrong abstraction (2016)

#195

Post by jihadjihad »

mdavid626 wrote: post #191
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…

Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.

> as if duplication would be the root of all evil

And instead it gets replaced with the actual root of all evil, complexity.

Re: Prefer duplication over the wrong abstraction (2016)

#198

Post by [deleted] »

dang wrote: post #178
stcg wrote: post #175

This is like saying "A slow leak is cheaper than a burst pipe" Yes, okay. But with both you will have a bad time cleaning up. There is a third option: good abstractions. I did see this pattern described in the blog in practice a lot (and fell victim to it myself) and I think that in general this comes down to inexperienced programmers. Object oriented programming makes it worse. Teaching these programmers that they s…

The OP is aware of good abstractions and is describing a procedure for finding them, or for increasing one's chances of finding them.

[deleted]

Re: Prefer duplication over the wrong abstraction (2016)

#199

Post by mystifyingpoi »

cryo32 wrote: post #190
mystifyingpoi wrote: post #186

Earlier quoted context omitted.

I get the joke, but in ideal world, in microservices, there is no such thing as code duplication across services. As a maintainer of a service, I should not give a crap about code present in some other service - it's some other team's code, why would I care? I don't have to even know that the other team exists. In big systems, it happens that I can't even feasibly know the existence of all the applications.

You mean you don’t have 300 versions of your badly developed rapidly evolving platform services rotting away underneath the bit you didn’t duplicate?

I don't. Other teams - maybe they do, maybe they don't. Who cares, not me. I have responsibility for services of my team, I think we are doing a good job.

Being selfish is the core principle of microservice architecture.

Post reply on HN