5 ms·

Another similar and good article: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-

Another similar and good article: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

an1sotropy 5y ago
Another common leaky abstraction: floating-point numbers as an abstraction of the real numbers. It works nearly all the time, until you have to really know about numerical precision, or where a NaN came from. https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leaky-abstraction/ https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leak...
- kortex 5y ago
  Relevant: the list of integers you can convert to float, invert twice, and don't get the same number back. https://oeis.org/A275419 https://oeis.org/A275419
  - an1sotropy 5y ago
    This is a treasure; thank you!
- chii 5y ago
  i wouldn't call floating point numbers an abstraction on real numbers. It's a representation - like char[] is a representation of strings, which is itself an abstraction used to manipulate human readable text!
  - an1sotropy 5y ago
    Read the link above about FP as a leaky abstraction of the reals; it explains it better than I can. FP is not really a representation of reals, because you can't represent the entire number line with a finite number of bits. It is a representation of a cleverly chosen subset of the reals, so well-designed that many people forget that they're not dealing with real numbers. That intelligent people can write code with FP values, operating on them thinking they are real numbers, and not knowing how FP works, and get programs that often do nearly the right thing, speaks to the success of FP as an abstraction. Understanding how things can go wrong is the leaks (like, non-associativity). I don't think people manipulating char[] representations of strings are ever at risk of forgetting that it's just an array of chars (they program with full awareness of the implementation), so it doesn't feel like there's much abstraction happening there. Other higher-level data structures for text manipulation probably do implement some useful abstractions; I haven't worked with those.
    - chii 5y ago
      > I don't think people manipulating char[] representations of strings are ever at risk of forgetting that it's just an array of chars and yet, when people start adding unicode text under this representation, and the program fails to work properly. Or when counting characters, and assume the glyph count would match the char array length. or any number of other string issues.
      - an1sotropy 5y ago
        yea good point. Unicode does overwhelm simplistic ideas about string representation. Love those grapheme clusters.
tester756 5y ago
this article is indeed cool and almost all examples are good, but this example is in my opinion heavily forced or even wrong? >And you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.
- belden 5y ago
  I think it’s contrived simply for a pun: > leaky abstractions > > hydroplaning > hydroplaning requires: - water (“leaky”) - sliding (“...traction”) - lack of _brakes_ (“abs...”) Well, and speed too.
lmm 5y ago
IMO that article is the most damaging thing to happen to programming culture in 20 years. It's not hard to write a valid abstraction, and none of Joel's examples actually hold up (yet he generalises it to a supposedly universal law). Of course abstractions are garbage-in, garbage-out - yes, TCP won't give you a reliable connection if you unplug the network cable, but an application written to use UDP won't fare any better in that case.
- tacitusarc 5y ago
  It sounds like you completely missed the point he’s trying to make...
  - lmm 5y ago
    Maybe, but if so so did many of my colleagues over the last ten years. I've seen so much bad code written in the name of avoiding abstractions, with that article as direct inspiration.
- klodolph 5y ago
  TCP won’t give you a reliable connection if you tunnel TCP over TCP, paradoxically, but you can tunnel TCP over UDP, UDP over TCP, or UDP over UDP. Leaky!
  - lmm 5y ago
    Not "leaky", the conditions that a TCP connection needs its underlying transport to satisfy are explicitly documented, and TCP doesn't conform to them.
    - klodolph 5y ago
      If you're going into the details of what conditions a TCP connection needs, you're no longer talking about an abstraction.
      - lmm 5y ago
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 ago
  Abstractions 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).

Another similar and good article: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

an1sotropy 5y ago

Another common leaky abstraction: floating-point numbers as an abstraction of the real numbers. It works nearly all the time, until you have to really know about numerical precision, or where a NaN came from. https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leaky-abstraction/ https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leak...

kortex 5y ago
Relevant: the list of integers you can convert to float, invert twice, and don't get the same number back. https://oeis.org/A275419 https://oeis.org/A275419
- an1sotropy 5y ago
  This is a treasure; thank you!
chii 5y ago
i wouldn't call floating point numbers an abstraction on real numbers. It's a representation - like char[] is a representation of strings, which is itself an abstraction used to manipulate human readable text!
- an1sotropy 5y ago
  Read the link above about FP as a leaky abstraction of the reals; it explains it better than I can. FP is not really a representation of reals, because you can't represent the entire number line with a finite number of bits. It is a representation of a cleverly chosen subset of the reals, so well-designed that many people forget that they're not dealing with real numbers. That intelligent people can write code with FP values, operating on them thinking they are real numbers, and not knowing how FP works, and get programs that often do nearly the right thing, speaks to the success of FP as an abstraction. Understanding how things can go wrong is the leaks (like, non-associativity). I don't think people manipulating char[] representations of strings are ever at risk of forgetting that it's just an array of chars (they program with full awareness of the implementation), so it doesn't feel like there's much abstraction happening there. Other higher-level data structures for text manipulation probably do implement some useful abstractions; I haven't worked with those.
  - chii 5y ago
    > I don't think people manipulating char[] representations of strings are ever at risk of forgetting that it's just an array of chars and yet, when people start adding unicode text under this representation, and the program fails to work properly. Or when counting characters, and assume the glyph count would match the char array length. or any number of other string issues.
    - an1sotropy 5y ago
      yea good point. Unicode does overwhelm simplistic ideas about string representation. Love those grapheme clusters.

tester756 5y ago

this article is indeed cool and almost all examples are good, but this example is in my opinion heavily forced or even wrong? >And you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.

belden 5y ago
I think it’s contrived simply for a pun: > leaky abstractions > > hydroplaning > hydroplaning requires: - water (“leaky”) - sliding (“...traction”) - lack of _brakes_ (“abs...”) Well, and speed too.

lmm 5y ago

IMO that article is the most damaging thing to happen to programming culture in 20 years. It's not hard to write a valid abstraction, and none of Joel's examples actually hold up (yet he generalises it to a supposedly universal law). Of course abstractions are garbage-in, garbage-out - yes, TCP won't give you a reliable connection if you unplug the network cable, but an application written to use UDP won't fare any better in that case.

tacitusarc 5y ago
It sounds like you completely missed the point he’s trying to make...
- lmm 5y ago
  Maybe, but if so so did many of my colleagues over the last ten years. I've seen so much bad code written in the name of avoiding abstractions, with that article as direct inspiration.
klodolph 5y ago
TCP won’t give you a reliable connection if you tunnel TCP over TCP, paradoxically, but you can tunnel TCP over UDP, UDP over TCP, or UDP over UDP. Leaky!
- lmm 5y ago
  Not "leaky", the conditions that a TCP connection needs its underlying transport to satisfy are explicitly documented, and TCP doesn't conform to them.
  - klodolph 5y ago
    If you're going into the details of what conditions a TCP connection needs, you're no longer talking about an abstraction.
    - lmm 5y ago

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 ago
Abstractions 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).