3 ms·
It feels to me that this blog post is pointing out the obvious. The examples are a bit forced in my opinion. I would expect it to be about badly designed or arc
by kinjba11 5y ago
It feels to me that this blog post is pointing out the obvious. The examples are a bit forced in my opinion. I would expect it to be about badly designed or architected code, but.
Iterating works. SQL works. Windshield wipers work. The iteration abstraction isn't leaking - the hardware and memory architecture isn't part of the abstraction. The SQL abstraction isn't leaking - the performance isn't part of the abstraction. The windshield wipers abstraction isn't leaking - the wipers were designed for rain, not a hurricane. Abstractions ignore details - that's the point. Reality doesn't cease to exist.
If your car isn't fast enough for the race, the car, steering wheel, accelerator pedal are not a leaky abstraction. You just don't have a fast enough car! If you have to worry about stuff like shifting gears, then an automatic transmission isn't the abstraction for you. The abstraction isn't leaking, you just chose the wrong one.
Abstractions are great.
I've never had to worry about CPU instructions or assembly code in the code I've written - the programming language abstraction is perfect as far as I'm concerned. Somebody handles it. I've never had to worry about the electricity powering my machines in the Cloud etc where I deploy. Perfect abstraction. Somebody handles it. My web browser chugs through hundreds of megabytes of JavaScript daily. Perfect abstraction. I've never needed to concern myself with the implementation of say V8. I've had my share of SQL performance investigations, but most of the SQL I've written didn't need any performance tweaking (there's a different abstraction for performance that works great - indexes).
Leaking is a matter of perspective.
- DharmaPolice 5y agoAbstractions are great but I think that's sort of the problem in some cases. You see a pattern like this in SQL from time to time - someone creates a view called dbo.GlobalReport which has all the joins and query logic they need for their reports. Next person comes along, sees the dbo.GlobalReport object but it's missing something so they wrap that in a view dbo.NewGlobalReport, joining a bunch of tables to the original dbo.GlobalReport. And this works. And then the next person comes along...and so on. Eventually someone has problems so they look at the query plan and their jaw drops. In theory, you shouldn't have to worry whether dbo.GlobalReport is a table or a view (if you're just querying it) but in practice you do (sometimes). Likewise, in an enterprise setting a (Windows) user shouldn't have to worry when saving a file to X:\ what kind of drive/storage X is. And 99.9% of the time, that abstraction works. But then someone tries to save a 500GB video and suddenly it does matter what kind of drive X is, where it is, how it's connected, the filesystem it's using etc. I think the issue in both cases is that the distinction is fairly obvious if you're in the know but not necessarily for anyone else (until they try it).