
Datastructure APIs in C++ - ingve
https://www.randygaul.net/2020/02/01/datastructure-apis-in-c/
======
ncmncm
It is hard to express how fundamentally wrong the author is, in his definition
of abstraction overhead, and his criteria for sound implementation practice.

The term "abstraction overhead" is already defined rigorously as the
difference between the runtime performance of handwritten pre-specialized
code, vs code that uses a more general abstraction.

So we don't have a proper term for what the author objects to, but avoiding
powerful language features -- most particularly, destructors -- would be a
huge step backward.

Most of us don't get the luxury of discarding a system and rewriting from
scratch. Instead, we make the code we have maintainable. Each of the tools the
author reviles is present in the language specifically because using it
properly makes libraries and programs more maintainable. A system coded using
the features wisely, well, and pervasively is more maintainable, and
fundamentally better.

The alternative would be to say that systems in raw C, or assembly language,
are more maintainable, which is obvious nonsense.

The experiences that led the author to his conclusions are no doubt tragically
lamentable, but do not represent anything like the mainstream experience of
system construction and maintenance.

~~~
RandyGaul
Hi, author here :)

> The term "abstraction overhead" is already defined

Interesting, I didn't know that. I was just trying to describe an idea I had
in my head, and not hijack some pre-existing term.

> Most of us don't get the luxury of discarding a system and rewriting from
> scratch. Instead, we make the code we have maintainable. Each of the tools
> the author reviles is present in the language specifically because using it
> properly makes libraries and programs more maintainable.

You're right. Re-writing things is a luxury.

> The alternative would be to say that systems in raw C, or assembly language,
> are more maintainable, which is obvious nonsense.

Well I didn't say that, and I don't agree that it's the alternative, as it's
merely a single alternative. I tried to focus on encouraging a skeptical
nature when picking language features to use, and tried to demonstrate the
idea of applying skepticism with my own personal examples/choices. The purpose
of the skepticism is to encourage conscious cost/benefit analysis that takes
into account compilation time, but also how easy code is to grok by new eyes.

~~~
comex
Don't worry about the parent's excessive negativity. Fast compilation time is
a huge and underappreciated benefit. As for abstraction... I personally
disagree with some of your conclusions as well, but I also recognize it's a
fundamentally subjective topic. After all, how easy something is to understand
depends on who is trying to understand it. Different people have different
preferences and are familiar with different coding patterns.

