474 sats \ 1 reply \ @0260378aef 8 Dec 2023
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
0 sats \ 0 replies \ @WeAreAllSatoshi 8 Dec 2023
You make great arguments here. Deduplication done right should not forgo extensibility. The two don’t have to be mutually exclusive
reply
12 sats \ 0 replies \ @hn OP 8 Dec 2023
This link was posted by kiyanwang 1 hour ago on HN. It received 59 points and 35 comments.
reply
0 sats \ 5 replies \ @Lumor 8 Dec 2023
Agree with the sentiment but regret tipping @hn bot 1000 sats. 😅
reply
100 sats \ 4 replies \ @WeAreAllSatoshi 9 Dec 2023
Why regret?
reply
1111 sats \ 3 replies \ @Lumor 9 Dec 2023
I'd rather tip humans those amounts.
reply
300 sats \ 2 replies \ @ek 10 Dec 2023
I am the human behind @hn, but here, have your 1000 sats back :)
reply
0 sats \ 1 reply \ @Lumor 11 Dec 2023
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
0 sats \ 0 replies \ @ek 11 Dec 2023
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
0 sats \ 1 reply \ @orthzar 8 Dec 2023
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
0 sats \ 0 replies \ @orthzar 8 Dec 2023
Correction:
should be something more like this:
reply
0 sats \ 1 reply \ @Zepasta 8 Dec 2023
Interesting articule.
True.
reply
21 sats \ 0 replies \ @WeAreAllSatoshi 8 Dec 2023
It really is. I always include the original (and/or latest) author when refactoring or rewriting. It’s just common courtesy.
reply