Live data from Hacker News

DRY is an over-rated programming principle?

gordonc.bearblog.dev

481–490 of 501 posts

Re: DRY is an over-rated programming principle?

#481

Earlier quoted context omitted.

Where is the typo? And the usefulness of your comment?

the typo is "non-pessimized code", which should be "non-optimized code". I see humor in thinking if my code is pessimistic enough. Have I assumed that the edge cases will happen and worked around them? Do I expect (and handle) crashes, i/o failures, network timeouts, etc? "code pessimism" could be an interesting metric. The typo in the other post was "superb owl" which should have been "super bowl". Several people on…

That's not a typo. But it doesn't seems that you are engaing in a good faith discussion so I don't think further elaboration is worth anything.

Re: DRY is an over-rated programming principle?

#483

Earlier quoted context omitted.

I think that drawing conclusions from these examples is not productive at all. In the wild we're going to see functions such as def make_string_filename(s): # four lines of regex and replace magic so that we have code like file_src = make_string_filename(object_name) file_dst = make_string_filename(object_name_2) which is much more understandable than eight lines of regex magic where you don't even know what the rege…

That's fair. But maybe someone wants to reuse this in another place so they do this: ``` def make_string_filename(s, style="new"): # 2 lines of shared magic if style == "old" # 2 lines of original magic elif style == "new": # different 2 lines of magic ``` When you get here, two totally separate `make_string_filenames()`, each private to the area of code they're relevant to, would be better.

Except that there should be only one way to make a filename from a string. Maybe some options like "allow_spaces" if needed but the point of DRY is not only to share code but to share algorithms.

Re: DRY is an over-rated programming principle?

#484

Earlier quoted context omitted.

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)

Can it be that you‘re using „stupid“ exactly what is meant by „simple“ in the KISS principle? ;-)

Sure. Related. It's an art.

Generally the less code, the cleaner the conceptual execution. I always strive to remove and reduce conceptually deceits

Here's some code I wrote earlier, probably a good example

https://github.com/kristopolous/music-explorer/blob/master/w...

It's self contained, not very big, not trying to be fancy, as direct as possible.

It's worth noting a few things:

Some things are repeated when there's no reasonable way to refactor it in a way that simplify things.

No framework. No view/model/controller/provider/orm separation. It's not doing much and it does it fine

Stuff is composed but intentionally not abstracted

Here's a frontend

https://github.com/kristopolous/music-explorer/blob/master/w...

Again, no react or angular or other framework. Just direct modern code.

As far as what it looks like, it's a music player frontend to some sprawling project Example https://9ol.es/pl/

Re: DRY is an over-rated programming principle?

#485
I think there are three levels of understanding this topic:

1) Repeat yourself everywhere because you're a noob and don't know how to DRY

2) DRY everything because it's easier to maintain, learn all sorts of clever tricks to make DRY work

3) Realise that sometimes it's easier to DRY and sometimes it's easier to write repetitive code.

The problem is that if someone at level 3 (like the author) talks to someone at level 2 then the level 2 developer thinks that they're talking to a level 1.

Re: DRY is an over-rated programming principle?

#486
post #447
post #426

Earlier quoted context omitted.

Quoting myself, due to context switches and parametric entanglement

Can you give an example where abstraction would be too complex, but a snippet wouldn't?

E.g. I rarely abstract http calls or endpoints, because APIs tend to have nuances and to account for them I have to add more parameters than is worth. So I have a full-blown snippet from which I delete irrelevant parts.

Another example is little utilities like a promise as a semaphore (by lifting resolve() to the scope). It could go as a utility function without parameters, but then I’d have to maintain that utility module across projects, which makes it extremely fragile, and force other people to deal with it.

Re: DRY is an over-rated programming principle?

#488

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…

Click bait. Please avoid and don't engage the post.

Re: DRY is an over-rated programming principle?

#489
It looks to me that the author has not faced a problem with DRY, but a junior developer and/or YOLO approach to architecture design.

In many cases thinking about possible future features/extension was one of the most limiting, complexing and at the end irrelevant approach out there, because it usually turned out that the future was different than it had been imagined. On the opposite side, when you take into account just what you know at the time of writing, led to easier adjusts, because it was way more clear to understand.

DRY is a great technique to organize your code, you just need to think about the structure first. In this article, the problem was that he wanted to bend 2 pizzas method into many other different types of pizzas, so his pizza architecture changed so vastly that it was not possible to describe it with just the initial idea of pizza.

Re: DRY is an over-rated programming principle?

#490

I see DRY as a smell, not a principle. If you see clones (same code in multiple places), then it's likely indicating that there is something that can be factorized. Now the question you should ask yourself before factorization is whether the duplication is coincidental (as the author shows) or if it's because the logic was copy pasted. Most of the time it's the second case, and duplicate code does make maintenance ha…

WET -> Write Everything Twice (before premature factorization).
Post reply on HN