3 ms·

> Nothing clever, nothing coupled Yes, simple is good. Simple is not always easy though. A good goal to strive for nevertheless. > nothing DRY That's interes

by tasuki 3y ago

> Nothing clever, nothing coupled Yes, simple is good. Simple is not always easy though. A good goal to strive for nevertheless. > nothing DRY That's interesting. Would you prefer all the code to be repeated in multiple places?

f1shy 3y ago
Bit OP but probably means “no fancy silver bullet acronyms”.
dclowd9901 3y ago
Depends. I haven’t come up with the rubric yet but it’s something like “don't abstract out functionality across data types”. I see this all the time: “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” Invariably it ends up collapsing, and if the whole program is constructed this way, it becomes monstrous to untangle, like exponentially complicated on the order of abstractions. I think it’s just a breathtaking misunderstanding of what DRY means. It’s not literally “don’t repeat yourself”. It’s “encapsulate behaviors that you need to synchronize.” Also, limit your abstractions’ external knowledge to zero.
- tasuki 3y ago
  Very good explanation! > “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” I'm guilty of this. I even fought hard against the people who wanted to keep the code duplicated for the different data types. > “encapsulate behaviors that you need to synchronize.” I like that!
manicennui 3y ago
The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.
- dclowd9901 3y ago
  Yep, exactly. I went into further detail in another comment.

by tasuki 3y ago

f1shy 3y ago

Bit OP but probably means “no fancy silver bullet acronyms”.

dclowd9901 3y ago

Depends. I haven’t come up with the rubric yet but it’s something like “don't abstract out functionality across data types”. I see this all the time: “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” Invariably it ends up collapsing, and if the whole program is constructed this way, it becomes monstrous to untangle, like exponentially complicated on the order of abstractions. I think it’s just a breathtaking misunderstanding of what DRY means. It’s not literally “don’t repeat yourself”. It’s “encapsulate behaviors that you need to synchronize.” Also, limit your abstractions’ external knowledge to zero.

tasuki 3y ago
Very good explanation! > “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” I'm guilty of this. I even fought hard against the people who wanted to keep the code duplicated for the different data types. > “encapsulate behaviors that you need to synchronize.” I like that!

manicennui 3y ago

The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.

dclowd9901 3y ago
Yep, exactly. I went into further detail in another comment.