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

261–270 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#261

Post by ChrisMarshallNY »

tomjakubowski wrote: post #231
ChrisMarshallNY wrote: post #96

Earlier quoted context omitted.

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…

> 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. I agree that we should think of inheritance and polymorphism separately. If we want to express this intent…

Or...we could hire folks that actually know how to write code, without screwing the pooch.

This is especially true, with languages like C++. Someone (I have heard it attributed to Bjarne, but I don't think he said it) said "With C, you can shoot yourself in the foot. With C++, you can blow your whole leg off."

But there's stuff that can basically, only be done in C++. It's a very powerful, mature, and storied tool; meant to be used by competent grownups.

In tech, we have folks that seem to be absolutely convinced that we can have tools, so marvelous, that we can hire total incompetents, and that they will magically write good code. I know of no other engineering discipline, or craft, where people think like this. They usually have rigorous career ladders, with lots of gates.

Maybe Finance sometimes lets knuckleheads behind the wheel, but then, you get things like the Barings Bank disaster.

"What's Barings Bank?" you ask. "It doesn't exist! Is it a hallucination?"

No, it is not. Unfortunately, they let a rather junior trader, named Nick Leeson, behind the wheel...

It's possible that LLMs may finally give us something like what people want, but I suspect that we'll be seeing folks stumping around on one leg...

Re: Prefer duplication over the wrong abstraction (2016)

#262

Post by dahart »

Waterluvian wrote: post #216

I think about this on occasion. Most recently I ran into an issue during a personal project: 2d sprites for RTS units were packed on spritesheets in a consistent manner: 5 sprites for 8 directions (you mirror 3). Packed in order of: stand, move, attack, die. So I made a loader that understands how to take action + direction and offer an array of sprites to play through. But then I came across more cases: sprites with…

You probably already have the common abstraction factored - the code to load pixels for a single sprite, and to display it? It makes sense to me that the level above that, interpreting the sprite sheet layout and modes of playback, come in different flavors and don’t have a common abstraction that fits all cases.

Personally I prefer what you’re doing over trying to come up with a non-obvious abstraction or trying to make an imperfect abstraction fit. Waiting til the abstraction is totally obvious and the need is crystal clear is a good thing.

The flipside (antidote?) of DRY is WET - write everything twice/thrice. More important, IMO, is to abstract only over things I have an actual, demonstrated use case for, usually demonstrated first via duplication, and not speculate about possible future uses I might want. Code written for future use cases we don’t have is so often the code that gets in the way of abstracting the things we do have, and it cracks me up when that happens.

Re: Prefer duplication over the wrong abstraction (2016)

#263

Post by ketozhang »

stanmancan wrote: post #214
jonahx wrote: post #164

Earlier quoted context omitted.

> I believe that "single source of truth" is a principle that should always be followed Fundamentally, the article addresses cases where it's not clear yet how many sources of truth there will be. Are the two spots in the code using the same algorithm, or slightly different versions? More importantly, will they change for the same sorts of reasons? The title adage (correctly, imo) argues that making two different thi…

The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places. Accidental divergence is the problem, not intentional.

This assumes the bug exists in both places which might not be true at all even if they both are dependent on the same duplicated code.

If you only spot the bug in path A and not path B, why fix the bug for B?

Re: Prefer duplication over the wrong abstraction (2016)

#265

Post by Waterluvian »

dahart wrote: post #262
Waterluvian wrote: post #216

I think about this on occasion. Most recently I ran into an issue during a personal project: 2d sprites for RTS units were packed on spritesheets in a consistent manner: 5 sprites for 8 directions (you mirror 3). Packed in order of: stand, move, attack, die. So I made a loader that understands how to take action + direction and offer an array of sprites to play through. But then I came across more cases: sprites with…

You probably already have the common abstraction factored - the code to load pixels for a single sprite, and to display it? It makes sense to me that the level above that, interpreting the sprite sheet layout and modes of playback, come in different flavors and don’t have a common abstraction that fits all cases. Personally I prefer what you’re doing over trying to come up with a non-obvious abstraction or trying to…

> Waiting til the abstraction is totally obvious and the need is crystal clear is a good thing.

I discovered this after a few early years of my career being a bit of a “best practices” zealot. The thing I say often at work is, “let’s get this shipped to prod so we can start learning all the things we don’t yet know about it.”

Re: Prefer duplication over the wrong abstraction (2016)

#266

Post by jongjong »

Also, I prefer having all the code inside a single 5000-lines file than split up into many small files representing incorrect abstractions.

The urge to split the code up since they beginning is generally a bad idea; it forces early abstraction; more likely to be wrong.

Re: Prefer duplication over the wrong abstraction (2016)

#267

Post by dahart »

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…

Having the constants at the top is more easily customizable, especially should this file get duplicated. If devs need to switch to http instead of https for testing or staging, it makes sense to separate the scheme from the domain and put the constants up top or even in another file. It also matters whether ‘url’ was constructed in multiple places or a single place. Having named constants at the top of the file is a very common style, and sometimes is part of the group coding standards.

Anyway, maybe there are other reasons too, so see Chesterton’s Fence. In any case, it’s never a good idea to assume cargo culting. Someone could easily say the same thing about using inline literals. If it looks weird, ask around and maybe you’ll find out there are good reasons, or maybe you’ll find out nobody cared and that people will like it if you refactor and embed the constants.

Re: Prefer duplication over the wrong abstraction (2016)

#268

Post by ttoinou »

t-3 wrote: post #257
ttoinou wrote: post #236

Earlier quoted context omitted.

We still need a way to track that there’s some common pattern in the code. So that when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that

> when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that It can, that's all about how aggressively you factor and structure your code, eg. combinators make it easy to reuse code in different application patterns without rewriting.

In which language do you use combinators for that ?

Even in that case the refactor can introduce mental overhead when having too many different variable / properties names

Re: Prefer duplication over the wrong abstraction (2016)

#269

Post by ttoinou »

Akronymus wrote: post #248
ttoinou wrote: post #246

Earlier quoted context omitted.

Me too ! I don't follow DRY that much, I'm aware that copy pasting is good enough for a few weeks / months to see how things evolve in the future, and do refactor when it's really needed. That said, how do you know if they mean different things ? For GUI code for example, they do mean the same thing, but there's a good chance the code will evolve in the future so premature refactor are wasted time

Mostly by looking at the calling site where the code is already used and the calling site where I want to reuse it. If both of those mean the same (calculate the tax on x products, for the purpose of applying to the shopping cart, vs for applying to generating reports) then I'll reuse it, if it can be achieved without adding stuff like flags, in most cases. In other cases, it just looks the same (sum some field + cal…

Its always about how far ahead in the future you plan ahead. And sometimes this future thinking is wasted time
Post reply on HN