Comment by FullyFunctional | Hacker News Reader

Comment by FullyFunctional | Hacker News Reader

Parent Full thread

FullyFunctional

That was a really interesting article. I completely agree with

>>> Abstractions may make things easier to extend in the future, or guard against certain types of errors, but they need to be considered against the fact that you may end up with 3 times the amount of code to understand and refactor, 3 times the amount of possible locations for bugs and less time left to spend on testing and further development.

Choosing when and how to abstract is key. Abstraction in a fashion extends the language so you are trading off a burden on the reader (who have to learn and trust the abstraction) for increased expressiveness. Don't overdo it. (And don't abstract idioms).

Could you clarify what you mean by "don't abstract idioms?"

One example (taken from the real world):

   addr = (addr + PAGESIZE - 1) & ~PAGESIZE;

contrast with

   addr = P2ALIGN(addr);

The former is idiomatic and immediately readable. For the latter I have to go lookup the definition of P2ALIGN (and make sure I got the one actually used as there may be multiple!), check that it does what I expect, and memorize it.

The value of abstracting the idiom is debatable. If it _is_ used sufficiently often, then it might be worthwhile, but often it isn't.

I think thinking carefully about the abstractions is also key, ideally not while at the computer. Good abstractions should be obvious and not really requiring refactoring as per se.

Reply on news.ycombinator.com