4 ms·

> Assert is primarily meant to be documentation of constraints in code Real or imagined constraints? AFAICT, an assert only tells me what you wish your program

> Assert is primarily meant to be documentation of constraints in code Real or imagined constraints? AFAICT, an assert only tells me what you wish your program did, but that has absolutely no bearing on what it will actually do.

coldtea 10y ago
Neither "real" nor "imagined". An asserts checks DESIRED constraints. >AFAICT, an assert only tells me what you wish your program did, but that has absolutely no bearing on what it will actually do. Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do.
- catnaroek 10y ago
  > An asserts checks DESIRED constraints. Then imagined it is. Your desires are totally a part of your imagination, unless you make them become real. > Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do. Point taken. Unfortunately, logging errors or aborting the program won't make assertions magically become true, though.
  - JonnieCache 10y ago
    If you have the process quit it definitely stops them from being false though. I thought that was the point of assert()?
    - catnaroek 10y ago
      > If you have the process quit it definitely stops them from being false though. The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.
      - coldtea 10y ago
        >The assertion remains false for the final process state, before the process quits. Which is inconsequential. Programmers don't expect automatic "recovery" from assertions, they expect them to notify them of the violated constraint, and/or to ensure that a program wont go on and use a value that violates an assertion further down -- which program termination achieves. >Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process. Captain Obvious?
        catnaroek 10y ago
        > Programmers don't expect automatic "recovery" from assertions, Users don't expect failed asserts at all. > Captain Obvious? Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.”
        coldtea 10y ago
        >Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.” He meant from being false subsequently in the program. I see we were joined by Technically Correct Man too. http://9gag.com/gag/a5PmrLq/technically-correct-man-the-man-we-need http://9gag.com/gag/a5PmrLq/technically-correct-man-the-man-...
        catnaroek 10y ago
        > He meant from being false subsequently in the program. But, you see, the assertion is no less false just because the process was aborted. The fact remains that there exists a reachable state for which the assert fails. So apparently what I meant is no more obvious to you than it was for JonnieCache.
        deleted 10y ago
        [deleted]
  - coldtea 10y ago
    >Then imagined it is. Only in the most pedantic and useless sense of the term. Asserts are not just some random imagination, they are added based on the program's specifications and expected/desired functionality and constraints. The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated. >unless you make them become real. Only there are no assurances for that. If the invariants in your program were somehow guaranteed to be "real" then you wouldn't need asserts. Asserts are there because whether you tried to make your invariants "become real" or not, you'll still miss things, have bugs, have unexpected interactions with code/systems outside your control etc. So they are there to tell you about those misses. >Point taken. Unfortunately, logging errors or aborting the program won't make assertions magically become true, though. Assertions are not expected to "magically become true" -- just to (a) inform about anytime they are violated, and, optionally, (b) not be violated and still have the program continue to run.
    - catnaroek 10y ago
      > The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated. An “invariant” is a function of the process state whose value remains constant (hence “invariant”) in spite of changes to the process state. Perhaps you meant “precondition” or “postcondition”? > Only there are no assurances for that. If the invariants in your program were somehow guaranteed to be "real" Guaranteeing that preconditions, postconditions and invariants hold when they're supposed to hold is your job, not the computer's. > then you wouldn't need asserts. I absolutely don't need asserts. An assert merely describes what you want, but that's useless to me, unless you establish a relation between what you want and what your program actually does - with proof. > Asserts are there because whether you tried to make your invariants "become real" or not, you'll still miss things, have bugs, It will become patently clear when the proof doesn't go through. > have unexpected interactions with code/systems outside your control etc. What happened to sanitizing input at system boundaries? > Assertions are not expected to "magically become true" Of course. Assertions are expected to always be true.
      - coldtea 10y ago

coldtea 10y ago

Neither "real" nor "imagined". An asserts checks DESIRED constraints. >AFAICT, an assert only tells me what you wish your program did, but that has absolutely no bearing on what it will actually do. Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do.

catnaroek 10y ago
> An asserts checks DESIRED constraints. Then imagined it is. Your desires are totally a part of your imagination, unless you make them become real. > Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do. Point taken. Unfortunately, logging errors or aborting the program won't make assertions magically become true, though.
- JonnieCache 10y ago
  If you have the process quit it definitely stops them from being false though. I thought that was the point of assert()?
  - catnaroek 10y ago
    > If you have the process quit it definitely stops them from being false though. The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.
    - coldtea 10y ago
      >The assertion remains false for the final process state, before the process quits. Which is inconsequential. Programmers don't expect automatic "recovery" from assertions, they expect them to notify them of the violated constraint, and/or to ensure that a program wont go on and use a value that violates an assertion further down -- which program termination achieves. >Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process. Captain Obvious?
      - catnaroek 10y ago
        > Programmers don't expect automatic "recovery" from assertions, Users don't expect failed asserts at all. > Captain Obvious? Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.”
        coldtea 10y ago
        >Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.” He meant from being false subsequently in the program. I see we were joined by Technically Correct Man too. http://9gag.com/gag/a5PmrLq/technically-correct-man-the-man-we-need http://9gag.com/gag/a5PmrLq/technically-correct-man-the-man-...
        catnaroek 10y ago
        > He meant from being false subsequently in the program. But, you see, the assertion is no less false just because the process was aborted. The fact remains that there exists a reachable state for which the assert fails. So apparently what I meant is no more obvious to you than it was for JonnieCache.
        deleted 10y ago
        [deleted]
- coldtea 10y ago
  >Then imagined it is. Only in the most pedantic and useless sense of the term. Asserts are not just some random imagination, they are added based on the program's specifications and expected/desired functionality and constraints. The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated. >unless you make them become real. Only there are no assurances for that. If the invariants in your program were somehow guaranteed to be "real" then you wouldn't need asserts. Asserts are there because whether you tried to make your invariants "become real" or not, you'll still miss things, have bugs, have unexpected interactions with code/systems outside your control etc. So they are there to tell you about those misses. >Point taken. Unfortunately, logging errors or aborting the program won't make assertions magically become true, though. Assertions are not expected to "magically become true" -- just to (a) inform about anytime they are violated, and, optionally, (b) not be violated and still have the program continue to run.
  - catnaroek 10y ago
    > The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated. An “invariant” is a function of the process state whose value remains constant (hence “invariant”) in spite of changes to the process state. Perhaps you meant “precondition” or “postcondition”? > Only there are no assurances for that. If the invariants in your program were somehow guaranteed to be "real" Guaranteeing that preconditions, postconditions and invariants hold when they're supposed to hold is your job, not the computer's. > then you wouldn't need asserts. I absolutely don't need asserts. An assert merely describes what you want, but that's useless to me, unless you establish a relation between what you want and what your program actually does - with proof. > Asserts are there because whether you tried to make your invariants "become real" or not, you'll still miss things, have bugs, It will become patently clear when the proof doesn't go through. > have unexpected interactions with code/systems outside your control etc. What happened to sanitizing input at system boundaries? > Assertions are not expected to "magically become true" Of course. Assertions are expected to always be true.
    - coldtea 10y ago