Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DRY is an over-rated programming principle?

gordonc.bearblog.dev

Post reply on HN
Print view View original

111–120 of 501 posts

Re: DRY is an over-rated programming principle?

#111

Post by zelphirkalt »

BlargMcLarg wrote: post #62
kaon123 wrote: post #56

I am working in a code base right now that was literally ruined because of #3. It's full of extremely difficult to follow and test higher order functions that are completely unnecessary. A feature request did come for a "half/half" pizza and we're spending our days trying to disentangle the higher order functions. The developer who wrote this thought himself the programmer genius and wanted to make a pattern out of e…

>"why did you hire this guy in the first place, or why did you not fire him?" Because many companies are actually looking for these guys following the principles to a T initially. It's only midway through they complain about them lacking flexibility, if ever. Then later everyone complains about the incomprehensible mess while a few go "that's the way things are, we just need smarter people to understand our solutions…

While one can certainly over-engineer everything into N levels of abstraction either with OOP stuff or with FP stuff like higher-order functions (or higher-higher-...-order functions for that matter), I could well imagine, that a person who knows FP stuff would not have as much of a problem with a specific code base and when that person leaves and only OOP-only people are left, they scratch their heads and call it an "unreadable mess".

So I would not rule out that possibility, without having seen the actual code. Documentation is a point though. One should always document at least for a bit stupider version of oneself. One day in the future that self will come back and "not get it".

That said, it is at least possible, that the company in question needs to hire a smarter person, or simply a more FP informed person. Also entirely possible, that the code is over-engineered and way too complicated for what it achieves. Without seeing an example ...

Re: DRY is an over-rated programming principle?

#112

Post by bjohnson225 »

frognumber wrote: post #43

In this case, the problem is with a bug creeping in: crust: "thyn", DRY is about avoiding this class of cut-and-paste bugs too. Or with changing a string to a token, as it should have been: crust: THIN The code isn't even correct. It's mixing JavaScript and Python. I'm also not sure why you'd declare functions for each type of pizza; that's data. I'm not sure about the context, but the right way is: def make_pizza(cr…

> I'm also not sure why you'd declare functions for each type of pizza; that's data.

Yep, had the same thoughts reading the code. What you suggest even seems a purer implementation of the DRY principle, rather than what is proposed in the article which would result in copy and pasting the make_pepperoni_pizza() function as soon as you decide to sell a third type of pizza.

Of course, the DRY principle used without considering other factors could produce bad results, but all the code in the article is bad for reasons unrelated to the principle it attempts to criticize.

Re: DRY is an over-rated programming principle?

#113

Post by mjburgess »

As with any such article, it comes down to competence mistaken as principle. Principles are never, here, to blame. A cultish (inexperienced) belief in the sanctity of a principle is to blame.

Excellence in programming is trading principles off each other based on the design constraints and expected changes.

DRY trades off everything else in different ways depending on the language and problem. DRY in python should, often stop when you ask "should this be a metaclasss" but before "should this be a decorator", that's different than in C

Re: DRY is an over-rated programming principle?

#114

Post by pydry »

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…

>EVERYTHING HAS TRADEOFFS. Every single thing has tradeoffs

This should be the lede, IMHO.

Re: DRY is an over-rated programming principle?

#115

Post by Joel_Mckay »

API/framework complexity can often be minimized within reason, but given the code-template nature of pattern components it is unreasonable to expect optimization without incurring tightly coupled code/structures.

For example, a project using a framework may only require a developer look at 4 small files to understand the functionality of a resource, and it acts as inline documentation to others on how to quickly contribute new features. In a way, through explicit separation of resources the “similar” code tends to differentiate rather quickly as use-cases rarely share the exact same context throughout the entire life-cycle of a program.

The worst maintenance teams of popular projects permute an API definition every 6 months, and break existing production code in downstream works. You know, ironically still building that bug infested Ivory Tower everyone assumed they could avoid with grossly oversimplified acronyms ( https://en.wikipedia.org/wiki/Ivory_tower ). ;-)

Re: DRY is an over-rated programming principle?

#116

Post by tcfhgj »

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…

> practice this is very relevant when you suspect something might be repeated in the future, but you're not sure.

DRY only hits when you indeed repeat something.

If you predict potential reuse, which you don't certainly know, it's premature optimization.

Re: DRY is an over-rated programming principle?

#117

Post by menaerus »

> Now we are talking about all kinds of fancy programming stuff to try to solve problems that only exist because we don't want to repeat the same 6 line snippet in a handful of different places because DRY tells us that's bad.

Oooh yeaah ... I have had that exact argument in the recent code review where patch literally modified _hundreds_ of LoC across many different files just to avoid duplicating a simple 10-liner at a single place? Yeah, you read that right.

A developer basically rewrote half of the existing code architecture and applied "best" OOP practices. Intention wasn't a bad one but it is unnecessary to say how incomprehensible code would have become if that patch went in in its original form. It was hard to argue against it and what would have been a 10-minute work it became a 2 or 3 week long discussion. And that is just ... bad.

Re: DRY is an over-rated programming principle?

#118

Post by kstenerud »

DRY absolutely can get this ugly and messy (I've seen it many times), but I believe that this is largely an experience problem. You have many tiers of DRY knowledge:

- Have heard of it and it sounds like a good idea

- Let's DRY everywhere!

- OK, maybe don't DRY everywhere...

- There are multiple ways to implement DRY, and it all depends on circumstance

Taking the article example, a better approach would be to DRY the data first (after discovering that in your organization the most common pizza is thin crust with tomato sauce and regular cheese):

    val STANDARD_PIZZA = {
        crust: "thin",
        sauce: "tomato",
        cheese: "regular",
    }

    val TOPPINGS_PEPPERONI = ["pepperoni"]
    val TOPPINGS_HAWAIIAN = ["pepperoni", "pineapple"]

    def make_pizza(design):
        requests.post(PIZZA_URL, design)

    def make_standard_pizza(toppings):
        make_pizza(STANDARD_PIZZA + {toppings: toppings})
Now it's easy to use with no repetition:

    make_standard_pizza(TOPPINGS_PEPPERONI)
    make_standard_pizza(TOPPINGS_HAWAIIAN)
    make_standard_pizza(["pepperoni", "ground beef", "olives", "feta cheese"])
You can easily add to it:

    val TOPPINGS_VEGETARIAN = ["green peppers", "tomato", "spinach"]
Then when you need to expand for half-and-half:

    def make_standard_half_and_half(left_toppings, right_toppings):
        make_pizza(STANDARD_PIZZA + {left_toppings: left_toppings, right_toppings: right_toppings})

    make_standard_half_and_half(TOPPINGS_HAWAIIAN, TOPPINGS_VEGETARIAN)
This gives you both low level and high level (convenience) interfaces to pizza generation, with none of the silly class complexity or function explosion.

Re: DRY is an over-rated programming principle?

#119

Post by oweiler »

JacobSeated wrote: post #28

Except, once you are done, you probably never have to touch that code again, and creating a class does not really take long. Depending on the given problem, this is sometimes more time consuming, but still gets easier and faster with practice, and the benefit down the road can be tremendous. Associative arrays are bad even for such simple things imo, because it breaks autocompletion / code inspections, and your funct…

There was rarely a point where I haven't regretted using an associative array instead of a class. Not only adds the class semantic meaning, you can also add constraints and methods to it.

Re: DRY is an over-rated programming principle?

#120

Post by EugeneOZ »

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…

I can't disagree more. DRY forces you to create pure reusable code, and split your code into small pieces. When I read such code I need to understand just a few pieces.
Post reply on HN