Of course, as you said it's "wrong abstraction".
The real problem is it's hard to tell if an abstraction is correct before you see enough duplication.
Prefer duplication over the wrong abstraction (2016)
311–320 of 375 posts
Re: Prefer duplication over the wrong abstraction (2016)
#312Earlier quoted context omitted.
> 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've always found it odd when even fairly smart engineers sometimes prioritize real-world metaphors over the actual needs of the codebase. Years ago when I was only a few years out of school, I was implementing a connection pool in Rust, and the most reas…
This is somewhat related: I mention this a lot, but in researching Data-Oriented Design (what Mike was talking about), I came across Richard Fabian's DoD book [1] which talks a lot about database normalization and the like. I found that odd, because the low-level high-performance game code he was talking about certainly wasn't going to marshal data into a DB to run SQL queries on it. It turns out the relational model…
> My big issue is that doing DB-like operations is hellish in most programming languages, and if you really want to try and marshal your data into a real DB (say, SQLite or DuckDB via a library), then you have a big messy translation layer where you're trying to match things to SQL types and you have giant SQL strings everywhere.
I prefer having that translation layer especially when it's domain oriented. All the sql strings are collected in one isolated module, and the only exported symbols is a set of functions.
From Domain-Driven Design, what I learned is to be comfortable having different representation of the same data in different layers/subdomains. Something may be a fat object from the API, but I prefer having a collection of functions that each use a different part and have a caching layer to not actually do the expensive network call. That network call and the caching layer will be encapsulated in one module and the collection of functions will be the only thing visible.
Re: Prefer duplication over the wrong abstraction (2016)
#313Nobody 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.
The part that no one want to say out loud: Making boring technology decisions makes you job boring and does not help to build your resume. This is the core reason why over-engineering exists.
Making the job boring is a great way to get free time to browse HN.
Re: Prefer duplication over the wrong abstraction (2016)
#314AI: Why not both?
Re: Prefer duplication over the wrong abstraction (2016)
#315Of course, as you said it's "wrong abstraction". The real problem is it's hard to tell if an abstraction is correct before you see enough duplication.
That's exactly what the article is about.
Re: Prefer duplication over the wrong abstraction (2016)
#316Similarly, 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…
I’m a big fan of closeness in code. I prefer defining things as closely to where it’s used as possible. This is a big pet peeve for me! Do not put regex at the top of the file either! Put it where you use it. Languages are smart, they’ll probably be able to tell that it’s constant anyway. Also for tiny functions just use a lambda. Please don’t make a one line function a million miles away that you use once or twice.
If multiple things use the same regex, which one should it be close to? Or do you propose duplicating it?
Re: Prefer duplication over the wrong abstraction (2016)
#317[deleted]
Re: Prefer duplication over the wrong abstraction (2016)
#318Earlier quoted context omitted.
Hardly iconoclastic, it's a very sensible suggestion. It would be iconoclastic if the common sense basic approach would be to start with abstraction. It's not, the common sense default is to write possibly duplicate behavior until you actually discover several cases to abstract away, until you bevalop a sensible idea of which functionality unites them and which doesn't carry over all of them. > Once you have an awkwa…
> Maintaining the wrong abstraction, or, god help, abstractions, would be even worse. Hard disagree. When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too. A bad abstraction would at least have had one fire in one place.
> When you've had to chase through a change in untold and actually unknown numbers of duplications of code in different permutations and fix them because they are all on fire simultaneously, you'd disagree too
Doesn't it mean that you are in a good place to start DRYing code? I mean, code was written in a way to avoid bad abstractions. You can't generalize on 1-2 samples, but now you have "unknown numbers" (more than two?), so you can start looking at it an see patterns. It means you can create a perfect abstraction. It is the basis of the WET (Write Everything Twice) principle.
It would be frustrating, and I mean really frustrating. People are easily generalize over two things but they struggle to generalize over three. Pick two random words and think of a common category they fall into. It is an easy task for 5 years old. Pick three random words and try to generalize them, you would have a very hard cognitive task.
This frustration stems from the inherent complexity of the task. It is not because people before you wrote duplicating code, it is because it is hard to generalize. People before you didn't do it being afraid of missing things and creating a bad abstraction, but you have hard data, you can create an abstraction without missing a thing.
Re: Prefer duplication over the wrong abstraction (2016)
#319[flagged]
Re: Prefer duplication over the wrong abstraction (2016)
#320Sandi is amazing. I learned so much from her.