4 ms·

> Any programming language that allows it is flawed. I think any language that allows that has different priorities than complete code correctness. There might

> 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.

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.