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

361–370 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#361

Post by throwaway2037 »

dbalatero wrote: post #310
the_af wrote: post #309

Earlier quoted context omitted.

Are ORMs still a thing? I've been away from OOP for some years now, but just when I was leaving it, there was a trend firmly against ORMs... my guess was that they were on their way out, replaced by more lightweight libs and frameworks? Or did they make a comeback? Regarding OOP itself, I also remember when "favor composition over inheritance" became a thing. Was this reversed too?

> Regarding OOP itself, I also remember when "favor composition vs inheritance" become a thing. Was this reversed too? I think this is generally still the advice, when working in OOP contexts.

I agree from my extensive experience writing enterprise CRUD software. At this point, inheritance is like a plague that no one wants to touch. The best examples that I have seen are abstract base classes with insanely restricted overrides. If writing Java, imagine all of the public/protected methods are final except one or two. Wherever possible, classes are intentionally final to avoid any inheritance. To make a joke: "That shit is locked down!"

Re: Prefer duplication over the wrong abstraction (2016)

#362

Post by throwaway2037 »

the_af wrote: post #307
throwaway2037 wrote: post #295

Earlier quoted context omitted.

Were you the same when you were a junior? I was. I didn't have the experience to understand the impact of my changes. The norm reply on HN: "You need more mentoring or code review.". Sometimes (usually?) that is in short supply.

Absolutely. I made all the usual mistakes, and had to be mentored and learn from more experienced programmers. (Alas! Sometimes you pick up bad habits from experienced people, and being a junior, you don't know better)

You raise a great point in your reply. At some point, as a junior, you begin to develop your own personal software philosophy and break-away from your seniors/mentors.

Re: Prefer duplication over the wrong abstraction (2016)

#363

Post by QuadmasterXLII »

uberex wrote: post #330
QuadmasterXLII wrote: post #252

Earlier quoted context omitted.

One killer life hack I’ve found is, if extreme duress pushes software into two sources of truth, add a ci test that wont merge into main till the sources match. The canonical case of this actually being the best solution is pyproject.toml / requirements.txt synchronization, but I suspect it has broader applicability. A precondition is that things have already gone off the rails far enough that single source of truth…

I know it is just an example but I'd generate one of those files from the other in that case.

That’s the obvious correct solution, I and many others have tried to make it work for a very long time. The python tooling is or at least was F’d enough that pure generate one from the other is a steady stream of disasters.

What works well is to generate one from the other and check the generated one into source control, and then verify that the checked in generated copy stays up to date using a CI job. But that’s very similar to the “two sources of truth, verified sync” approach

Re: Prefer duplication over the wrong abstraction (2016)

#364

Post by kread »

jonahx wrote: post #164
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…

> 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…

I totally agree with you. If "single source of truth" was possible in every situation, I wouldn't have been confused about first name and last name. When someone asks me first name, I always get confused whether I say first name in Korean or first name in English. I think there are two sources.

Re: Prefer duplication over the wrong abstraction (2016)

#365

Post by preg_match »

what wrote: post #316
preg_match wrote: post #230

Earlier quoted context omitted.

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.

If multiple things use the same regex, which one should it be close to? Or do you propose duplicating it?

My go-to is actually wrapping it in a lambda. The reason being you get nice syntax highlighting you don’t get with string literals! (In PHPStorm the string part of preg_match gets regex highlighting)

Re: Prefer duplication over the wrong abstraction (2016)

#366

Post by throwaway2037 »

Rendello wrote: post #346
throwaway2037 wrote: post #299

Earlier quoted context omitted.

> My big issue is that doing DB-like operations is hellish in most programming languages, and if you really want to try and marshal your data into a real DB (say, SQLite or DuckDB via a library), then you have a big messy translation layer where you're trying to match things to SQL types and you have giant SQL strings everywhere. Have heard of the JOOQ library for Java? It is a godsend because you can write guarantee…

I read about it just a few days ago! I don't use Java, either, but it looked awesome. Right now I'm using Rust, which feels limited in this capacity outside of ORMs.

Oh, it should be possible with an LLM to translate the open source code from JOOQ into Rust. I wonder if anyone has tried yet.

Re: Prefer duplication over the wrong abstraction (2016)

#367

Post by tcfhgj »

Brian_K_White wrote: post #255
Akronymus wrote: post #245

Earlier quoted context omitted.

My metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)

This right here. Here we're loading the customer record and updating their discount % Here we're loading the broker record and updating their commision % They will have 99% identical code. It's possible but exceedingly unlikely we have found 2 things that should be a load_record_and_update_percent(file,id,field,val) Tomorrow the business logic behind one of those will no longer be a simple % and now you have a real m…

Why a mess?

Re: Prefer duplication over the wrong abstraction (2016)

#368

Post by tcfhgj »

janpmz wrote: post #324
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…

> If they diverge This is the key, if they are very similar but used by different consumers the chance that they will diverge in the future is very high. And once they do they will break the abstraction.

You can still duplicate then

Ctrl+c, Ctrl+v

Re: Prefer duplication over the wrong abstraction (2016)

#369

Post by tcfhgj »

andix wrote: post #158
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…

Duplication is often less harmful than abstraction. Duplications can often be cleaned up over time, bad abstractions can quickly become a bottleneck, that severely slow down everyone working on the project.

The opposite

Re: Prefer duplication over the wrong abstraction (2016)

#370

Post by tcfhgj »

ubertaco wrote: post #149
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…

I'd recommend clicking through the headline to watch the talk. Metz talks a lot about types of similarity: similarity by coincidence vs similarity due to an actual semantic or functional equivalence. Code that is coincidentally similar very often diverges in either the short or long term, and DRYing it up aggressively tends to result in functions that have many boolean parameters that each trigger disjoint sets of be…

"tends to result in functions that have many boolean parameters that each trigger disjoint sets of behavior "

What tends to happen is in your hands.

Post reply on HN