The Cost of Abstraction (2016)

You are exactly right. It's indirection without abstraction. Good abstractions are simpler than the sum of their parts, the author's example of abstraction is clearly far more complicated (templates, references) than two increment operations. Good abstractions are ones you don't even think about, like arithmetic operators. How often do non-embedded/non-OS developers think about how multiplication is implemented?

Quoting from the blog post:

>It also seems that Go's implicit interfaces were designed to avoid unnecessary abstraction.

Actually, interfaces are often extremely abstract in Go. How much more abstract does it get than io.Reader? It's a thing that you can read bytes from into slices (arrays). The io.Reader abstraction is far simpler than os.File, net.Conn, or even bytes.Buffer (a file object, a network connection, and an in-memory buffer, respectively).

He shows an example of indirection without abstraction, then blames abstraction. His point isn't wrong, the problem is that he's confusing abstraction with any form of indirection. He claims that abstractions increase cognitive load when in fact the opposite is true. Bad abstractions and indirection without abstraction increase cognitive load.

I agree with him that abstractions should be crafted carefully, but not because abstractions are categorically bad. If he thinks abstraction is so bad, why does he write software at all? Software is extremely abstract, even assembly language is an abstraction of what the CPU does. Human language is abstract too: we can talk about trees without having to consider any specific tree.

Abstraction is a fundamental building block of human civilization. Of course, he doesn't actually believe that abstractions are bad. It would be nice if he differentiated between good abstraction and bad abstraction.

On a side note: I take issue with his criticism of mocking. Good abstractions are easily mocked and make the code base easier to understand because you don't have to consider every detail of the application at the same time. On the other hand, mocking concrete objects,[0] rather than abstract roles, definitely complicates things.

[0] Or "header interfaces" that duplicate the API of a concrete class exactly : https://www.martinfowler.com/bliki/HeaderInterface.html

I confess I've never seen that happen, but I do think excessive abstraction is killing the argument this article is trying to make.

When would anyone ever make an inc_pair function? Or a hierarchy of 'animals that lay eggs'? I guess these are supposed to be examples of something, but I'm not sure what. I wouldn't even call them "abstraction". They seem like completely hypothetical examples of how to apply programming language features to non-problems in bad ways.

Without knowing what the designer of these programs is trying to model, it's impossible for me to understand what they're trying to accomplish or why they think applying these language features in this way makes sense at all.

Both of these examples sound like they increase the number of lines of code, for no appreciable benefit, and I recall Yegge's old observation that the main issue with any codebase is simply the bulk of it.

I think this is nonsense and leads to enterprise-y type patterns and hard to understand code.

Wrapping things for the sake of it is a recipe for unnecessary verbosity and a hard to learn codebase as things are obfuscated and take longer to trace through.

In C, your point 1 makes me think your code is unsafe, if you're having trouble keeping track of types and signedness. Point 2 is fair enough, but I think a lot of C headers are granular enough that it's irrelevant, especially given how fast everything is these days. Gone are the 8 hour builds of old.

Point 3 is precisely the type of premature interface-isation that's the problem here. If you're never going to change it, then it doesn't matter whether huge portions of the code rely on the library or your wrapper. It's basically the same thing. Only you've put in extra work to wrap something in another layer for no gain. 4 much the same.

Hmm, I think I should put that in context. I'm not saying write a wrapper for the sake of it. I don't wrap everything in three layers of OO giftwrap. I'm saying one should follow basic rules of hygiene.

For example, I have a FreeType backend in my code, and I have a single file which implements a font interface (open font file, choose font size, draw to texture in the format of my app) by interfacing with Freetype. It returns my own error values, prints warnings with my own logging framework, puts the data in my own datastructures, etc. All things that Freetype could never do since it does not know my project.

I have an OpenGL backend, and I make sure that my geometry and math stuff, UI drawing code, and what not, does not depend on OpenGL, or OpenGL types. (Did that once when I learned OpenGL, and it was terrible). So now I have basically one file which is dependent on OpenGL, and it's there to simply put my internal datastructures on the screen, in a very straightforward way.

Same goes for my windowing backend. I use GLFW currently but I make sure I don't use e.g. GLFW_KEY_A in client code. I define my own enums and own abstractions. It does not come with any cost to simply have my own KEY_A, which means I can swap out the backend relatively easily, and can change my model more easily (for example, make up my own controls abstraction instead of relying on a standard PC 104 keys keyboard, etc).

> In C, your point 1 makes me think your code is unsafe, if you're having trouble keeping track of types and signedness.

No, it's safer precisely because I have a well-defined boundary where values get converted. I can check for overflows there, and not worry about the rest of my code. There is no practical way to deal with size_t in every little place when normal values come as int.

> Point 2 is fair enough, but I think a lot of C headers are granular enough that it's irrelevant,

You bet. Have you ever tried to access parts of the Win32 API? You're immediately in for (I think it was) 30K lines of code even if you define WIN32_LEAN_AND_MEAN. Otherwise it's maybe more like 60K. It's crazy. Or check out GLEW (which I don't use it anymore). It generates 27000 lines of header boilerplate simply to access the OpenGL API.

Add to that that most headers have a standard #ifdef include guard, which means that while files get ignored the second time, the lexer has to parse the whole thing over and over again.

> If you're never going to change it

How would you know?

> then it doesn't matter whether huge portions of the code rely on the library or your wrapper.

It does matter a lot if there is a semantic mismatch.