Live data from Hacker News

The Wrong Abstraction (2016)

sandimetz.com

11–18 of 18 posts

Re: The Wrong Abstraction (2016)

#11
post #6

Earlier quoted context omitted.

> For example, the way signed and unsigned numbers are defined in the C standard What do you mean?

Presumably something like the representation of signed numbers being implementation defined (instead of two's complement as is virtually always the case nowadays).

I know this doesn't address the point about the C standard itself, but:

• GCC and Clang both accept the -fwrapv argument, causing the compiler to guarantee that signed overflow will wrap, like in Java

• The latest C++ standard mandates that signed integer types use two's complement representation (signed overflow remains undefined behaviour)

Re: The Wrong Abstraction (2016)

#12
I recently wrote a post about the problem with naming things (https://itnext.io/and-naming-things-tailwind-css-typescript-...), but this post points out that not only is that the case -- once an abstraction has been introduced, it's hard to get rid of simply because removing them intuitively feels like a step backwards. Very good point!

Re: The Wrong Abstraction (2016)

#13
Some past threads:

The Wrong Abstraction (2016) - https://news.ycombinator.com/item?id=23739596 - July 2020 (240 comments)

The Wrong Abstraction (2016) - https://news.ycombinator.com/item?id=17578714 - July 2018 (207 comments)

The Wrong Abstraction - https://news.ycombinator.com/item?id=11032296 - Feb 2016 (119 comments)

Recovering from the wrong abstraction (2014) - https://news.ycombinator.com/item?id=10127289 - Aug 2015 (11 comments)

Re: The Wrong Abstraction (2016)

#17

One of my all-time favorite HN comments is from the original discussion of this article: > Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to ma…

I love this a lot and am saving it to my Roam notes for later reference ♥

Re: The Wrong Abstraction (2016)

#18
I think this sort of mis-identifies the problem: the problem isn’t the wrong abstraction, it’s that later programmers don’t feel free to refactor to a better abstraction. Especially in languages with good refactoring tools (I.e. Java), inlining and refactoring is a much lower cost than the long-term maintenance cost of duplication.
Post reply on HN