> The lesson is "goodbye to over-applying a rule without considering context-specific trade-offs",
I think the problem is the rule itself. A rule of thumb is fundamentally broken if it does more harm than good. The heuristics to drive a decision need to lead the developer to a good outcome if they apply it without overthinking things or have meetings, because that's what rules of thumb are for.
Time and again developers tie codebases into contrived knots by mindlessly repeating the mantra "duplicate code is bad code" because they fail to realize that code that looks the same is not the same code at all, and sometimes should not be the same code at all for a number of reasons. Developers need to think hard about whether a refactorization helps simplify a project, and shoving code sections into multiple unrelated code paths is surely a way to do the exact opposite. Moreso when a mastermind developer opts to add conditionals to force similar code blocks to fit other code paths.
> Some newer languages don't even deal in classes at all (Rust for example) and with good reason. If one says we need classes for having objects—No we don't.
That's specious reasoning at best.
A class basically means a way to specify types that track specific states and behavior. Afterwards this materializes in other traits like interfaces and information-hiding.
Don't tell me Rust does not support those.
Also, C++ precedes Rust and it supports free functions and objects without member functions from day one. Rust is hardly relevant or unique in this regard. What Rust supports or not is not progress, nor is the definition of progress whatever Rust supports.
> And objects are a concept to manage state over the lifetime of what the object represents, so that might be a worthy concept, but a class?
You're showing some ignorance here. Classes and objects are entirely different concepts. An object is an instance of a class. A class is a blueprint of an object. This is programming 101.
> But I find it hard to believe that among those 10 lines of maths each, there aren't any functions one can extract that form some natural abstraction (e.g. "translate vector" or whatever), so that every handle function ends up being maybe 1 or 2 lines instead of 10.
That's besides the point, isn't it? Just because you can in theory extract functions that doesn't mean you should, or that your codebase will be in a better shape if you do. There's the issue of coupling, and there's the issue of introducing dependencies, and there's the issue of whether the apparent duplication holds the same semantics and behavior across the project. I'm talking about things like does it make sense to change the behavior on all 10 code paths if you need to change it in only two or three? Having a surface-level similarity between code blocks doesn't make them the same behavior, does it?
If you're translating vectors 10 times, or calculating cosines, or whatever, then yes, you should abstract this into separate functions. It's not like "translateVector" or "calculateCosine" are brittle abstractions or anything.
> Piracy isn't exactly a zero-sum game, but there is a cost associated with it.
There is zero cost associated with piracy. Zero.
At best, there's an expectation of profit that's not met. To argue that, you need to show how copying a file translates to a potential sale being converted to a no-sale, and there are plenty of evidence that unauthorized distribution of copyrighted work drives demand up.
> Pretending piracy doesn't hurt revenue is a shaky ground to stand on
Go ahead and show exactly where copying a file hurts anyone. You're trying to pass off your personal assertions as axioms, but it's on you to prove that copying a file without the consent of someone hurts anyone.
Go ahead.
> now whatever it hurts the artists revenue is a different question
If anything, artists are the least impacted counterpart as they literally get paid a small fraction of the whole income.
At all the public libraries I've used they only let me checkout something if the total number of copies already checked out is less than the number of copies the library has licenses for. If the number checked out is not under the number of licenses they make me wait until one of the checked out copies is returned.
That's still no different from the content creator's point of view than a non-sale or pirate. The practical limitations of libraries is immaterial to the fact I can view content without paying the creator anything. Carving out some logical exception for content pirates is ludicrous. They're functionally no different than non-customers or library patrons.
The physical limitations of libraries are immaterial. Patrons are non-customers of the content publisher. They're doing the same exact thing pirates are doing, experiencing some piece of content without paying the original publisher. The same thing as if they watched a movie on broadcast TV, listened to the radio, or bought that content second hand.
If you're going to argue against piracy you're also arguing against libraries. The differences between a pirate and a library are mostly statutory.
> However, Musk has recently addressed his distaste for unions, saying in New York last week: “I disagree with the idea of unions. I just don’t like anything which creates a lords and peasants sort of thing. I think the unions naturally try to create negativity in a company.”
> Reusing a function C in functions A and B makes A and B dependent on C. If the definition of C changes, the definitions of A and B also change.
To pile onto this example, in some cases the mastermind behind these blind deduplication changes doesn't notice that the somewhat similar code blocks reside in entirely different modules. Refactoring these code blocks into a shared function ends up introducing a build time dependency where previously there was none, and as a result at best your project takes longer to build because independent modules are now directly dependent or at worsr you just introduced cyclic dependencies.
> Removing duplication is the introduction of a dependency. If this dependency is a good model of the problem then this deduplication is a good abstraction and may also be a simplification. Otherwise it's just compression in the guise of abstraction.
I think you're referring to coupling. Deduplicating code ends up coupling together code paths that are entirely unrelated, which ends up increasing the complexity of an implementation and increase the cognitive load required to interpret it.
This problem is further compounded when duplicate code is extracted to abstract and concrete classes instantiated by some factory, because some mastermind had to add a conditional to deduplicate code and they read somewhere that conditionals are for chumps and strategy patterns are cleaner.
Everyone parrots the "Don't Repeat Yourself" (DRY) rule of thumb and mindlessly claim duplicate code is bad, but those who endure the problems introduced by the DRY principle ended up coining the Write Everything Twice (WET) rule of thumb to mitigate those problems for good reasons. I lost count of all the shit-tier technical debt I had to endure because some mastermind saw two code blocks resembling the same shape and decided to extract a factory with a state patter turning two code blocks into 5 classes. Brilliant work don't repeating yourself. It just required 3 times the code and 5 times the unit tests. Brilliant tradeoff.
Yeah, this is the crux of it. What exactly is duplicated code? Humans are pattern matching machines, we see rabbits in the clouds. Squint at any 4 lines of code and something might look duplicated.
On the other hand, code bases that do have true duplication (100s of lines that are duplicated, large blocks of code that are exactly duplicated 16 different times), multiple places & ways to interact with database at differing layers - that's all not fun either.
It is a balance & trade-off, it goes bad at either extreme. Further, there is a level of experience and knowledge that needs to be had to know what exactly is a "duplicate block of code" (say something that pulls the same data out of database and does the same transform on it, is 20 lines long and is in 2, 3 or more places) vs things that just look similar (rabbits in the clouds, they are all rabbits).
> Deduplicating code ends up coupling together code paths that are entirely unrelated, which ends up increasing the complexity
Code paths that may be unrelated. If they are related, then deduplicating is most definitely a good idea. If they're trying to do the same thing, it makes sense that they call the same function to do it. If they do completely different things that currently happen to involve some of the same lines of code, but they could become different in the future, then deduplication makes no sense.
I'm going off on a tangent here, but whenever I read about progress in dentistry I always get the feeling they are just sugarcoating medieval practices. In an era where mankind routinely flies people into space, the primary tools leveraged by orthodontists is still drilling and pulling teeth, and teeth replacement is still implemented as lodging metal spikes onto the jawbone. It sounds like the only progress that we had since the 17th century is clever ways to numb pain and how finer materials ended up replacing wood for dental prosthetics.
"In an era where mankind routinely flies people into space ... replacement is still implemented as lodging metal spikes"
Osseo-integration of titanium was first observed in the 1940s, so the technology for modern dental implants is approximately of the same age as space rockets. (Wernher von Braun designed the first A4/V2 at almost precisely the same time.)
> With good hygiene and dental checkups twice a year, you can reasonably expect to avoid cavities altogether.
Your comment is self-contradicting. The only thing that dental checkups do is allow cavities to be flagged before they progress very far.
Also, I feel that in this context "good hygiene" is a weasel word, in the sense that implies that any occurrence of a cavity can only be explained by the absence of good hygiene. There are many factors to cavities that aren't addressed by hygiene, such as vulnerable teeth and cavity types such as root cavities, whose primary risk factor is decreased salivary flow.
I think the problem is the rule itself. A rule of thumb is fundamentally broken if it does more harm than good. The heuristics to drive a decision need to lead the developer to a good outcome if they apply it without overthinking things or have meetings, because that's what rules of thumb are for.
Time and again developers tie codebases into contrived knots by mindlessly repeating the mantra "duplicate code is bad code" because they fail to realize that code that looks the same is not the same code at all, and sometimes should not be the same code at all for a number of reasons. Developers need to think hard about whether a refactorization helps simplify a project, and shoving code sections into multiple unrelated code paths is surely a way to do the exact opposite. Moreso when a mastermind developer opts to add conditionals to force similar code blocks to fit other code paths.