Firstly, there is no such things as perfect abstractions, hence the The Law of Leaky Abstractions. Secondly, without abstraction we would be writing in machine code. So unless the authors enlightens us on what makes an abstraction wrong the whole discussion is a waste of time.
The Wrong Abstraction
61–70 of 121 posts
Re: The Wrong Abstraction
#62False dichotomy. You can avoid code duplications while using the "right" abstractions.
Re: The Wrong Abstraction
#63I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. This writer is pointing out that there are other concerns that far, far trump duplicated code -- and she's right. However she's not elaborating enough…
Off the top of my head, there are two reasons people seem to de-duplicate code. One is because two or more things happen to share similar code. Another reason is because two or more things must share similar code.
It seems like you are speaking of the first reason. There is no dependency, and the programmer is creating one. IMHO you should have at least 3 instances before creating an abstraction to reduce your code.
The second reason is different though. By creating the abstraction you are not adding a dependency, you are making an implicit dependency explicit. There is a huge difference. In this instance any duplicate code is bad.
Re: The Wrong Abstraction
#64"Programmer B feels honor-bound to retain the existing abstraction" I think it's more often likely that the next person comes along and lazily forces the most brittle, minimal change possible to make their new requirement work without thinking about the larger context. Even if that means putting a complicated conditional into the existing function, while leaving the existing function name intact. This isn't about hon…
Or maybe programmer B is trying to maintain a monolith of pasta for which there is no documentation, the original programmer has long since left the company, no one is entirely sure what the business rules of the program are actually supposed to be, there are no tests, and you don't have time to actually read and understand all 100k lines of code.
Management just needs this one little feature tweaked, so you dive in to where you think that needs to go, make the new thing happen while absolutely changing as little as possible because god help us if anything breaks.
Now imagine that you're not the second or third person to be responsible for this, but maybe the tenth or so, and it's been going on for decades. And the last person to work on it was really new to this language and didn't understand its idioms very well, or vice Versace, and you don't understand the language very well.
I greatly enjoy these conversations about code quality and maintainability, but I've encountered it more than once where business constraints don't allow you to even start to think about these issues. You have no choice but to respect the abstraction you inherit because your job is to get in, get out, and pray you didn't break some edge case that no one would ever think of.
Or maybe I'm just an amateur/novice.
Re: The Wrong Abstraction
#65I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. This writer is pointing out that there are other concerns that far, far trump duplicated code -- and she's right. However she's not elaborating enough…
I understand and sympathize with the idea you suggest here, but I also wonder about the fine tuning. We accept that both duplication and dependency are bad (and certainly that the minimal, maximally stable dependency set is best) but when making that tradeoff what parameters make a duplications better or worse than a dependency? Are there languages or toolchains which cause this tradeoff to fall in the opposite direc…
>when making that tradeoff what parameters make a duplications better or worse than a dependency?
This depends entirely upon the context. Overduplication and tight coupling are universally bad but the trade off between them is often a matter of opinion.
In practice I've found that once you've hit the point where you're trying to trade duplication + tight coupling off against one another the code is already in a decent enough state that there's other more important work to be done.
Re: The Wrong Abstraction
#66The same applies to dependencies. I've grown very reluctant towards introducing a dependency for the sake of deduplication. I'd rather have isolated modules than a de-duplicated Big Ball of Mud.
Re: The Wrong Abstraction
#67It's funny how often I've made this argument with even fairly experienced programmers and they seem to have a visceral reaction to the code being "less dry" than it could possibly be.
Similarly, once a codebase uses several very wrong abstractions, it becomes significantly more confusing to work on, exponentially increasing cost.
The temptation to use a mature library as a dependency is very strong since time is initially saved. When that library introduces the wrong abstraction, the consequences can be severe.
I typically argue for (at least) creating the correct abstraction and having it wrap the mature library to constrain or properly name its behavior, and to make it less strongly coupled to the rest of the system.
It doesn't just take experience to realize these sorts of things, it takes a willingness to question one's own code and imagine how it might have been done better, or how it might appear to someone who didn't write it.
Re: The Wrong Abstraction
#68False dichotomy. You can avoid code duplications while using the "right" abstractions.
expand?
Re: The Wrong Abstraction
#69I'm reminded off ESR's "curse of the gifted" email, schooling Linus Torvalds on the lack of modularization and code-sharing in Linux's driver code. :)
Re: The Wrong Abstraction
#70I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. This writer is pointing out that there are other concerns that far, far trump duplicated code -- and she's right. However she's not elaborating enough…
I can tell an amateur programmer because they aren't getting paid. Flippancy aside though:
While I don't think it's what you're arguing for, I'd fear some would use an argument like this to defend a workflow and culture where new features are started by copy and pasting a mass of code, and then going in and tweaking little things here and there. Then when something has to change across the system, there are endless traps because things you need to change and maintain, that look identical, aren't quite. These workflows and cultures exist.
There's a balance somewhere and finding that is the hard part, right?