Live data from Hacker News

DRY is an over-rated programming principle?

gordonc.bearblog.dev

451–460 of 501 posts

Re: DRY is an over-rated programming principle?

#451

Every time I read an article like this, "why is overrated", I think, yeah you are right in theory. But most places I have worked, these best practices were not overused, but underused. If you have the problem that your coworkers create unneccessary abstractions, I envy you, because I have so often had the opposite problem. Maybe this is not the case if you work in a great software development team. But if you work so…

> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

That’s some did-I-wake-up-in-another-dimension shit. :)

Re: DRY is an over-rated programming principle?

#452

Earlier quoted context omitted.

> I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY. “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” is the verbatim definition of DRY from when the DRY principle was first articulated.

Yeah there are a lot of definitions out there that are along these lines and they do hollow out my argument. But why call it "Don't Repeat Yourself" if it actually means something somewhat more subtle than that. I firmly believe many junior developers don't grasp the nuance and based on the comments I'm not the only one who thinks this. So if DRY is widely understood by developers to mean literally "don't repeat your…

Unfortunately, words mean things and people will take names to mean what they say.

Re: DRY is an over-rated programming principle?

#453

Earlier quoted context omitted.

If you have client and server side and you have to check only in one place if conditions are met, this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase. Not sure if this is always feasible. Add DB to that and this means that you have to always check for constraints at DB level.

> If you have client and server side and you have to check only in one place if conditions are met, this means that you cant check in client side anything and must do a server call, or implement both server side and client side in single codebase Checks don't have to include the definition of knowledge independently, so multiple checks against the same rule don't need to be a violation. As a simple example, if you ha…

Have not thought about this. Good point. Constraints as a data not as a code. aka schema.

Re: DRY is an over-rated programming principle?

#454
post #290

Earlier quoted context omitted.

> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

I regularly see code of the form `if(x == false)` as the author has a distrust of `if(!x)`. I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.

Even more common seems to be

  if (x == true)
which always seem to come with some argument how it is "more clear".

I have started to ask people straight away to change to

  if ((x == true) == true)
which following the same argument should be even more clear.

Re: DRY is an over-rated programming principle?

#455

Earlier quoted context omitted.

You've answered one of the easiest ways to do it: just use the same language. Node (and Deno/Bun) is a good way to maximize code sharing and single points of truth. But I definitely understand not everyone wants to write all of their backend in JS (or even TS). (Node ORMs sometimes don't have the polish of their cousins in other languages, for instance.) There are great opportunities here for language mixing, however…

