Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prefer duplication over the wrong abstraction (2016)

sandimetz.com

Post reply on HN
Print view View original

171–180 of 375 posts

Re: Prefer duplication over the wrong abstraction (2016)

#171

Post by svieira »

cjfd wrote: post #157
coldtea wrote: post #143

Earlier quoted context omitted.

Duplication is just code doing the same thing in several places, and as such it's much easier to make DRY (and much easier after you have N copies to see what should be shared and what should not), compared to re-architecting the whole system to remove a bad abstraction.

No. The duplication is seldomly that clean. It has started to diverge in subtle ways where the question becomes whether that was the intention or not. In the worst possible cases it has resulted in 8000-line functions full of duplication. 're-architecting the whole system to remove a bad abstraction' sounds fear mongering. That never happens.

Ah contraire, mon ami, I am currently in the process of doing just that in many places in my current codebase.

Re: Prefer duplication over the wrong abstraction (2016)

#172

Post by anygivnthursday »

dofm wrote: post #63
coldtea wrote: post #47

Earlier 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.

Both are bad, what you describe is very real, but so is the opposite. That one fire in one place can end up in a total rewrite of numerous layers because the abstraction never anticipated certain things to happen.

Re: Prefer duplication over the wrong abstraction (2016)

#174

Post by baublet »

irishloop wrote: post #51

Too many abstractions are bad. Too many code duplication is bad. Part of being a good engineer is finding the right balance. I know engineers who would gladly duplicate code all over the code base to avoid creating a new abstraction. I know engineers who create polymorphic abstractions for a single caller with a very obvious set of parameters. So much of wisdom is in finding balance and not being dogmatic about rules…

The most difficult codebases are those with every little thing some bespoke abstraction that went through 3 rounds of committee reviews that results in having to click through 12 files to figure out what anything is doing. Factory factory factories each with their own little frankenframework to understand before using anything.

Re: Prefer duplication over the wrong abstraction (2016)

#175

Post by stcg »

This is like saying "A slow leak is cheaper than a burst pipe"

Yes, okay. But with both you will have a bad time cleaning up.

There is a third option: good abstractions.

I did see this pattern described in the blog in practice a lot (and fell victim to it myself) and I think that in general this comes down to inexperienced programmers. Object oriented programming makes it worse.

Teaching these programmers that they should not abstract is not the solution. It is blocking their growth.

Teach them how to make better interfaces instead.

Re: Prefer duplication over the wrong abstraction (2016)

#176

Post by bogrollben »

One thing I don't see talked about often is the fact that not all duplication is equal. Duplicated html/xml/markup does not equal template-based boiler plate, which does not equal almost everything else. I'm far more forgiving of duplicate html/markup because that code is so cheap.

Re: Prefer duplication over the wrong abstraction (2016)

#177

Post by Rendello »

saghm wrote: post #76
Rendello wrote: post #36

Two 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…

> 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 has a lot of advantages though. Programmers use trees all the time, in OO, in structs containing structs, in objects pointing to other objects. It's easy to forget that trees are just a special case of graphs (ie. networks), and that there are many ways to represent networks that don't rely on encoding a tree structure directly.

So, I've been doing what Richard Fabian suggested and I lay out my data (on paper) into tables, then attempt to normalize it and see the connections. I really like this way of designing things.

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 see C# has LINQ, which is a query languages embedded in the language. I wonder if that approach is best, and why hasn't it been adopted more broadly? It seems like there's a lot for programming language designers to explore in this dimension, though I wonder if it even matters now with the superintelligence tidal wave.

1. https://www.dataorienteddesign.com/dodmain/

Re: Prefer duplication over the wrong abstraction (2016)

#178

Post by dang »

stcg wrote: post #175

This is like saying "A slow leak is cheaper than a burst pipe" Yes, okay. But with both you will have a bad time cleaning up. There is a third option: good abstractions. I did see this pattern described in the blog in practice a lot (and fell victim to it myself) and I think that in general this comes down to inexperienced programmers. Object oriented programming makes it worse. Teaching these programmers that they s…

The OP is aware of good abstractions and is describing a procedure for finding them, or for increasing one's chances of finding them.

Re: Prefer duplication over the wrong abstraction (2016)

#179

Post by dimgl »

agentifysh wrote: post #10

i recall very early in my career i did exactly this. i took what worked duplicated it—my reasoning being that it was far safer to reuse what has been battle tested and leave refactoring at a later stage it wasn't received well and senior developer told me that 'good developers know exactly what patterns to use all the time before writing any piece of code and that he will clean up my mess' long story short his refact…

> long story short his refactoring caused what was otherwise a stable system into a complete mess

Yeah that totally happened

Re: Prefer duplication over the wrong abstraction (2016)

#180

Post by alkhimey »

The disadvantages of duplication are greatly reduced in the world of AI. From my experience it can easily detect the duplicates and refactor code safely. On the other hand, code without abstractions is easier to read and easier for AI.

With AI, we really need to rethink the clean code principles.

Post reply on HN