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

Re: DRY is an over-rated programming principle?

#31

Post by MichaelGlass » Thu, Jul 07, 2022, 8:09 AM UTC

fartsucker69 wrote: post #18

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…

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…

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 functions and adding a conditional for the non-shared codepaths. shudders

Re: DRY is an over-rated programming principle?

#32

Post by ukoki » Thu, Jul 07, 2022, 8:09 AM UTC

fear91 wrote: post #14

DRY is better for performance (cache efficiency). It’s also less work for the compiler. Those might not be concerns of someone writing pizza CRUD in python.

DRY is not necesarily better for performance. Loop unrolling is extremely un-dry and often provides better performance. DRY can also lead to more branches which can lead to branch predictor misses which can impact performance. For example: the author's update to make_pizza to handle split pizzas introduces a branch where previously the code would have been branchless.

Re: DRY is an over-rated programming principle?

#33

Post by YouWhy » Thu, Jul 07, 2022, 8:10 AM UTC

jcelerier wrote: post #19

YouWhy wrote: post #16

I disagree with the author's example as given. The example discusses a code boundary that is internal to a single atomic "module" - the preparation of a data structure that describes a pizza. Then the author says that bad things will happen if said code boundary is used from other modules. However, why would an extrenal module developer do that? It is common wisdom to recognize and avoid module-internal utility funct…

> However, why would an extrenal user do that? Potential external users typically recognize and avoid module-internal utility functions. External users will go look the implementation of msvc's standard library and reverse engineer windows API to make things faster lol. No internal module function is ever safe.

I agree that no internal module function is safe, but MSVCRT is used by literally millions of developers, some of which have very uncommon functional requirements, such as making their product work on a rare version of Windows. My empirical observation is that most developers are prone to the other extreme of not considering internals when they should.

Re: DRY is an over-rated programming principle?

#34

Post by aaccount » Thu, Jul 07, 2022, 8:12 AM UTC

WRONG. OOP is the most over rated

Re: DRY is an over-rated programming principle?

#35

Post by kristopolous » Thu, Jul 07, 2022, 8:14 AM UTC

ihateolives wrote: post #17

Personal anecdata. I have been increasingly aware of my own mental patterns during development and I've noticed that often I've been sitting and mulling over refactoring to some sort of universal solution instead of getting on with the work and getting things done. There are instances when I could've finished the task twice as fast if I would've just went ahead and done it with repeating code instead of thinking of c…

My principles are "be as stupid as possible" write it for someone stupider and comment it for someone even stupider and then maybe you'll have something maintainable.

(Important note: stupid is not incompetent - it's a proxy for clarity, composability and rational structure without becoming formal, rigid, overly orthodox or academic about it)

Re: DRY is an over-rated programming principle?

#36

Post by misja111 » Thu, Jul 07, 2022, 8:14 AM UTC

pech0rin wrote: post #23

Not sure why this is on the frontpage. Not only are there a bunch of typos, a bunch of code doesn't actually work the way they said it does. Also gotta love hating on the 10x developer or whatever for saying you are wrong. EVERYTHING HAS TRADEOFFS. Every single thing has tradeoffs. Obviously you should not write terrible, brittle code. The reason DRY is important is because when you start duplicating code, having 30…

This. The clean code principles should be considered within the specific context of the situation. They are guidelines that are good to keep in mind, but no more than that.

The article gets this wrong by considering DRY as some kind of dogma and then discovering some situations where it doesn't work well. And then of course some commenters here get it wrong by only looking at situations were it does work well. It's the same religious discussion again as FP vs OOP, static vs dynamic typing, no code vs full code etc. etc. The real answer to each of these is always 'it depends'.

Re: DRY is an over-rated programming principle?

#37

Post by arethuza » Thu, Jul 07, 2022, 8:14 AM UTC

reacweb wrote: post #22

IMO, DRY is the second principle, the first one is KISS. It is preferable to repeat ourself if that contributes to simplicity and ease of maintenance. My third principle is that there is only three principles.

"There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.”

Simplicity is hard.

Re: DRY is an over-rated programming principle?

#38

Post by account42 » Thu, Jul 07, 2022, 8:15 AM UTC

> The problem is that these two pizzas just happen to have the same crust, sauce and cheese.

The problem with analogies is that they are often bad. Don't don't specify that you want tomato sauce and regular cheese when you order your pizza because that's the default.

Re: DRY is an over-rated programming principle?

#39

Post by bjornsing » Thu, Jul 07, 2022, 8:15 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…

TLDR: If you do DRY in moderation it’s great (as the OP explicitly says).

Re: DRY is an over-rated programming principle?

#40

Post by jokoon » Thu, Jul 07, 2022, 8:16 AM UTC

The best principle is KISS https://en.wikipedia.org/wiki/KISS_principle

> "Keep it simple, silly", "keep it short and simple", "keep it short and sweet", "keep it simple and straightforward", "keep it small and simple", "keep it simple, soldier", "keep it simple, sailor", or "keep it sweet and simple".

It's true that often, complexity is praised...