41–50 of 99 posts
I only think about "Out of the Tar Pit".
I think part of the mystique of it is that the authors kind of faded into the background after publishing it. I've never been able to find a follow-up paper from them.
http://pages.cs.wisc.edu/~remzi/Naur.pdf
At the time I found it I was was working where the key challenge was not so much technical as much as ensuring that simple technology, spread across a large breadth of functionality, adhered to a consistent vision of the business domain that was being implemented. The program became an implementation of the mental model I developed of the business domain itself: its purpose, its uses, and its allowances and prohibitions. The Naur paper hit exactly not only on what I had been implementing in code, but on what other developers would have to know in order to maintain that code over time.... and had the kind of knowledge that had been lost over the life of application by the time I came to be involved.... and part of why my project existed.
So glad to see the Law of Leaky Abstractions in there - that's had a very long-running impact on how I think about programming. It's still super-relevant today, nearly 18 years after it was published. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
A) not a law, but a principle
B) a tautology (formally the essence is “All non-trivial abstractions are non-trivial”)
(Let alone the weaselly “to some degree“)
Earlier quoted context omitted.
You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. Or if you have a bad RAM chip.
Indeed proof formalisms are themselves leaky abstractions.
Earlier quoted context omitted.
I’m going through the conversation with a colleague atm where he believes DRY applies to everything.
Yeah that sucks. Especially when you're designing service endpoints and your colleague insists upon reusing an existing endpoint instead of opening up a new one, because the two use cases looked the same when he squinted hard enough. Now instead of /credit-card and /debit-card, which are independently testable, debuggable and changeable, you just have /card. Can't change the debit logic in /card because it will break…
Earlier quoted context omitted.
It's nonsense, written because Joel had never used a language with a decent type system. Any Haskell programmer uses half a dozen non-leaking abstractions before breakfast. Even the examples in the post itself don't hold up - using UDP instead of TCP doesn't actually mean your program will work any better when someone unplugs the network cable.
Is it possible that you are misinterpreting what Spolsky meant? I think he means that in the real world we interact with implementations of abstractions, and that the implementation always shines through and can bite you in the ass. This is what makes side-channel attacks possible, and (in Spolsky's view) unavoidable.
I understood fine. He asserts that "always" on the basis of a handful of examples, only one of which even attempts to show anything more than a performance difference. It's nonsense.
Earlier quoted context omitted.
I don't think that's true. A lot of these abstractions are provably correct and so simply cannot leak (and in slightly more advanced languages you might even enforce those proofs - consider Idris' VerifiedMonad and friends). Of course if you put garbage in at the lower levels (e.g. define a monoid instance that doesn't actually commute) then you will get garbage out at the higher levels (e.g. the sum of the concatena…
You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. Or if you have a bad RAM chip.
There are cache-aware abstractions if your situation warrants them. Of course if you abstract over a detail then you lose control over that detail. But that's not the same as a leak, and it's the very essence of programming at all; if the program needs to behave differently every time it runs, then creating a useful program is impossible.
> Or if you have a bad RAM chip.
That's another example of what I said about garbage in, garbage out. The fault isn't in the abstraction, the fault is the bad RAM chip. If you were manually managing all your memory addresses then a bad RAM chip would still present the same problem.
Sadly it's a video/presentation, not an essay, but Simple Made Easy[1] is the single software argument that has made the most impact on me. ___ 1. https://www.infoq.com/presentations/Simple-Made-Easy/
So glad to see the Law of Leaky Abstractions in there - that's had a very long-running impact on how I think about programming. It's still super-relevant today, nearly 18 years after it was published. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
I hate it, because it’s either: A) not a law, but a principle B) a tautology (formally the essence is “All non-trivial abstractions are non-trivial”) (Let alone the weaselly “to some degree“)
"Not a law" is strictly tue, but the "law" idiom is totally in-line with "law of supply and demand," "law of diminishing returns," etc.
The tautology problem is not a problem. Tautologies are powerful. Douglas Adams has a great essay on this, but his novel version is more concise.
If you want strict laws and no "to some degree" hedges, read physics.
Earlier quoted context omitted.
It's nonsense, written because Joel had never used a language with a decent type system. Any Haskell programmer uses half a dozen non-leaking abstractions before breakfast. Even the examples in the post itself don't hold up - using UDP instead of TCP doesn't actually mean your program will work any better when someone unplugs the network cable.
The reason UDP is less leaky is not because it meets any guarantee better, but because it guarantees less