2 ms·

> because people like you are going to keep insisting that somehow this was a good idea, Woah, there cowboy, you're mischaracterising my position. When, and w

> because people like you are going to keep insisting that somehow this was a good idea, Woah, there cowboy, you're mischaracterising my position. When, and where, did I "insist that this was a good idea"? Me pointing out that the real world is filled with null references is irrelevant to whether or not I think they're a bad or good idea. > 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. Which bit made you think I'm ignoring it? The sad fact of life is that programs are written to interface to the real world, which is filled with missing values. Regardless of the programming language you use, you'll still deal with them. Some programming languages make it easier to deal with, and some harder. Regardless, you'll still have to deal with them, and IME the best way for a program to deal with the outside world is by doing Parse, Don't Validate at the system boundaries. Since that is, and was, my position before this conversation took place, it seems to me that you've set up a strawman (i.e. my position is something other than what I now stated) so that you could destroy it to make your argument for Rust stronger. In reality, if you're doing Parse, Don't Validate, then its really irrelevant if your language has compile-time-checked nullability types or not.

tialaramex 2y ago
> In reality, if you're doing Parse, Don't Validate, then its really irrelevant if your language has compile-time-checked nullability types or not. If you never make any mistakes then there's no value in systems which prevent mistakes. But you're human, so you do make mistakes, Most of us work in larger organisations in which there are many humans and they all make mistakes. Parse, Don't Validate is very much a pattern in which it's crucial to avoid mistakes where maybe you don't have a reference and you need to care about that. In languages where the type system won't help catch that mistake it is likely to leak into production. The other end of this is that people moan about the expense, and that's why I brought up Rust. With the Guaranteed Niche Optimisation Rust says that Option<T> is the same size as T where there's a niche, that means not only references, including the popular string slice reference &str, but many other types. Rust's Option<OwnedFd> is exactly the same size in RAM as the C int would be for the same purpose (typically 4 bytes on a modern system). But your code won't accidentally try to read from a non-existent file descriptor in Rust, because instead of the int being this magic value -1, there is no corresponding OwnedFd, your Option<<OwnedFd> was None.
- lelanthran 2y ago
  > Parse, Don't Validate is very much a pattern in which it's crucial to avoid mistakes where maybe you don't have a reference and you need to care about that. Wait, what? Parse, Don't Validate is a way to make sure that invalid representations of data don't make its way into your system. Null is just one of many invalid data. Parse, Don't Validate does MORE than just prevent nulls, while the approach you are repeating only protects against nulls. > In languages where the type system won't help catch that mistake it is likely to leak into production. You are correct here: Languages with no enforced compilation step (Python, PHP, Ruby, Javascript) can't help even if you do do Parse, Don't Validate. Languages with a compilation step and mandatory types (C, Go, Java, C++, etc) get the benefit of doing Parse, Don't Validate. While the benefit includes protecting against null dereferencing, it also includes protecting against other incorrect representations of the data. In other words, if you're doing Parse, Don't Validate in Go, or C, or Java, etc, there's not much benefit, if any, to be gained from an option type. Once that $THING enters your system, it's already been transformed into the correct datatype and the compiler will ensure correctness, as far as type mismatches against null go.
  - tialaramex 2y ago
    As predicted you decided that since it matters, not having a reference is "invalid". But it wasn't invalid, like I said, maybe you don't have a reference. Only maybe. Either way is valid in this system. The user needs to care which is which. In the languages you prefer (such as C), we can't distinguish this case from the case where we should always have a reference and not having one is a bug, they look the same, the machine can't help us get this right and hopefully the user carefully consults our documentation "NB this value may be NULL". Ugh. Go is a wonderful example of a language that's grossly unsuited to this problem. Instead of "Make invalid states unrepresentable" Go chooses "Make representable states valid". Don't want a default for this type? Too bad, Go insists zero is valid and that's always your default, feel free to name this "DoNotUse_GoIsAWful" if you like, in a large system it'll get used anyway.

tialaramex 2y ago

> In reality, if you're doing Parse, Don't Validate, then its really irrelevant if your language has compile-time-checked nullability types or not. If you never make any mistakes then there's no value in systems which prevent mistakes. But you're human, so you do make mistakes, Most of us work in larger organisations in which there are many humans and they all make mistakes. Parse, Don't Validate is very much a pattern in which it's crucial to avoid mistakes where maybe you don't have a reference and you need to care about that. In languages where the type system won't help catch that mistake it is likely to leak into production. The other end of this is that people moan about the expense, and that's why I brought up Rust. With the Guaranteed Niche Optimisation Rust says that Option<T> is the same size as T where there's a niche, that means not only references, including the popular string slice reference &str, but many other types. Rust's Option<OwnedFd> is exactly the same size in RAM as the C int would be for the same purpose (typically 4 bytes on a modern system). But your code won't accidentally try to read from a non-existent file descriptor in Rust, because instead of the int being this magic value -1, there is no corresponding OwnedFd, your Option<<OwnedFd> was None.

lelanthran 2y ago
> Parse, Don't Validate is very much a pattern in which it's crucial to avoid mistakes where maybe you don't have a reference and you need to care about that. Wait, what? Parse, Don't Validate is a way to make sure that invalid representations of data don't make its way into your system. Null is just one of many invalid data. Parse, Don't Validate does MORE than just prevent nulls, while the approach you are repeating only protects against nulls. > In languages where the type system won't help catch that mistake it is likely to leak into production. You are correct here: Languages with no enforced compilation step (Python, PHP, Ruby, Javascript) can't help even if you do do Parse, Don't Validate. Languages with a compilation step and mandatory types (C, Go, Java, C++, etc) get the benefit of doing Parse, Don't Validate. While the benefit includes protecting against null dereferencing, it also includes protecting against other incorrect representations of the data. In other words, if you're doing Parse, Don't Validate in Go, or C, or Java, etc, there's not much benefit, if any, to be gained from an option type. Once that $THING enters your system, it's already been transformed into the correct datatype and the compiler will ensure correctness, as far as type mismatches against null go.
- tialaramex 2y ago
  As predicted you decided that since it matters, not having a reference is "invalid". But it wasn't invalid, like I said, maybe you don't have a reference. Only maybe. Either way is valid in this system. The user needs to care which is which. In the languages you prefer (such as C), we can't distinguish this case from the case where we should always have a reference and not having one is a bug, they look the same, the machine can't help us get this right and hopefully the user carefully consults our documentation "NB this value may be NULL". Ugh. Go is a wonderful example of a language that's grossly unsuited to this problem. Instead of "Make invalid states unrepresentable" Go chooses "Make representable states valid". Don't want a default for this type? Too bad, Go insists zero is valid and that's always your default, feel free to name this "DoNotUse_GoIsAWful" if you like, in a large system it'll get used anyway.