5 ms·

> Nullability (or nillability) > func(s *string) { > // s maybe nil here, better check first > } If this happens, you don't have proper checks before thi

by knodi 2y ago

> Nullability (or nillability) > func(s *string) { > // s maybe nil here, better check first > } If this happens, you don't have proper checks before this call. Clearly an error check was missed prior to this call.

ninkendo 2y ago
You know what's better than having to remember to write the proper checks before the call? Having the compiler do the checks for you. Code that results in a nil dereference should not be compilable, period. Any programming language that allows it is flawed.
- mariusor 2y ago
  > Any programming language that allows it is flawed. I think any language that allows that has different priorities than complete code correctness. There might even be programmers out there that would also prefer those priorities (simplicity, speed, etc) over having the compiler spend time every compilation to make sure a pointer is null or not.
  - ninkendo 2y ago
    The amount of time spent every compilation on this is negligible: a nullable type is just another type like any other. I don’t buy your argument at all. It’s a clear no-brainer at this point: null references were a mistake, and any language with compile-time type checking is flawed if they’re allowed.
    - mariusor 2y ago
      > It’s a clear no-brainer at this point Of course. All compiler designers, outside a select few, are clearly wrong and have given the problem absolutely no thought.
      - ninkendo 2y ago
        I mean, the guy who is broadly considered the "inventor" of the null reference straight-up admits he gave it no thought: https://en.wikipedia.org/wiki/Tony_Hoare https://en.wikipedia.org/wiki/Tony_Hoare > At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement So, it doesn't seem unlikely at all that other languages with type systems[0] probably just carried this behavior forward because it's how other languages worked at the time. The idea that you could have references which weren't allowed to be null probably seemed limiting, because other languages allowed it. That this was a mistake is pretty broadly accepted at this point. It's not even a controversial statement any more. [0] I'm excluding languages that don't have type checking at compile time (or without any compile time at all), that's a different discussion. I'm limiting the scope of my criticism to languages that (1) have a compile-time type checker but (2) opt to have that type checker allow null references to be used as if they're non-null.
      - Dylan16807 2y ago
        Compiler designers don't have a choice. Their skill and intelligence is not evidence in either direction, because they're not the ones adding null to the language.
    - lelanthran 2y ago
      > It’s a clear no-brainer at this point: null references were a mistake, and any language with compile-time type checking is flawed if they’re allowed. Maybe you mean 'dereferences', not 'references', because without NULL/null/nil, we can't interface to the real world which is filled with "there is no value here!" values.
      - tialaramex 2y ago
        No. The null reference shouldn't exist. That's Tony Hoare's "Billion Dollar Mistake". Rust does not have null references. If I have a reference it is not null. The "there is no value here" semantic is provided by Option<T> - if I mean that there may or may not be a reference I want Option<&T> an optional reference.
        lelanthran 2y ago
        > No. The null reference shouldn't exist. That's Tony Hoare's "Billion Dollar Mistake". This gets repeated so much, so often, that at this point it's safer to assume that the person who is citing it is just so new to programming that they don't realise we've all already seen multiple times, almost always posted by an enthusiastic but ultimately green newbie. > Rust does not have null references. So? The word "reference" in Rust is defined by that languages specification, which is not the same definition as the word "reference" used in English, nor in other programming languages. If you were having a Rust-specific discussion, you should have said so. > - if I mean that there may or may not be a reference I want Option<&T> And one of those options is `this reference does not exist`, which is what Tony Hoare referred to as a null reference in his writing(s). Hence it's the dereference that's a problem in programming languages other than Rust, not the existence of the null reference in languages other than Rust. Note, I am using the word 'reference' as defined everywhere outside of Rust. I am also using the word 'dereference' as defined everywhere outside of Rust.
        tialaramex 2y ago
        Yes, other people are going to keep pointing you at Tony's lecture because people like you are going to keep insisting that somehow this was a good idea, which it was not. I wouldn't have mentioned Tony's lecture in this sort of rant decades ago when I graduated because he hadn't given it. I would probably have cited his lament about Z (a formal notation, which I had by then learned) because some of the same lessons apply. New Jersey languages won for a long time, simplicity of implementation trumped correctness. Languages like C and eventually C++ dominated because while the programs were invariably wrong, the enormous cost of that could be somewhat justified by an insistence that better alternatives don't exist, even though of course better alternatives did exist. But notice that even in C++ there are no null references. It's just that unlike Rust the C++ language inherits C's "strong typed, weakly checked" approach to types, it's trivial to make such an "impossible" thing, so although there are no null references, your references might be null anyway... The whole point is the ergonomics, which you are ignoring whether out of ignorance or because you think you'll get away with it rhetorically. Option<&T> isn't a &T it only might be one. That's why C++ is probably getting std::optional<T&> at last in C++ 26, and why languages like C# add "non-nullable" types. Tony's mistake has terrible ergonomics.
  - tialaramex 2y ago
    No, "simplicity" and "speed" are in fact both conditional on correctness. Simple wrong answers aren't useful, fast wrong answers aren't useful. There can be accuracy and you might trade lower accuracy for speed, but that's not correctness. If the answer is "Chicago" then "A City in North America" is low accuracy but "New York" is wrong.
- hnlmorg 2y ago
  I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved another way if nils weren’t available. It would have been more code but it might have had the side effect of that codes behaviour being more explicit. So potential win-win. This argument feels somewhat moot though. I cannot see how Go could ever reverse their nil decision because it’s so core to how interfaces work that I suspect it would end up being a massive breaking change.
  - masklinn 2y ago
    > I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved another way if nils weren’t available. In every language where pointers / references / values are not universally nullable, it's just an opt-in away, either as a wrapper type (Option/Maybe), a union type (T* | Nil), or a built-in language feature. Either way you can pretty much always say "this may be nil", the difference is that you can't use a nullable value where a non-nullable value is expected, the language will require explicit checking (or in the worst case coercion).
    - hnlmorg 2y ago
      Ah ok. That makes a lot more sense.
mariusor 2y ago
You should check the nulls where you run the risk for panic. This is doubly true if your function is part of a library.
- enneff 2y ago
  It depends. In this trivial case, what do you do if you find s == nil is true? You probably panic anyway. Unless you have some specific reason to panic with a different message to the default “nil pointer dereference” then there’s no point checking it.
- jfoudfwfayasd 2y ago
  Incorrect, it's a type system flaw.
- dwattttt 2y ago
  The point is that you should check for null, then be able to represent the variable as something that can't be null. That way once you've checked it's not null (somewhere you're not forced to panic ideally), you can pass around the pointer & be confident you don't need to ever check it again.

by knodi 2y ago

ninkendo 2y ago

You know what's better than having to remember to write the proper checks before the call? Having the compiler do the checks for you. Code that results in a nil dereference should not be compilable, period. Any programming language that allows it is flawed.

mariusor 2y ago
> Any programming language that allows it is flawed. I think any language that allows that has different priorities than complete code correctness. There might even be programmers out there that would also prefer those priorities (simplicity, speed, etc) over having the compiler spend time every compilation to make sure a pointer is null or not.
- ninkendo 2y ago
  The amount of time spent every compilation on this is negligible: a nullable type is just another type like any other. I don’t buy your argument at all. It’s a clear no-brainer at this point: null references were a mistake, and any language with compile-time type checking is flawed if they’re allowed.
  - mariusor 2y ago
    > It’s a clear no-brainer at this point Of course. All compiler designers, outside a select few, are clearly wrong and have given the problem absolutely no thought.
    - ninkendo 2y ago
      I mean, the guy who is broadly considered the "inventor" of the null reference straight-up admits he gave it no thought: https://en.wikipedia.org/wiki/Tony_Hoare https://en.wikipedia.org/wiki/Tony_Hoare > At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement So, it doesn't seem unlikely at all that other languages with type systems[0] probably just carried this behavior forward because it's how other languages worked at the time. The idea that you could have references which weren't allowed to be null probably seemed limiting, because other languages allowed it. That this was a mistake is pretty broadly accepted at this point. It's not even a controversial statement any more. [0] I'm excluding languages that don't have type checking at compile time (or without any compile time at all), that's a different discussion. I'm limiting the scope of my criticism to languages that (1) have a compile-time type checker but (2) opt to have that type checker allow null references to be used as if they're non-null.
    - Dylan16807 2y ago
      Compiler designers don't have a choice. Their skill and intelligence is not evidence in either direction, because they're not the ones adding null to the language.
  - lelanthran 2y ago
    > It’s a clear no-brainer at this point: null references were a mistake, and any language with compile-time type checking is flawed if they’re allowed. Maybe you mean 'dereferences', not 'references', because without NULL/null/nil, we can't interface to the real world which is filled with "there is no value here!" values.
    - tialaramex 2y ago
      No. The null reference shouldn't exist. That's Tony Hoare's "Billion Dollar Mistake". Rust does not have null references. If I have a reference it is not null. The "there is no value here" semantic is provided by Option<T> - if I mean that there may or may not be a reference I want Option<&T> an optional reference.
      - lelanthran 2y ago
        > No. The null reference shouldn't exist. That's Tony Hoare's "Billion Dollar Mistake". This gets repeated so much, so often, that at this point it's safer to assume that the person who is citing it is just so new to programming that they don't realise we've all already seen multiple times, almost always posted by an enthusiastic but ultimately green newbie. > Rust does not have null references. So? The word "reference" in Rust is defined by that languages specification, which is not the same definition as the word "reference" used in English, nor in other programming languages. If you were having a Rust-specific discussion, you should have said so. > - if I mean that there may or may not be a reference I want Option<&T> And one of those options is `this reference does not exist`, which is what Tony Hoare referred to as a null reference in his writing(s). Hence it's the dereference that's a problem in programming languages other than Rust, not the existence of the null reference in languages other than Rust. Note, I am using the word 'reference' as defined everywhere outside of Rust. I am also using the word 'dereference' as defined everywhere outside of Rust.
        tialaramex 2y ago
        Yes, other people are going to keep pointing you at Tony's lecture because people like you are going to keep insisting that somehow this was a good idea, which it was not. I wouldn't have mentioned Tony's lecture in this sort of rant decades ago when I graduated because he hadn't given it. I would probably have cited his lament about Z (a formal notation, which I had by then learned) because some of the same lessons apply. New Jersey languages won for a long time, simplicity of implementation trumped correctness. Languages like C and eventually C++ dominated because while the programs were invariably wrong, the enormous cost of that could be somewhat justified by an insistence that better alternatives don't exist, even though of course better alternatives did exist. But notice that even in C++ there are no null references. It's just that unlike Rust the C++ language inherits C's "strong typed, weakly checked" approach to types, it's trivial to make such an "impossible" thing, so although there are no null references, your references might be null anyway... The whole point is the ergonomics, which you are ignoring whether out of ignorance or because you think you'll get away with it rhetorically. Option<&T> isn't a &T it only might be one. That's why C++ is probably getting std::optional<T&> at last in C++ 26, and why languages like C# add "non-nullable" types. Tony's mistake has terrible ergonomics.
- tialaramex 2y ago
  No, "simplicity" and "speed" are in fact both conditional on correctness. Simple wrong answers aren't useful, fast wrong answers aren't useful. There can be accuracy and you might trade lower accuracy for speed, but that's not correctness. If the answer is "Chicago" then "A City in North America" is low accuracy but "New York" is wrong.
hnlmorg 2y ago
I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved another way if nils weren’t available. It would have been more code but it might have had the side effect of that codes behaviour being more explicit. So potential win-win. This argument feels somewhat moot though. I cannot see how Go could ever reverse their nil decision because it’s so core to how interfaces work that I suspect it would end up being a massive breaking change.
- masklinn 2y ago
  > I’ve ran into a few edge cases where nil was a desirable feature. But on the whole I do agree with you. Those situations I mentioned could have been solved another way if nils weren’t available. In every language where pointers / references / values are not universally nullable, it's just an opt-in away, either as a wrapper type (Option/Maybe), a union type (T* | Nil), or a built-in language feature. Either way you can pretty much always say "this may be nil", the difference is that you can't use a nullable value where a non-nullable value is expected, the language will require explicit checking (or in the worst case coercion).
  - hnlmorg 2y ago
    Ah ok. That makes a lot more sense.

mariusor 2y ago

You should check the nulls where you run the risk for panic. This is doubly true if your function is part of a library.

enneff 2y ago
It depends. In this trivial case, what do you do if you find s == nil is true? You probably panic anyway. Unless you have some specific reason to panic with a different message to the default “nil pointer dereference” then there’s no point checking it.
jfoudfwfayasd 2y ago
Incorrect, it's a type system flaw.
dwattttt 2y ago
The point is that you should check for null, then be able to represent the variable as something that can't be null. That way once you've checked it's not null (somewhere you're not forced to panic ideally), you can pass around the pointer & be confident you don't need to ever check it again.