3 ms·

The main point here is worth a broader discussion. Part of the problem is that we tend to hide behind mental concepts that a ambiguous, incomplete or just bad.

by vast 7y ago

The main point here is worth a broader discussion. Part of the problem is that we tend to hide behind mental concepts that a ambiguous, incomplete or just bad. DRY is a awful "thing" (a decree at best). In the worst interpretation it simply says "never write the same code twice". There is no balance or end to it. It doesn't have a competitor or alternative. It somewhat implies that it is always good. It doesn't define a scope where/when it should be applied. There is simply no broad agreement how to use it in practice. DRY touches multiple concepts, each too complex to put behind three tiny letters. OP fails to make a great point, but the direction is right. We cannot take DRY and "code reuse" laws as granted. Abstractions and indirections have their downsides. It increases systemic complexity and may add dependencies. It certainly limits how easy the full system can be understood by humans.

AstralStorm 7y ago
The alternative to DRY is... Repeating yourself. Which is fine once or thrice but not too many times. Second alternative is code generation, which brings its own problems, but is relatively clean. (Custom build systems are a pain.) You have to keep balance to not turn the code into some DSL for example. Then you can also do macros, especially if the language has a decent enough support. (In C++ the equivalent is not C macros but templates and RAII pattern.) And finally, you do not need to move code out to necessarily reuse it all the time, or even make it public. Things that work together best stay together, and strengthen encapsulation.
tetha 7y ago
The counterpoint to DRY doesn't seem to have a name, but it very much exists. I know it under the names of 'oversharing' or 'premature sharing'. Practically, this tends to extend the question of DRY: Is the code the same in two places, and will the code /change/ in the same way in these two places? Can we delay sharing this code to have more time to figure out if the code changes in the same way? Maybe currently two integrations with two external applications are just the usual socket/newline separated json at the moment, so you could share the implementation. But maybe one integration gets replaced with thrift, one gets replaced with protobuf and suddenly you end up with an abstraction that's full of <if service.protobuf...> and that'll be ugly.

by vast 7y ago

AstralStorm 7y ago

The alternative to DRY is... Repeating yourself. Which is fine once or thrice but not too many times. Second alternative is code generation, which brings its own problems, but is relatively clean. (Custom build systems are a pain.) You have to keep balance to not turn the code into some DSL for example. Then you can also do macros, especially if the language has a decent enough support. (In C++ the equivalent is not C macros but templates and RAII pattern.) And finally, you do not need to move code out to necessarily reuse it all the time, or even make it public. Things that work together best stay together, and strengthen encapsulation.

tetha 7y ago

The counterpoint to DRY doesn't seem to have a name, but it very much exists. I know it under the names of 'oversharing' or 'premature sharing'. Practically, this tends to extend the question of DRY: Is the code the same in two places, and will the code /change/ in the same way in these two places? Can we delay sharing this code to have more time to figure out if the code changes in the same way? Maybe currently two integrations with two external applications are just the usual socket/newline separated json at the moment, so you could share the implementation. But maybe one integration gets replaced with thrift, one gets replaced with protobuf and suddenly you end up with an abstraction that's full of <if service.protobuf...> and that'll be ugly.