3 ms·

> Null pointers take something that should be strictly consistent (references) and make it fuzzy. I'd disagree; this is still strict consistency, at least in m

by zvrba 4y ago

> Null pointers take something that should be strictly consistent (references) and make it fuzzy. I'd disagree; this is still strict consistency, at least in managed languages like Java or C#. (Coming from someone who has fully embraced nulls instead of fighting them.) "Strict consistency" breaks in C and C++ where a pointer can either point to 1) a valid object, 2) be null, 3) point to an invalid address (i.e., dereferencing it crashes the program). Cases 1 and 2 can simply be distinguished by simple != 0 check. There is no (direct, simple, portable, defined by the language) check to distinguish between cases 1 and 3, which is where the inconsistency arises.

josephg 4y ago
>> Null pointers take something that should be strictly consistent (references) and make it fuzzy. > I'd disagree; this is still strict consistency, at least in managed languages like Java or C# The semantics are well defined, but the program that lives in my head (where the pointer is never null) can be subtly different from the program that runs on my computer. On the computer, the pointer can and will very occasionally be null, because I have a bug somewhere else in my code that the compiler isn't smart enough to point out to me. That window of fuzzyness is wide enough to fit a peak hour traffic jam full of bugs. > (Coming from someone who has fully embraced nulls instead of fighting them.) Everyone who programs in C, Java, Javascript, C# and all the other languages with null pointers feel like they "embrace nulls rather than fight them". And yet, memory bugs still make up ~60% of the critical security vulnerabilities in Chrome and other systems software. I've seen so many crashes in application software over the years from null pointer exceptions (or the C/C++ equivalents). I've been programming for 30 years and I still make occasional mistakes in these languages ending up with null pointer related errors. I think its fair to say that moving away from implicitly nullable types lowers our collective defect rate. Language authors are on board too. Haskell, Swift, Rust, Typescript and even (I think) C++ now have non-nullable types in their type system. Even if you feel like you're too smart to need the guard rails of non-nullable references, I'm definitely not that smart. And chances are, you run my code. Tightening up this stuff lowers the chance that my software crashes while you're using it.
- zvrba 4y ago
  So what to do about stuff such as lazy creation of objects? - Option 1: nullable reference and if the program crashes, you have a bug. (That should be caught during testing.) - Option 2: Maybe<T>, making the rest of the code unreadable. Because - Option 2a: "Force-extract" the value and get another exception if the value is not initialized - Option 2b: Do "proper" pattern-match and do ??? if the value is not initialized. So I strongly prefer a plain nullable reference. If I dereference it, it raises an exception that gets handled at top-level _just like any other exception due to any other kind of bug_. There's no reason that, in a properly structured program, dereferencing null should crash the whole program. (In a managed language. Unmanaged languages have their own problems - e.g., impossible to determine if a non-null pointer is at all valid. Though OS _does_ let you handle segfaults, if you want to go that way. Windows structured exceptions are much more flexible there than anything available on unix.)

by zvrba 4y ago

josephg 4y ago

>> Null pointers take something that should be strictly consistent (references) and make it fuzzy. > I'd disagree; this is still strict consistency, at least in managed languages like Java or C# The semantics are well defined, but the program that lives in my head (where the pointer is never null) can be subtly different from the program that runs on my computer. On the computer, the pointer can and will very occasionally be null, because I have a bug somewhere else in my code that the compiler isn't smart enough to point out to me. That window of fuzzyness is wide enough to fit a peak hour traffic jam full of bugs. > (Coming from someone who has fully embraced nulls instead of fighting them.) Everyone who programs in C, Java, Javascript, C# and all the other languages with null pointers feel like they "embrace nulls rather than fight them". And yet, memory bugs still make up ~60% of the critical security vulnerabilities in Chrome and other systems software. I've seen so many crashes in application software over the years from null pointer exceptions (or the C/C++ equivalents). I've been programming for 30 years and I still make occasional mistakes in these languages ending up with null pointer related errors. I think its fair to say that moving away from implicitly nullable types lowers our collective defect rate. Language authors are on board too. Haskell, Swift, Rust, Typescript and even (I think) C++ now have non-nullable types in their type system. Even if you feel like you're too smart to need the guard rails of non-nullable references, I'm definitely not that smart. And chances are, you run my code. Tightening up this stuff lowers the chance that my software crashes while you're using it.

zvrba 4y ago
So what to do about stuff such as lazy creation of objects? - Option 1: nullable reference and if the program crashes, you have a bug. (That should be caught during testing.) - Option 2: Maybe<T>, making the rest of the code unreadable. Because - Option 2a: "Force-extract" the value and get another exception if the value is not initialized - Option 2b: Do "proper" pattern-match and do ??? if the value is not initialized. So I strongly prefer a plain nullable reference. If I dereference it, it raises an exception that gets handled at top-level _just like any other exception due to any other kind of bug_. There's no reason that, in a properly structured program, dereferencing null should crash the whole program. (In a managed language. Unmanaged languages have their own problems - e.g., impossible to determine if a non-null pointer is at all valid. Though OS _does_ let you handle segfaults, if you want to go that way. Windows structured exceptions are much more flexible there than anything available on unix.)