61–70 of 240 posts
Earlier quoted context omitted.
Unfortunately, I did. It is an attempt to approach complexity, cognitive load and high entropy in code, jumping to conclusions prematurely while suggesting a solution that is worse than the problem.
I would really like to convince you that you are missing something very important. Please try to make sense of the article, reading it again a trying to find cases where it makes sense for you.
EVERY class implemented an interface. 98% of interfaces had one implementation.
Every programmer was applying a different programming pattern. A lot of abstractions seemed incomplete and did not work.
Proguard (mostly used for code obfuscation for Android apps) definitions were collected in the top module even though the project had multiple modules. Half of the definitions were no longer needed and the code was badly obfuscated. Problems were solved by continuesly adding classes and checking what sticks.
The UI was controlled by a stateful machine. State transitions were scatter everywhere in the code with lots of conditions in unforeseen places.
Legacy code was everywhere because no one wanted to risk a very long debugging session of an unforseen change.
No API definitions. Just Maps that get send via REST to URLs.
By biggest mistake was to not directly rewrite this project when I entered the team. We did after one year.
Abstraction hides detail, but at what coat? A network close call at a high level closes a network socket. But at the tcp level there's a difference between close and reset. Which do you want? Your api has removed that choice from you, and if you look you will have no idea if rhe close api does a close or a reset. Is the difference important? If depends. If you have a bunch of half open sockets and run out of file des…
It has? Can't you rely on connect(2) with AF_UNSPEC doing a RST, and shutdown(2) with SHUT_WR doing a FIN?
What about java?
The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…
Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.
They can do that too, but the cache miss cost already makes that expensive.
The best part comes close to the end:
> Asymmetry of abstraction costs
> There’s also a certain asymmetry to abstraction. The author of an abstraction enjoys its benefits immediately—it makes their code look cleaner, easier to write, more elegant, or perhaps more flexible. But the cost of maintaining that abstraction often falls on others: future developers, maintainers, and performance engineers who have to work with the code. They’re the ones who have to peel back the layers, trace the indirections, and make sense of how things fit together. They’re the ones paying the real cost of unnecessary abstraction.
TCP is great. Long chains of one-line functions that just permute the arguments really suck. These both get called abstraction, and yet they're quite different. But then you hear people describe abstraction ahem abstractly. "Abstraction lets you think at a higher level," "abstraction hides implementation detail," and it's clear that neither of those things are really abstractions. As the OP mentions, we have a great…
I just re-read your article but unfortunately I still struggle to really understand it. I believe you have a lot of experience in this, so I'd love to read a more dumbed down version of it with less math and references to PL concepts and more practical examples. Like, this piece of code does not contain an abstraction, because X, and this piece of code does, because Y.
Keep up the good work!
>There’s a well-known saying: "All abstractions leak." It’s true. No matter how good the abstraction, eventually, you’ll run into situations where you need to understand the underlying implementation details This is false. One can read up on Theorem's for Free by Wadler to see that not all abstractions are leaky.
Theorems for Free tells you that some abstractions satisfy some mathematical properties (for free!) under some circumstances. If you write down a function with signature {T : Type} -> T -> T then it must be the identity function, if you do not use "malicious" extensions of the type system. But what is the performance of the identity function? Here is an identity function: lambda T, lambda t, if (2 + 2 = 4) then t els…