You're assuming a web client. The example I had in mind was a mobile client, where we actually used a cross compiler to generate java byte code from swift to allow code sharing between iOS/Android clients, but that wasn't usable for the backends (which were C# mostly). Which is why I went with a server-precomputed lookup table in the cases the number of possible inputs made that feasible. If not, reg-exes for validat…

Option 1 applies to mobile frontends, too. In Swift you can always call JavaScriptCore to run a script. Android can use system-wide V8 or even bundle a smaller interpreter for JS.

(In fact, JS is the only "universal" scripting language in mobile due to Apple's fun restrictions that JavaScriptCore is the only JIT engine allowed on iOS. It really is the strongest option today for language to write things in if they absolutely need to be shared across all possible operating environments.)

Re: DRY is an over-rated programming principle?

#456
post #362
post #209

Earlier quoted context omitted.

Don't do this! OP's version is better! It might be "fine", but you don't gain anything here while introducing both indirection and coupling. DRY is _not_ about data repetition. Data repetition is fine. Alice and Bob having the same birthday is coincidental. And even if they are actually twins, you rather say that they are twins separately. In your example you are just preserving keystrokes, but you don't say anything…

With only 2 types of pizza with the same base, I'm inclined to agree. But if there are more, or a strong potential for more (as there is with pizza), I'd argue that this factoring allows simpler implementation of new pizzas as well as easier comparison of existing pizzas.

I think volume is almost deceptive. It seems like we’re doing useful compression, but if we’re not careful we introduce complexity and indirection that is not based on actual needs. So we essentially code ourselves into a corner.

There are circumstances when your version is actually better: when pizza_base has a real meaning in your domain, outside of the code representing it. The chefs, accountants and so on use the term day to day, and might even have specific pricing or techniques around it. Then pizza_base is an actual thing that you want to represent in some way.

However it could also just be a function, which derives from pizza_base from your raw data. Like is_pizza_base(). I would prefer that in general.

There is nothing wrong with dumb, raw, data. It gives you leverage and frees you from coupling.

Re: DRY is an over-rated programming principle?

#457
The key skill is to distinguish between harmful repetition, harmless repetition and beneficial repetition.

Say you have two templates (web pages). They are conceptually independent and serve two different business purposes. Yet in terms of their structure/content/whichever, they have about 20% in common.

Somebody obsessed with DRY would now elevate that 20% into some reusable module, after which both templates use it and the repetition is gone. Feels clean.

In reality, you didn't solve a real problem whilst you created a new one. Now individuals/teams cannot independently edit these templates as they need to understand and check the dependency tree. It no longer is simple, there's no piece of mind.

Next, inevitably somebody is going to request changes impacting that 20% and before you know it and after cutting lots of corners, you end up with this freak component that changes output based on some flag.

It's taken me 20 years to come to this conclusion: the negative effects of (too much) DRY (it increases complexity) show up in every single project and make code harder to understand and change. Meanwhile, the negative effects of allowing (some) repetition are mostly theoretical and more often than not a benefit, not a negative.

I mean it. This is coming from an ex-DRY fan boy. The DRY principle makes us eager to connect dots that really aren't connected and shouldn't be connected.

Re: DRY is an over-rated programming principle?

#458
post #328

Earlier quoted context omitted.

On a similar note, tree/graph structures should be avoided versus lists unless there is a good reason. Flat is better than nested. A linear block of code is far easier to reason about than a network of function calls, or (heaven forbid) a class hierarchy. Not that such tools don't have their place, but I've seen too much convoluted code that has broken simple things into little interconnected bits for no reason other…

I'm not sure I follow... Can you provide an example? (junior dev here) If I understand some of it correctly, I was contemplating this when I started writing functions for "single functional concepts" like, "check for X; return true or false", then called each of those functions sequentially in a single "run" function. Is that what you mean? I found that approach much easier to test the functions and catch bugs, but y…

My own understanding of the comment:

They're making a connection between non-jumping code with a list, and jumping code, like classes, functions, etc. with a graph. A list can be iterated from beginning to end and read in sequence, or can be jumped into at any point in the code at arbitrary points. Similarly, if I open a file and want to read code, I can jump to any arbitrary line in the code and go forwards or backwards to see what the sequence of code is like. I can guarantee that line n happens before line n+1.

With functions, classes, modules, whatever, the actual code is located somewhere else. So for me to understand what the program is doing I have to trust that the function is doing what it says it's doing, or "jump" in the code to that section. My sequence is broken. Furthermore, because I am now physically in a new part of the code, my own internal "cache" is insufficient. It takes me some effort to understand this new piece of code and re-initialize the cache in my mind.

The overall thrust of DRY is overrated is that we often times take DRY too literally. If I have repeated myself I MUST find a way to remove that repetition; this typically means writing a function. Whereas previously the code could be read top to bottom now I must make a jump to somewhere else to understand it. The question isn't whether this is valuable, rather, whether it is overused.

Re: DRY is an over-rated programming principle?

#459

Earlier quoted context omitted.

> I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY. “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” is the verbatim definition of DRY from when the DRY principle was first articulated.

Yeah there are a lot of definitions out there that are along these lines and they do hollow out my argument. But why call it "Don't Repeat Yourself" if it actually means something somewhat more subtle than that. I firmly believe many junior developers don't grasp the nuance and based on the comments I'm not the only one who thinks this. So if DRY is widely understood by developers to mean literally "don't repeat your…

There's nothing wrong with "Don't Repeat Yourself" except if it applies to code rather than knowledge.

Any principle like this that is applied to code is wrong.

Re: DRY is an over-rated programming principle?

#460
post #290

Earlier quoted context omitted.

> People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Nex…

I regularly see code of the form `if(x == false)` as the author has a distrust of `if(!x)`. I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.

The UW intro CS courses call the `if (x)` form "Boolean Zen", which I've always enjoyed.
Post reply on HN