3 ms·

> You need to worry about running out of memory precisely because the abstraction is leaky. In practice, I don't worry. I'm fine with the leaky abstraction, be

> You need to worry about running out of memory precisely because the abstraction is leaky. In practice, I don't worry. I'm fine with the leaky abstraction, because the benefit of fixing the leak (reducing the probability that OOM crashes my program from almost zero to exactly zero) isn't worth the cost (increased complexity). But see below. > If you need to micromanage, it's perhaps not leaky, but it's also not much of an abstraction. I'm not sure about this. There are levels of abstraction and degrees of micromanagement. For instance, `malloc` lets you micromanage the memory layout of your data structures, and `mmap` and `mprotect` also let you micromanage what you can do with each memory page, but they're still abstractions over even lower-level concerns, like the mapping between physical and virtual memory addresses. > We probably want a model of "we never run out of memory, our program may die at any point in time, possibly correlated with inputs", which I would contend is actually not very leaky. Depends on what kind of program you're writing. If your web crawler crashes, you just restart it. If your web server crashes, your users will be annoyed, but at least your database won't be compromised. (You're properly using transactions, right?) But if your DBMS crashes, your data might even be in an irrecoverably inconsistent state, unless you properly anticipated all (software) causes for it to crash.

dllthomas 11y ago
> In practice, I don't worry. I'm fine with the leaky abstraction, because the benefit of fixing the leak (reducing the probability that OOM crashes my program from almost zero to exactly zero) isn't worth the cost (increased complexity). In practice, you're being sloppy or what you've described is the relevant worrying - considering whether your program has appreciable odds of OOM and the odds of things being particularly bad when that happens, and then deciding that additional worrying is unnecessary. But this can need re-evaluating as circumstances change. > There are levels of abstraction and degrees of micromanagement. No disagreement there. > Depends on what kind of program you're writing. A bit, but mostly in terms of performance. > But if your DBMS crashes, your data might even be in an irrecoverably inconsistent state, unless you properly anticipated all (software) causes for it to crash. I disagree. If you have designed your program with an assumption that it might fail at any point regardless of reason, then you don't need to have "properly anticipated all (software) causes for it to crash", and further you should be robust against some portion of non-software causes.
- catnaroek 11y ago
  > In practice, you're being sloppy or what you've described is the relevant worrying I'm unhappy with this line of reasoning. For me, an abstraction leak is a failure to behave as advertised. Since memory allocation can always fail, an abstraction that advertises “allocations always succeed” is necessarily leaky. Even if the leak isn't important in practice, the leak exists. > If you have designed your program with an assumption that it might fail at any point regardless of reason I'm not sure this is even possible (if I take nothing for granted, how do I do anything?), but I'd like to be proven wrong.
  - dllthomas 11y ago
    > I'm unhappy with this line of reasoning. For me, an abstraction leak is a failure to behave as advertised. To my mind, it must fail to behave as advertised in a way that is meaningful. Otherwise, the differences are precisely what is being abstracted away. > I'm not sure this is even possible (if I take nothing for granted, how do I do anything?), but I'd like to be proven wrong. I don't mean "might act in arbitrary ways", but specifically "might be unexpectedly be terminated at any point".

dllthomas 11y ago

> In practice, I don't worry. I'm fine with the leaky abstraction, because the benefit of fixing the leak (reducing the probability that OOM crashes my program from almost zero to exactly zero) isn't worth the cost (increased complexity). In practice, you're being sloppy or what you've described is the relevant worrying - considering whether your program has appreciable odds of OOM and the odds of things being particularly bad when that happens, and then deciding that additional worrying is unnecessary. But this can need re-evaluating as circumstances change. > There are levels of abstraction and degrees of micromanagement. No disagreement there. > Depends on what kind of program you're writing. A bit, but mostly in terms of performance. > But if your DBMS crashes, your data might even be in an irrecoverably inconsistent state, unless you properly anticipated all (software) causes for it to crash. I disagree. If you have designed your program with an assumption that it might fail at any point regardless of reason, then you don't need to have "properly anticipated all (software) causes for it to crash", and further you should be robust against some portion of non-software causes.

catnaroek 11y ago
> In practice, you're being sloppy or what you've described is the relevant worrying I'm unhappy with this line of reasoning. For me, an abstraction leak is a failure to behave as advertised. Since memory allocation can always fail, an abstraction that advertises “allocations always succeed” is necessarily leaky. Even if the leak isn't important in practice, the leak exists. > If you have designed your program with an assumption that it might fail at any point regardless of reason I'm not sure this is even possible (if I take nothing for granted, how do I do anything?), but I'd like to be proven wrong.
- dllthomas 11y ago
  > I'm unhappy with this line of reasoning. For me, an abstraction leak is a failure to behave as advertised. To my mind, it must fail to behave as advertised in a way that is meaningful. Otherwise, the differences are precisely what is being abstracted away. > I'm not sure this is even possible (if I take nothing for granted, how do I do anything?), but I'd like to be proven wrong. I don't mean "might act in arbitrary ways", but specifically "might be unexpectedly be terminated at any point".