DRY is an over-rated programming principle? • Hacker News Board

Re: DRY is an over-rated programming principle?

#171

Post by tasuki » Thu, Jul 07, 2022, 10:53 AM UTC

Double_a_92 wrote: post #90

dvh wrote: post #59

I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and code is hard to read, bugs are difficult to solve, diffs are difficult. WET code (opposite of DRY code, often starts as copy pasted) has more code, more typing, but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 dif…

Until you end up with multiple similar pieces of code, that seem to do exactly the same thing except for a few small changes... and you wonder if maybe all the other copies would benefit from those changes too.

Oooh, I spent a lot of time doing this! Good times... then I told the lead about svn:externals and we gradually mitigated some of the pain.

To the lead's credit he was humble and open to proposals while I was an asshole about it.

Re: DRY is an over-rated programming principle?

#172

Post by mjw_byrne » Thu, Jul 07, 2022, 10:55 AM UTC

Ironically, the second example has a copy-and-paste bug:

  def make_pepperoni_pizza():
      make_pizza(["pepperoni"])
  
  def make_hawaiian_pizza():
      make_pizza(["pepperoni"])

Re: DRY is an over-rated programming principle?

#173

Post by [deleted] » Thu, Jul 07, 2022, 10:55 AM UTC

[deleted]

Re: DRY is an over-rated programming principle?

#174

Post by neilwilson » Thu, Jul 07, 2022, 11:00 AM UTC

Perhaps the problem is that we've stopped teaching people about coupling and cohesion, along with the mechanism of stepwise refinement.

We abstract to functions to reduce cognitive load and to allow scope rules and information hiding within the language to prevent local variables becoming pseudo globals.

The whole premise of the 'goto consider harmful' structured programming movement was to allow us to replace control structures with a single black box consisting of input-process-output, which aided in reasoning.

The premise was to construct the program from cohesive functions that are lightly coupled.

When did we move away from that?

Re: DRY is an over-rated programming principle?

#175

Post by eloff » Thu, Jul 07, 2022, 11:02 AM UTC

laserlight wrote: post #88

MichaelGlass wrote: post #31

Earlier quoted context omitted.

Agreed. To use the example from the article `make_pizza(["pepperoni"])` What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. I think the article fails to show particularly problematic examples of DRY. E.g. merging two ~similar func…

> What does `make_pizza()` do? It could be a lot or it could be a little. It could have side-effects or not. Now I have to read another function to understand it, rather than easily skimming the ~four lines of code that I would have to repeat. This is not a problem of DRY. This is a problem of wrong abstraction and naming. If the function is just four lines, it could easily be named `make_and_cook_pizza`. In the alte…

Exactly this. I fixed a problem like this a week ago. I found some duplicated code, factored it out into one place by introducing an abstract base class (Python) and in the process discovered one of the duplicated methods had a logic error leading to returning a slightly smaller integer result.

The code had test coverage, but the test confirmed that it produced the wrong result. I had to fix the test too.

Re: DRY is an over-rated programming principle?

#176

Post by lucideer » Thu, Jul 07, 2022, 11:03 AM UTC

mavu wrote: post #13

> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high. Mistake 1: Switch from DRY to premature optimization. > You might think that legit reasonable developers but would not act…

> Mistake 1: Switch from DRY to premature optimization.

Mistake 1a: Conflating the term "premature optimization" - it doesn't apply here. Premature optimization is about runtime performance, DRY is about optimising maintenance overhead.

Mistake 1b: (good) DRY can't be done early (it's a continuous process throughout project development).

> Mistake 2: Assumption of incompetence to support your argument.

Mistake 2: Assuming you're never working in teams leveraging peers' of varying experience and technical focus.

The presumption of re-usability is absolutely the most common red flag I've seen with DRY: I've seen it with a lot of very senior / experienced devs. You can call them incompetent, but there's plenty of them and we have to work with them. Articles like this help.

> Mistake 3: Strawman argument. DRY does NOT lead to over-complicating things. Overcomplicating things leads to overcomplicating things.

This statement concerns me. DRY very obviously and demonstrably leads to over-complicating things (excessive / ballooning parametrisation is just one of many very simple examples of this). If you can't see this I would have my own concerns about competence...

Re: DRY is an over-rated programming principle?

#177

Post by spacemanmatt » Thu, Jul 07, 2022, 11:03 AM UTC

This article is just a rant against what the author sees as popular-but-wrong justifications for DRY, while failing to mention any of the good reasons. -1

Re: DRY is an over-rated programming principle?

#178

Post by mellavora » Thu, Jul 07, 2022, 11:03 AM UTC

hsn915 wrote: post #41

mavu wrote: post #13

> Instead of our code being architected around the concept of how pizzas are made in the abstract, its architecture is tightly coupled to the specific needs of these two pizzas that we happened to be dealing with. The chance that we will be putting this code back the way it was is extremely high. Mistake 1: Switch from DRY to premature optimization. > You might think that legit reasonable developers but would not act…

> Mistake 1: Switch from DRY to premature optimization. "Premature optimization" is largely a bogus concept, because the meaning of "optimization" has shifted a lot since the concept was first created. People now use optimization to mean "sensible design that does not needlessly waste resources". In this meaning of optimization, "premature optimization" is a bogus concept. You should absolutely ALWAYS write non-pessi…

> You should absolutely ALWAYS write non-pessimized code by default.

Some days I come here just for the typos. :)

Today I've seen two good ones, number zero was

"Costco had to stop returns on TVs because people were “renting” them for free for the superb owl."

Re: DRY is an over-rated programming principle?

#179

Post by kitkat_new » Thu, Jul 07, 2022, 11:04 AM UTC

n4r9 wrote: post #146

strken wrote: post #97

Surely you'd remove repetition by doing this instead: hawaiian_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["ham", "pineapple"] } pepperoni_pizza = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza) This isn't better just because it's DRY, it also keeps the data separate from code, which makes it usable elsew…

Even better IMO (although devolving into pseudo code): pizza_base = { crust: "thin", sauce: "tomato", cheese: "regular", toppings: [] } hawaiian_pizza = pizza_base { toppings: ["ham", "pineapple"] } pepperoni_pizza = pizza_base { toppings: ["pepperoni"] } def make_pizza(pizza): requests.post(PIZZA_URL, pizza)

this could(!) be coincidental code duplication

Re: DRY is an over-rated programming principle?

#180

Post by spacemanmatt » Thu, Jul 07, 2022, 11:05 AM UTC

bigDinosaur wrote: post #81

fartsucker69 wrote: post #18

Earlier quoted context omitted.

I don't read coding opinion articles like OP but I like to check out comments. > DRY does NOT lead to over-complicating things. That is not true. I dive around foreign code bases a lot and dry-ness is actually a significant complicating factor in understanding code, because you're jumping around a lot (as in physically to different files or just a few screens away in the same file). As in, inherently every time it's…

DRY makes it harder to actually understand the system as a whole in some sense, since it usually means some indirection has been added to the program. However, it avoids the one thing that actually makes me pull hair out: code that looks the same because it was duplicated but is just different enough to trip you up because each area it was used required minor syntax changes that had major implications for the result.

On a big codebase, I much prefer to learn a function once than see its body repeated frequently. It's not a small thing.