writing it is not expensive. however, fixing the same bug in all the redundant reimplementations, adding the same feature to all of them, and keeping straight the minor differences between them, is expensive
Not only fixing the same bug twice, but also fixing bugs that happen because of using the same functionality in different places. For example, possible inconsistency that results from maintaining state in multiple different locations can be a nightmare, esp. in hard-to-debug systems like highly parallelized or distributed architecture.
I see "code that looks the same" being treated as "code that means the same" resulting in problems much more often than "code that means the same" being duplicated.
can you clarify your comment with some examples, because i'm not sure what you mean, even whether you intend to disagree with the parent comment or agree with it
Lets take pending orders and paid for orders as an example.
For both, there is a function to remove an order-line that looks the same. Many people would be tempted at that point, to abstract over pending and paid orders to have both reference the same function, via adding a base class of order, for example, because the code looks the same.
But for a pending order, it means removing an item from the basket, while for the paid for order, it means removing an item due to unavailability. So the code means different things.
Lets then take the system to have evolved further, where now on the paid for order some additional logic should be kicked off when an item is removed. If both pending and paid for orders reference the same function, you have to add conditionals or something, while if each has its own, they can evolve independantly.
And it definitely is disagreement with the parent comment. Sorry to have not elaborated on it in the first place.
