Hacker News Reader

Comment by jackconsidine | Hacker News Reader

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/

View on HN

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

> Do be DRY (Don't Repeat Yourself).

> Avoid being so DRY that you sacrifice readability.

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.

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.

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".

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.

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.

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.

Reply on news.ycombinator.com