Earlier quoted context omitted.
Not op, but let me rephrase it: leaky abstractions create more trouble than is worth it. If your abstraction does not fit the problem neatly do not abstract it.
Leaky abstractions are bad abstractions. So what you are basically saying is “don’t implement bad abstractions”. Ehhhh right. I think we can all agree to not implement bad things. There is no insight or enlightenment there IMHO.
> Having said that, a lack of architectural abstractions leads to badly designed code with a WTF count reaching the heavens.
> a lack of architectural abstractions leads to spaghetti code.
> domain logic directly relying on a specific UI framework?
If we are pedantic: lack of architectural abstractions, spaghetti code, and domain logic tied to an UI can also be interpreted as simply bad, so no information in either of our posts :)
Of course, I am joking. Saying that I think leaky abstractions are bad, or you saying that no abstractions are bad is new information (it reduces uncertainty). It tells us that we think that x is bad.
We can agree that bad abstractions are bad. In this thread, abstracting to early, or having leaky abstractions or not having any abstractions are just 3 positions on the topic of what a bad abstraction is.
I bet we could much easier agree with a specific example. In my experience all "big principle" discussions improve when we focus on a specific example. Otherwise people are thinking of different scenarios.
In any case, I can think of scenarios where each of those 3 positions is right, so I do not really disagree with any of them.