4 ms·

> Conscious duplication (often called “forking”) allows people who depend on a piece of code to change it without breaking anyone else. Then that code is DRY b

by dgb23 3y ago

> Conscious duplication (often called “forking”) allows people who depend on a piece of code to change it without breaking anyone else. Then that code is DRY by definition and simpler. It can’t be Non-DRY because that would imply you’d need to change things in multiple places at once in order to avoid breakage. If you have two separate parts that can evolve independently, without coordination then those parts don’t represent the same piece of knowledge.

dahart 3y ago
Well all repeated code can evolve independently too, so by that definition, how can non-DRY code exist? This discussion is a bit too abstract and losing meaning as a result. I think you’re glossing over the very real scenarios of code (“knowledge”) that’s similar but not the exactly the same; of copies of code that are similar being merged; of code that’s exactly the same being intentionally forked and “repeated” and placed nearby; and others. Repeated code definitely can be the same piece of “knowledge” and exist in multiple places without coordination. After that the copies might drift in different directions, and the DRY dogma says this is bad. This is what people mean when they talk about DRY principles, the general idea to look for and merge similar code, and to prevent multiple pieces of similar code from being able to evolve independently. DRY in fact doesn’t really come up if two pieces of code are exactly the same; then it’s pretty obvious and easy to factor it. It’s a non-issue. The reason this is a concept we talk about is because bits of code are similar but not the same, or they’re they same but people need them to be modifiable without risk. I don’t know about using the word “knowledge” to represent processes with dependencies that change over time, it doesn’t seem like the best terminology for this discussion. Specifically, the word “knowledge” tends to imply a timeless static quality to the code. In reality all the of issues worth discussing here, all of the problems with DRY, and all of the benefits of DRY, relate to how code changes over time. Your point about similar but not the same code being different knowledge actually kind-of illustrates exactly why merging similar bits of code is dangerous, precisely why you shouldn’t just apply DRY principles blindly, and why sometimes rejecting the idea of DRY is appropriate in a given situation.
- dgb23 3y ago
  The point that I wanted to make above is that DRY has a precise meaning and we seem to talk past each other because you use a much looser definition of DRY than I. With that loose definition we think in terms of arbitrary similarity and duplication. And I absolutely agree with you that it's dangerous to use abstraction to patch over this perceived similarity. Let's look at a trivial example of applying DRY correctly: Say we have a database schema with a column representing some URI of an entity like "person/12" which encodes ":kind/:id". It's trivially obvious that this should be a computed column, which is derived from other columns that represent the "single, unambiguous, authoritative" pieces of knowledge of these values. (It's no coincidence that DRY applies neatly to data models. The Pragmatic Programmer, which coined the term, uses data models to explain the principle as well). Really what DRY teaches us is to have a separation between authoritative knowledge and derived knowledge. Typically we're talking about data representing information here, but it can just as well be a piece of logic that is used to validate user input that you better have in just one place (think of the fun that you would have otherwise...) and so on. Of course we need derived knowledge all the time, but we want to treat that very differently. We use things like code generators, cache invalidation, materialized views, macros, temporal databases and so on in order to protect ourselves from having to coordinate derived knowledge in tandem with authoritative knowledge. And it's not just IT related. Even game programmers and compiler writers like to use DRY code in order to reduce coordinating (and growing) memory allocations, because it's often faster to compute values on the fly from a cached array, than to fetch memoized values. > I don’t know about using the word “knowledge” to represent processes with dependencies that change over time, it doesn’t seem like the best terminology for this discussion. Specifically, the word “knowledge” tends to imply a timeless static quality to the code. In reality all the of issues worth discussing here, all of the problems with DRY, and all of the benefits of DRY, relate to how code changes over time. I fully agree with the latter statement here. Thinking of how code changes over time and the implied coordination, is like a razor that we can use to determine whether some piece of code is violating actual DRY and whether we should do something about it.

by dgb23 3y ago

dahart 3y ago

Well all repeated code can evolve independently too, so by that definition, how can non-DRY code exist? This discussion is a bit too abstract and losing meaning as a result. I think you’re glossing over the very real scenarios of code (“knowledge”) that’s similar but not the exactly the same; of copies of code that are similar being merged; of code that’s exactly the same being intentionally forked and “repeated” and placed nearby; and others. Repeated code definitely can be the same piece of “knowledge” and exist in multiple places without coordination. After that the copies might drift in different directions, and the DRY dogma says this is bad. This is what people mean when they talk about DRY principles, the general idea to look for and merge similar code, and to prevent multiple pieces of similar code from being able to evolve independently. DRY in fact doesn’t really come up if two pieces of code are exactly the same; then it’s pretty obvious and easy to factor it. It’s a non-issue. The reason this is a concept we talk about is because bits of code are similar but not the same, or they’re they same but people need them to be modifiable without risk. I don’t know about using the word “knowledge” to represent processes with dependencies that change over time, it doesn’t seem like the best terminology for this discussion. Specifically, the word “knowledge” tends to imply a timeless static quality to the code. In reality all the of issues worth discussing here, all of the problems with DRY, and all of the benefits of DRY, relate to how code changes over time. Your point about similar but not the same code being different knowledge actually kind-of illustrates exactly why merging similar bits of code is dangerous, precisely why you shouldn’t just apply DRY principles blindly, and why sometimes rejecting the idea of DRY is appropriate in a given situation.

dgb23 3y ago
The point that I wanted to make above is that DRY has a precise meaning and we seem to talk past each other because you use a much looser definition of DRY than I. With that loose definition we think in terms of arbitrary similarity and duplication. And I absolutely agree with you that it's dangerous to use abstraction to patch over this perceived similarity. Let's look at a trivial example of applying DRY correctly: Say we have a database schema with a column representing some URI of an entity like "person/12" which encodes ":kind/:id". It's trivially obvious that this should be a computed column, which is derived from other columns that represent the "single, unambiguous, authoritative" pieces of knowledge of these values. (It's no coincidence that DRY applies neatly to data models. The Pragmatic Programmer, which coined the term, uses data models to explain the principle as well). Really what DRY teaches us is to have a separation between authoritative knowledge and derived knowledge. Typically we're talking about data representing information here, but it can just as well be a piece of logic that is used to validate user input that you better have in just one place (think of the fun that you would have otherwise...) and so on. Of course we need derived knowledge all the time, but we want to treat that very differently. We use things like code generators, cache invalidation, materialized views, macros, temporal databases and so on in order to protect ourselves from having to coordinate derived knowledge in tandem with authoritative knowledge. And it's not just IT related. Even game programmers and compiler writers like to use DRY code in order to reduce coordinating (and growing) memory allocations, because it's often faster to compute values on the fly from a cached array, than to fetch memoized values. > I don’t know about using the word “knowledge” to represent processes with dependencies that change over time, it doesn’t seem like the best terminology for this discussion. Specifically, the word “knowledge” tends to imply a timeless static quality to the code. In reality all the of issues worth discussing here, all of the problems with DRY, and all of the benefits of DRY, relate to how code changes over time. I fully agree with the latter statement here. Thinking of how code changes over time and the implied coordination, is like a razor that we can use to determine whether some piece of code is violating actual DRY and whether we should do something about it.