5 ms·

Yepp. It took me a long time to embrace the mindset that repeating things is sometimes way more elegant than unreadable abstractions. Dan Abramov's article [1]

Yepp. It took me a long time to embrace the mindset that repeating things is sometimes way more elegant than unreadable abstractions. Dan Abramov's article [1] brilliantly put into words how I feel about DRY. It's a great heuristic, but still a heuristic. https://overreacted.io/goodbye-clean-code/ https://overreacted.io/goodbye-clean-code/

colechristensen 6y ago
That is a great bit of self awareness. “This of how I changed my mind” is a narrative we all need to see more and experience more ourselves.
SomeCallMeTim 6y ago
I felt that Abramov's article showed...nothing useful at all. Yes, he found an abstraction that turned out to be not useful. But that doesn't mean there wasn't an abstraction that could have been useful. Or even that the judgment call that his exact abstraction wasn't useful was correct. DRY is important. Maybe he didn't find the right abstraction, but for the most part it's possible to refactor repetitious code with readable abstractions.
- jackconsidine 6y ago
  Yeah I generally agree with you (excepting Abramov's article being useless). > but for the most part it's possible to refactor repetitious code with readable abstractions. The operative phrase being "for the most part".
- cccc4all 6y ago
  Dan's point in that article was that he spent time doing something basically for the sake of keeping up appearances. Kind of like going through motions without achieving anything useful. It wasn't solving any problems. It's better to focus on solving problems as they rise up, as opposed to doing things to keep in line with some arbitrary standards that may not be relevant. Key is learn how to discern between trivial issues and real issues that affect the project.
  - Applejinx 6y ago
    No, it runs deeper than that. Dan came up with a really twisted, weird set of abstractions to link things that really weren't as similar as he thought they were. After he was done, you had to keep track of whether things had sides or corners and how many of those there were, something that didn't enter into how the original problems were framed. Instead of presenting 'okay, here's our resize for these respective things', his (disavowed) code began demanding how many corners your thing had. What about orientation? If you have a star, with five corners, and you can rotate it 180 degrees, what do you then call 'top left' to force that into your DRY not-repeating resize routine? Is it the bounding rect? If you've rotated the thing, is top left now bottom right or are you only concerned with the bounding rect? What if you have a non-contiguous selection so you've got two top lefts? Are they one big rect, or are you trying to resize each thing in its individual location? The point of his article was that he'd CREATED possibly significant problems through imposing an abstraction where it didn't fit. I can think of a number of new 'things' for 'resizing' that would be valid new 'things' with intitutively sensible behaviors that would violate any enclosing abstraction he might have produced, especially the one he offered as a 'bad example' where sides are conflated with corners and so on. He's right to have realized he was on the wrong path.
cooervo 6y ago
I'm not a big fan of Angular, but in their style guide they talk about Try to be DRY. And I think they explain it better than Dan: https://angular.io/guide/styleguide#t-dry-try-to-be-dry https://angular.io/guide/styleguide#t-dry-try-to-be-dry > Do be DRY (Don't Repeat Yourself). > Avoid being so DRY that you sacrifice readability.
- flukus 6y ago
  The problem is DRY almost always improves readability, at least with well named functions. It reduces comprehensibility, so much of the logic is abstracted away that the bigger picture can't be seen from the inside or outside of the abstraction.

colechristensen 6y ago

That is a great bit of self awareness. “This of how I changed my mind” is a narrative we all need to see more and experience more ourselves.

SomeCallMeTim 6y ago

I felt that Abramov's article showed...nothing useful at all. Yes, he found an abstraction that turned out to be not useful. But that doesn't mean there wasn't an abstraction that could have been useful. Or even that the judgment call that his exact abstraction wasn't useful was correct. DRY is important. Maybe he didn't find the right abstraction, but for the most part it's possible to refactor repetitious code with readable abstractions.

jackconsidine 6y ago
Yeah I generally agree with you (excepting Abramov's article being useless). > but for the most part it's possible to refactor repetitious code with readable abstractions. The operative phrase being "for the most part".
cccc4all 6y ago
Dan's point in that article was that he spent time doing something basically for the sake of keeping up appearances. Kind of like going through motions without achieving anything useful. It wasn't solving any problems. It's better to focus on solving problems as they rise up, as opposed to doing things to keep in line with some arbitrary standards that may not be relevant. Key is learn how to discern between trivial issues and real issues that affect the project.
- Applejinx 6y ago
  No, it runs deeper than that. Dan came up with a really twisted, weird set of abstractions to link things that really weren't as similar as he thought they were. After he was done, you had to keep track of whether things had sides or corners and how many of those there were, something that didn't enter into how the original problems were framed. Instead of presenting 'okay, here's our resize for these respective things', his (disavowed) code began demanding how many corners your thing had. What about orientation? If you have a star, with five corners, and you can rotate it 180 degrees, what do you then call 'top left' to force that into your DRY not-repeating resize routine? Is it the bounding rect? If you've rotated the thing, is top left now bottom right or are you only concerned with the bounding rect? What if you have a non-contiguous selection so you've got two top lefts? Are they one big rect, or are you trying to resize each thing in its individual location? The point of his article was that he'd CREATED possibly significant problems through imposing an abstraction where it didn't fit. I can think of a number of new 'things' for 'resizing' that would be valid new 'things' with intitutively sensible behaviors that would violate any enclosing abstraction he might have produced, especially the one he offered as a 'bad example' where sides are conflated with corners and so on. He's right to have realized he was on the wrong path.

cooervo 6y ago

I'm not a big fan of Angular, but in their style guide they talk about Try to be DRY. And I think they explain it better than Dan: https://angular.io/guide/styleguide#t-dry-try-to-be-dry https://angular.io/guide/styleguide#t-dry-try-to-be-dry > Do be DRY (Don't Repeat Yourself). > Avoid being so DRY that you sacrifice readability.

flukus 6y ago
The problem is DRY almost always improves readability, at least with well named functions. It reduces comprehensibility, so much of the logic is abstracted away that the bigger picture can't be seen from the inside or outside of the abstraction.