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.
But please don't. Doing that adds a cost to the community, by toxifying it. Because of that, your pro-community intention is not only not fulfilled, it's actively damaged.
I find facile dismissals irritating as well, and lord knows this site gets a lot of them. But the way to push back is with a clear, positive defense of whatever was unfairly dismissed. Venting doesn't help; it only invites more venting.
I think its better to give feedback explicitly rather than sneering. The latter just feels bad to read (even as a third party) but doesn't really espouse some better active social norms to follow.
> to add a cost (the possibility of being dismissed/sneered back) to such dismissals.
Given the fact that this is a conversation among strangers, I would assert that it isn't really that effective to just add costs by making discourse less pleasant.
--
In general, I think a community is healthier when we treat people 25% better than you expect to be treated, to account for the Fundamental Attribution Error and other misinterpretations.
>I think its better to give feedback explicitly rather than sneering. The latter just feels bad to read (even as a third party) but doesn't really espouse some better active social norms to follow.
I guess so. Sometimes I'm just pissed from the easy dismissal, as in "This 5 second basic retort is all you've came up with, and you think you've taken down TFA?".
This whole pointless sub-discussion has had a small cost for me because for some reason I bothered reading it. A simple downvote of the original comment could have provided feedback to the author while sparing the rest of us.
It's a bit like saying bricks are useless, by limiting the entire argument to a single brick.