3 ms·
I would say that the article simply states the obvious: bad abstractions are bad, but for some reason that I'm missing tries to derive from there that copy and
by tigershark 10y ago
I would say that the article simply states the obvious: bad abstractions are bad, but for some reason that I'm missing tries to derive from there that copy and paste sometimes is good.
And the quoted comments persist in the same illogical path.
Saying that bad abstractions are a bad thing and then copy and paste must be a good thing in some cases is simply a non sequitur.
There is no whatsoever correlations between the two statements.
And if you want to know my opinion, blind copy and paste is always bad.
Especially in codebases over 1MLOC.
Those bugs that you have to fix multiple times in multiple places will kill yourself and, believe me, you will really curse whoever thought that doing a copy and paste was a good idea simply because they couldn't see a better solution.
These kind of trends in HN, that now I'm seeing more often, make me terribly sad, it's like promoting mediocrity instead of a well thought solution just because of laziness.
If you can't understand some abstraction then try harder, or if the abstraction is not good then find a better solution.
But PLEASE don't start to copy and paste and above all don't start promoting this abomination.
Source: I wrote a lot of copy and paste when I was too young to understand and I had to read too many copy and paste when I stopped doing it.
- stcredzero 10y agoSaying that bad abstractions are a bad thing and then copy and paste must be a good thing in some cases is simply a non sequitur. What happens when you are under deadline and you understand just enough to make a bad abstraction, but not enough to make a good abstraction? So here, you seem to have an underlying assumption of timeless omniscience. (This is common in people attracted to absolutes and abstractions.) By all means, if you have the time to make the right abstraction and DRY, then please do that. However, it's just as fallacious to suppose that any DRY abstraction is necessarily the right thing to do. Again, it's all about contextual cost/benefit. (Most of the time, it is the right thing to do, but this certainly isn't absolute.) To be more specific, what if you have an abstraction that lets you do DRY, but it's obtuse, it looks like it's not quite the right answer, and it would involve the modification of a library that is used by many other parts of the system for which you don't have tests? Are you certain that in all cases like this, the cost/benefit of not having to do the search in your code next week is going to be worth it?
- tigershark 10y agoYour case is not in favour of duplication, it is in favour of temporary duplication because of a deadline. So I think that you agree with me that duplications is always bad, because you can justify writing whatever abomination close to a deadline, not only duplication. But if you leave untouched that mess in the future then sooner or later it will bite your ass.