3 ms·

I’ve been thinking a lot about this kind of problem lately. My thinking was triggered by a description of real-world contracts by Lawrence Lessig, in a talk abo

by jt2190 4y ago

I’ve been thinking a lot about this kind of problem lately. My thinking was triggered by a description of real-world contracts by Lawrence Lessig, in a talk about crypto. [1] His point was that in most real world contracts there are many, many undefined contingencies for rare occurrences; the time and effort to nail-down what each party should do in those cases is just not worth it, and if any of them do actually occur everyone will go to court for adjudication. The software industry might be better off if we start making explicit that we have a real trade off of time and effort between designing a system that can handle all contingencies, and one that needs adjudication occasionally, i.e. throws an error or crashes, needs patching, etc. [2] Notice that Rui’s solution here was to basically allow lld to just crash under rare, extraordinary cases. This seems reasonable when written here, but in the real world suggesting that a system be allowed to crash, ever, often gets very hard pushback. [1] “Smart Contracts and DApps: Clarity versus Obscurity” https://youtu.be/JPkgJwJHYSc?t=3512 https://youtu.be/JPkgJwJHYSc?t=3512 [2] “Hard-assed bug fixin’” Joel on Software (2001)

ncmncm 4y ago
This is where the programming-language exception feature is valuable. You could crash, but you can also throw. Somebody somewhere sometime might be able to do a better job with the situation than you can right there and then. Checking status codes all up and down the call graph does not increase the likelihood that something could be done, but costs in the meantime. Hiding the checking behind abstractions does not reduce those costs.
- jt2190 4y ago
  > You could crash, but you can also throw. Somebody somewhere sometime might be able to do a better job with the situation than you can right there and then. This is a very big assumption. Edit: The assumption is that this day can ever come. The author decided that in his system that day would likely never arrive.
  - ncmncm 4y ago
    There's no assumption, at all. Either it happens or it doesn't. If it doesn't, throwing an exception is a controlled sort of crash. There's no need for that person to decide, then and there, when they can just as well leave the choice to somebody else, at exactly zero cost.
    - jt2190 4y ago
      > when they can just as well leave the choice to somebody else, at exactly zero cost. This is where the confusion lies. “Zero cost” here means “it’s a few lines of code, a few cpu cycles to handle it. What’s the big deal?” But I’m not talking about a few lines of code or cpu cycles, I’m talking about developer time. Leaving the decision to someone else may take little no time to you, today, but might incur a steep cost on someone else’s time tomorrow. Even worse is when you, with deep domain knowledge, tempt a far less knowledgeable dev into “handling” an error at a time and in a place that will be difficult or impossible to handle, wasting their time.
      - ncmncm 4y ago
        You are still not getting this. It costs exactly zero more developer time to type "throw x" than to type "abort()". It places exactly zero demand on anybody else. If somebody decides they want to catch the exception and try something else, that is totally their choice, and they can devote as much or as little time to getting their idea working as they like. If they get it working, good. If they give up first, that is fine too.
        mst 4y ago
        Common Lisp's condition system arguably proves your point.
        jt2190 4y ago
        > You are still not getting this. I understand perfectly well what you’ve said, and I don’t disagree with any of it. The point I’m trying to make (badly, apparently) is not that. My point (and I believe the point of the linked article, and, I mistakenly thought, my original comment) is that decisions by a few can have enormous impacts on the productivity of many, including design decisions like “should we bother polishing the errors from these corner cases at the expense of delaying new feature work, or just let people report a bug if they run into a corner case and get on with new features?” Rui chose to group a whole swath of errors in lld into the “not worth polishing” category so they could move on with more important work. My apologies that my point somehow came across as “always crash your program, never throw exceptions!” Thanks for your patience and taking the time to read generously and deeply and to really understand my point.

by jt2190 4y ago

ncmncm 4y ago

This is where the programming-language exception feature is valuable. You could crash, but you can also throw. Somebody somewhere sometime might be able to do a better job with the situation than you can right there and then. Checking status codes all up and down the call graph does not increase the likelihood that something could be done, but costs in the meantime. Hiding the checking behind abstractions does not reduce those costs.

jt2190 4y ago
> You could crash, but you can also throw. Somebody somewhere sometime might be able to do a better job with the situation than you can right there and then. This is a very big assumption. Edit: The assumption is that this day can ever come. The author decided that in his system that day would likely never arrive.
- ncmncm 4y ago
  There's no assumption, at all. Either it happens or it doesn't. If it doesn't, throwing an exception is a controlled sort of crash. There's no need for that person to decide, then and there, when they can just as well leave the choice to somebody else, at exactly zero cost.
  - jt2190 4y ago
    > when they can just as well leave the choice to somebody else, at exactly zero cost. This is where the confusion lies. “Zero cost” here means “it’s a few lines of code, a few cpu cycles to handle it. What’s the big deal?” But I’m not talking about a few lines of code or cpu cycles, I’m talking about developer time. Leaving the decision to someone else may take little no time to you, today, but might incur a steep cost on someone else’s time tomorrow. Even worse is when you, with deep domain knowledge, tempt a far less knowledgeable dev into “handling” an error at a time and in a place that will be difficult or impossible to handle, wasting their time.
    - ncmncm 4y ago
      You are still not getting this. It costs exactly zero more developer time to type "throw x" than to type "abort()". It places exactly zero demand on anybody else. If somebody decides they want to catch the exception and try something else, that is totally their choice, and they can devote as much or as little time to getting their idea working as they like. If they get it working, good. If they give up first, that is fine too.
      - mst 4y ago
        Common Lisp's condition system arguably proves your point.
      - jt2190 4y ago
        > You are still not getting this. I understand perfectly well what you’ve said, and I don’t disagree with any of it. The point I’m trying to make (badly, apparently) is not that. My point (and I believe the point of the linked article, and, I mistakenly thought, my original comment) is that decisions by a few can have enormous impacts on the productivity of many, including design decisions like “should we bother polishing the errors from these corner cases at the expense of delaying new feature work, or just let people report a bug if they run into a corner case and get on with new features?” Rui chose to group a whole swath of errors in lld into the “not worth polishing” category so they could move on with more important work. My apologies that my point somehow came across as “always crash your program, never throw exceptions!” Thanks for your patience and taking the time to read generously and deeply and to really understand my point.