Hacker News Reader

Comment by AdriaanvRossum | Hacker News Reader

Like DRY is wrong? I don't really get the point of this article.

The comment that it's about knowledge, not code resonated with me.

Like, if you saw Http.getClient(...).doGetRequest(...) a few times, it wouldn't be worth pulling them out into a myGetRequest(...) method. Your teammates already understand the existing, repeated statements, but they haven't seen myGetRequest(...) before, so you wouldn't be making the code any more readable to them.

But if you had Http.getClient("auth.myservice.com:8443").doGetRequest(...) in a few places, then I would pull out the host and port (or maybe the whole line), since it contains knowledge of where/how to authenticate.

Coming from the other direction: if I were reading the code, I can imagine myself looking for the one place where the auth happens, but I can't imagine myself needing to know the one place where Get requests happen (even if the 'Get' code is repeated much more than the 'auth' code)

I think, you are making a good point for what may be called mutable knowledge. I.e., when writing a shell script to iterate over a few files, nothing of this is of utter importance, since the script is meant to be run only once, thus we may consider any knowledge immutable. Also, maintenance and readability aren't much of a consideration here. In the case of a "real" application, when connecting to an endpoint, as in your example, we may consider address and credentials subject to change, so this is mutable knowledge, which ought to be represented once. However, the method of connecting is hard coded in several places, so it's pretty much immutable. If we expect the method of connecting (http) subject to change, we should consider to put this in a single spot, as well, even, if this may mean that the code may be harder to follow, since we introduced another layer of abstraction. And so on…

DRY was introduced in the Pragmatic Programmer, and Dave Thomas pointed out in a recent Changelog episode that DRY doesn't mean "Don't repeat code", it means "Don't repeat knowledge."

One concrete example: If your software has to create really complex objects, would you rather describe _how_ to create those objects in 10 places or one place? That's a scenario where you don't want to repeat yourself.

Dan Abramov [wrote about](https://overreacted.io/goodbye-clean-code/) this (linked in the OP), but in his example he's removing repetitive code. He's not removing multiple copies of the _knowledge_ about what the program is supposed to do.

It's a subtle difference that seems more difficult to describe than I'd like, but it's an important one.

Sometimes "A little copying is better than a little dependency."

I absolutely subscribe to that, but then again, I don't have a Rule of Three or similar...

It's a bit difficult to get across in text, but the minimum number of repetitions of a piece of code to make it "worth" putting it in a function is... 1. (According to me, and Tony van Eerd of Postmodern C++ fame. I had come to this conclusion on my own, but his talk really articulated it well.)

It's all about limiting the scope of side-effects, accidental reuse or variables, etc. etc. such that a human can do chunking to understand the whole.

I generally find that this is not an easy thing to capture in "metrics" or "rules". Guidelines with reasonable rationales, etc. etc. and when-not-to's, definitely, but that's a really hard thing to do and it doesn't get many clicks.

EDIT: ... and just to get back to DRY. The acronym is far too absolutist, but Try-Not-To-Repeat-Yourself-Too-Much-Unless-You-Have-Good-Reason-To isn't quite as catchy, is it?

I've seen so many times people going all in on DRY not understanding that just as dangerous as duplication is _coupling_ - the inevitable result being some ungodly $COMPANY_NAME_common lib with a thousand dependencies, and usually only depped in a codebase for a config parser and a string helper. See also node_modules and left-pad.io.

No, they're not saying it's wrong, but rather it's commonly misunderstood. From the motto alone you might think the point is to abjure all code duplication. But Hunt & Thomas' intent was instead to warn against duplicating sources of truth/knowledge - that is, all knowledge embedded in your code needs to have a canonical source, and all other references should derive from that source or you risk divergence (or in the best case must always remember to make necessary changes in multiple places).

So for example, documentation (truths about the code) should derive from the code (eg by doc generation). Otherwise the docs & code will drift apart. Or if you're passing domain information across the wire between client & server, you should derive the data structures at both ends from a common source.

>all knowledge embedded in your code needs to have a canonical source

I don't get it. Code /IS/ knowledge and whenever I copy-paste code around, I duplicate not only code but also knowledge.

Well (and I'm elucidating, not necessarily defending) they mean knowledge somewhat specific to the project, not in an absolute philosophical sense.

So you have an API that belongs to this project. When you change it, do so in one place, and then run your doc generator rather than change it in both function/method signatures and docs.

Or you have domain knowledge embedded in classes, and a wire protocol between peers or client & servers using different languages. Derive the data structures in the two different languages from common source (either one of the languages, or both from metadata).

I think the distinction between this kind of project-specific 'knowledge' and more abstract 'everything is knowledge' issues is clear enough in practice. But it is just a rule of thumb rather than a deep philosophical principle, and like all such will break down in individual cases.

whenever I copy-paste code around

But that's just one source of code duplication. Another might be (for example) duplicated code deriving from code generation. DRY might advocate this (as there's a clear canonical source of knowledge), whereas a generic rule against all 'duplication' wouldn't.

It's true that code is knowledge, but I think it's talking more about not having slightly different versions of that knowledge floating around the same code base. For example, if there is one canonical way to do something, such as adding a table row and having to remember to update counts somewhere else, then that should be done in one place. That way, if that agreed-upon way changes you don't have to remember that it's done in 25 other places across your code base.

Sometimes, things happen to be the same now, but they got there for different reasons and are likely to evolve differently in the future.

In that case, there is not a single piece of knowledge being duplicated, but rather two separate pieces of knowledge being possibly unified.

>Like DRY is wrong? I don't really get the point of this article.

More that it's a guideline, not a law. We should always use best judgement to decide when the tradeoff of readability and declarative code is worth a small amount of repetition, rather than religiously refactoring something for the sake of it.

Reply on news.ycombinator.com