5 ms·
I think saying that some examples are just performance disadvantages rather than leaks misses the point. "Leaky" is a metaphor here, so assuming that any kind o
by jhh 13y ago
I think saying that some examples are just performance disadvantages rather than leaks misses the point. "Leaky" is a metaphor here, so assuming that any kind of actual data loss is necessary for it to be the case seems incorrect to me.
For example if your SQL query is too slow from a pragmatic point of view and then you go ahead and fix it by using optimizer hints then the abstraction of the procedural querying process provided by SQL has just failed you as it hasn't worked.
I agree that some abstractions are very good, but that does not make Joel's point moot. The key thing is to understand that abstractions are always some sort of tradeoff between the virtues of directness and the virtues of productivity.
Btw: I am really surprised that this essay had never been posted to HN before.
- lmm 13y ago> For example if your SQL query is too slow from a pragmatic point of view and then you go ahead and fix it by using optimizer hints then the abstraction of the procedural querying process provided by SQL has just failed you as it hasn't worked. Well sure. But I've never had that happen; is the A = B and B = C and C = A problem the article talks about one that causes problems in real-life code?
- danielweber 13y agoI've had to rewrite lots of SQL queries (for Postgres) that an intelligent database should have just handled for me. I'd prematurely exclude certain columns that it could be mathematically proven from the query I would never need and see amazing speed-ups. (I'm not picking on Postgres, it's a wonderful DB, but you need to understand how your tools are working.)