[flagged]
Prefer duplication over the wrong abstraction (2016)
331–340 of 375 posts
Re: Prefer duplication over the wrong abstraction (2016)
#332Whilst I understand cases in which duplication is preffered. I generally think abstractions are underused. Sometimes I would abstract something away that is only done once, not because i want to have less code, but because it allows me to solve bigger problems and when i look at a function I don’t have to worry about it. It allows to create systems. Obviously your abstractions should be good
Re: Prefer duplication over the wrong abstraction (2016)
#333Nobody wants to listen. Nobody. In 90% of the companies there are some so called senior devs that get ecstatic when they create a new abstraction. Overengineering, abstractions and premature optimisation are the 3 worst plagues of engineering. At the same time I’m happy they exist because it means we’ll always have a job.
There are codebases out there with enormous amounts of duplication, filled with implicit dependencies. You just haven't encountered them to appreciate good abstraction.
Re: Prefer duplication over the wrong abstraction (2016)
#334Earlier quoted context omitted.
> I believe that "single source of truth" is a principle that should always be followed Fundamentally, the article addresses cases where it's not clear yet how many sources of truth there will be. Are the two spots in the code using the same algorithm, or slightly different versions? More importantly, will they change for the same sorts of reasons? The title adage (correctly, imo) argues that making two different thi…
The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places. Accidental divergence is the problem, not intentional.
You forgot the fourth place.
Re: Prefer duplication over the wrong abstraction (2016)
#335[flagged]
Re: Prefer duplication over the wrong abstraction (2016)
#336Another way to put it:
Things that should be tightly coupled but are not is preferable to things that should not be tightly coupled but are.
I agree especially because coupling things is easier than uncoupling things.
Re: Prefer duplication over the wrong abstraction (2016)
#337Similarly, I've seen some developers who seem to think that any inline string or numeric constant is evil. In one PR, I saw: HTTPS_SCHEME = 'https' DOMAIN = 'www.example.com' url = HTTPS_SCHEME + '://' + DOMAIN I don't understand what they think this is buying, other than just cargo culting "don't embed constants." And of course, the constant definitions were at the top of the file and the url building code was hundr…
That particular example doesn't quite fit, but I've certainly seen cases where otherwise perfectly ordinary fixed strings needed to be broken up to meet linting rules.
Re: Prefer duplication over the wrong abstraction (2016)
#338Two talks come to mind here: Mike Acton's Data-Oriented Design and C++ [1] and Brian Cantrill's The Complexity of Simplicity [2]. Mike's talk argues that code solutions need not be modelled on the real world, and that different data creates different problems, which need different solutions. I can't do the talk justice, but it's had a big impact on me. Brian's talk is about abstraction generally, and how it's difficu…
this one comes to mind https://youtu.be/17KCHwOwgms
Re: Prefer duplication over the wrong abstraction (2016)
#339I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well. So code duplication because of abstraction issues is rare. Code du…
Developers do not really have to be siloed to experience code duplication. When the team size grows past a certain point such that each person is not aware of what every one else is working on, code duplication is quite inevitable. This is the case even if everyone writes functional style code. In fact this just happened last month at work: I wrote a new functional and pure helper function and placed it at the beginn…
It would be interesting to see if LLM's can scan and surface such issues. Might have been probable with parsing tools pre-LLM also? Not sure.
Re: Prefer duplication over the wrong abstraction (2016)
#340Earlier quoted context omitted.
Are ORMs still a thing? I've been away from OOP for some years now, but just when I was leaving it, there was a trend firmly against ORMs... my guess was that they were on their way out, replaced by more lightweight libs and frameworks? Or did they make a comeback? Regarding OOP itself, I also remember when "favor composition over inheritance" became a thing. Was this reversed too?
I love an ORM. I think much of the problems people experience with ORM, OOP, Restful routes, is because they get the domain model wrong. When you model the data correctly you don’t need to have complex queries that push ORM beyond their breaking point.
I think it's more complex than just about getting the domain model wrong. ORMs introduce tradeoffs and are inherently complex and full of caveats (both when deciding to use one or not), as amusingly pointed out in the much-discussed article from 2006: "[Object-Relational Mapping is] The Vietnam of Computer Science" [1]
----
[1] https://archive.is/QVPj (excuse the archive link, Ted Neward's blog seems now lost to linkrot).