Maybe I'm missing something but I don't get the argument that somehow this de-duplication was bad because "there proved later to be tons of special cases for each shape" etc.
That's why object hierarchies work, right? You have a Shape object with all the basics, then the exceptions that occur in e.g. Oval are isolated the Oval sub-class. Makes way more sense than having Oval just repeat all the boilerplate that's already in all the other shapes.
Deduplication matters a lot. Especially for productivity. (For example, if you repeated the same logic in 10 places, then made a patch and forgot to update 1 of the 10, it would be fine if you have a test suite that catches the error, but it sure wasted a lot of your time!).
The stuff about team work etc. sure, but that's completely orthogonal.
reply
You make great arguments here. Deduplication done right should not forgo extensibility. The two don’t have to be mutually exclusive
reply
This link was posted by kiyanwang 1 hour ago on HN. It received 59 points and 35 comments.
reply
Agree with the sentiment but regret tipping @hn bot 1000 sats. 😅
reply
Why regret?
reply
I'd rather tip humans those amounts.
reply
I am the human behind @hn, but here, have your 1000 sats back :)
reply
Have 300 back, grateful for your bots! Maybe I'll tip them a little bit in the future if it goes to their creator.
reply
It's okay, @hn made a lot more than I ever anticipated already :)
I might have to figure out what to do with these sats, would be boring to just use them for myself.
reply
Clean/dirty code wasn't the problem here. The first problem was a lack of communication before rewriting someone else's code, which the author admits.
But another problem is the use of languages that cause abstractions to increase code complexity, whereas better languages allow you to make proper abstractions that decrease code complexity.
Languages with proper object-orientation (e.g. not C++) would make proper abstractions easy to write and maintain. Such languages enable specialization of code based on either the class of the input object (in the case of Smalltalk), or based on all the arguments passed to a generic function call (in the case of Common Lisp).
Object orientation was invented for the purpose of managing complexity. [0] If your co-workers picked a language that makes managing complexity difficult (e.g. C, C++, etc), then you get to choose between (a) fighting a losing battle (i.e. the code will only get less manageable) and (b) quitting.
[0] Unfortunately, more than a few programmers seem to think OO is all about code cleanliness or, worse, encapsulation.
reply
Correction:
Such languages enable specialization of code based on either the class of the input object (in the case of Smalltalk), ...
should be something more like this:
Such languages enable specialization through polymorphism either based on inheritance (in the case of Smalltalk), or generic functions (in the case of Common Lisp).
reply
Interesting articule.
Rewriting your teammate’s code without a discussion is a huge blow
True.
reply
It really is. I always include the original (and/or latest) author when refactoring or rewriting. It’s just common courtesy.
reply