4 ms·

If you're willing to accept unsorted output from your sort function, why are you sorting? What are you sorting?

AnimalMuppet 7y ago
If you supply an invalid comparison function to your sort function, which would you prefer to happen - that it crash, or that it give you unsorted output? (If you actually wanted sorted output, you should have provided a valid comparison function.)
- njharman 7y ago
  No question, that it crash. Silent buggy behavior is a bitch to notice.
- chias 7y ago
  Personally, I would very much prefer that it crash.
- chc 7y ago
  Ideally I'd like a compile-time error — but that's beyond the current level of technology, so the next best thing is a crash. Having code that does unintended things is the worst-case scenario IMO. (Obviously it's the programmer's fault for providing buggy code, but that's a fault that every programmer shares. Personally, I appreciate any help in guarding against it.)
  - jiofih 7y ago
    > beyond the current level of technology I’m sure there quite a few languages that will catch that at compile time.
    - earenndil 7y ago
      It is possible for a compiler to catch that particular mistake at compile-time. It's also possible for the user to provide a proof to a given compiler that a comparison function is well-formed. But I think that the parent was referring to a function that would check arbitrary comparison functions in java for correctness, without a proof, which is afaik provable impossible.
  - estebank 7y ago
    > but that's beyond the current level of technology Is it? In Rust and other languages you would use trait bounds to restrict the input types to be comparable with each other, which would make this a compile time error.
    - Dylan16807 7y ago
      How does that prevent you from accidentally making a.compare(b) and b.compare(a) inconsistent on some values? Making sure you can compare the types is already happening in the compiler, and doesn't find the bug.
- naniwaduni 7y ago
  Crash, so that I actually get a reasonably high chance to notice that there is a bug during testing? The comparison being invalid is definitely a bug; if I didn't want sorted output, I wouldn't be sorting.
- kragen 7y ago
  Most of the time I want it to crash in development and give me unsorted output in production; debugging an unhandled exception is super easy compared to debugging sometimes incorrectly sorted output. In rare cases I would also want it to crash in production. I definitely don't want it to change between the two scenarios when I update my JVM.
  - deleted 7y ago
    [deleted]
- aaaa123 7y ago
  crash so i know what a fucking stupid mistake I made and thus I can fix it :)
- aaaa123 7y ago
  chrash, noob. Then I can fix it
- longemen3000 7y ago
  maybe you shouldn't supply invalid comparisons in the first place. but if you do, crashing seems like an appropriate response
- wil421 7y ago
  Crash so when wil421 sort is implemented in the next version I’m not scratching my head months or years later.

If you supply an invalid comparison function to your sort function, which would you prefer to happen - that it crash, or that it give you unsorted output? (If you actually wanted sorted output, you should have provided a valid comparison function.)

njharman 7y ago
No question, that it crash. Silent buggy behavior is a bitch to notice.
chias 7y ago
Personally, I would very much prefer that it crash.
chc 7y ago
Ideally I'd like a compile-time error — but that's beyond the current level of technology, so the next best thing is a crash. Having code that does unintended things is the worst-case scenario IMO. (Obviously it's the programmer's fault for providing buggy code, but that's a fault that every programmer shares. Personally, I appreciate any help in guarding against it.)
- jiofih 7y ago
  > beyond the current level of technology I’m sure there quite a few languages that will catch that at compile time.
  - earenndil 7y ago
    It is possible for a compiler to catch that particular mistake at compile-time. It's also possible for the user to provide a proof to a given compiler that a comparison function is well-formed. But I think that the parent was referring to a function that would check arbitrary comparison functions in java for correctness, without a proof, which is afaik provable impossible.
- estebank 7y ago
  > but that's beyond the current level of technology Is it? In Rust and other languages you would use trait bounds to restrict the input types to be comparable with each other, which would make this a compile time error.
  - Dylan16807 7y ago
    How does that prevent you from accidentally making a.compare(b) and b.compare(a) inconsistent on some values? Making sure you can compare the types is already happening in the compiler, and doesn't find the bug.
naniwaduni 7y ago
Crash, so that I actually get a reasonably high chance to notice that there is a bug during testing? The comparison being invalid is definitely a bug; if I didn't want sorted output, I wouldn't be sorting.
kragen 7y ago
Most of the time I want it to crash in development and give me unsorted output in production; debugging an unhandled exception is super easy compared to debugging sometimes incorrectly sorted output. In rare cases I would also want it to crash in production. I definitely don't want it to change between the two scenarios when I update my JVM.
- deleted 7y ago
  [deleted]
aaaa123 7y ago
crash so i know what a fucking stupid mistake I made and thus I can fix it :)
aaaa123 7y ago
chrash, noob. Then I can fix it
longemen3000 7y ago
maybe you shouldn't supply invalid comparisons in the first place. but if you do, crashing seems like an appropriate response
wil421 7y ago
Crash so when wil421 sort is implemented in the next version I’m not scratching my head months or years later.