3 ms·

I must say that this "billion dollar mistake" about nulls really baffles me. What's the mistake? We invent new languages almost daily and none of them have eve

by prerok 2y ago

I must say that this "billion dollar mistake" about nulls really baffles me. What's the mistake? We invent new languages almost daily and none of them have ever resolved the problem. I mean, when you start with a pointer, it's uninitialized. Setting it to null is much better than having it point somewhere, where there might be incorrectly interpreted data. So, null. We have Java, suffering the same problem, Golang suffering the same problem and Rust, where you have the same problem if you call unwrap, without checking that all code paths ensure you have the value populated. Seems to me this is an inherent problem of using an uninitialized value... so, what is the mistake?

tialaramex 2y ago
> I must say that this "billion dollar mistake" about nulls really baffles me. What's the mistake? The mistake is that Nothing isn't a kind of thing. It's a categorical mistake, enshrined in many programming languages because it was easy and they didn't realise it was a bad idea, that's what Tony's talk is about - he's the one who made the mistake originally. > I mean, when you start with a pointer, it's uninitialized You're talking about a language implementation detail. Indeed I'd say plainly, a language defect, particularly notable in C (and so C++) where it continues to cause problems. > We have Java, suffering the same problem That's correct, all non-primitive Java objects can be null instead. > Golang suffering the same problem That's correct, Go chooses "make representable states legal" rather than "make illegal states unrepresentable" and so every type must have a legal "zero" state. > and Rust, where you have the same problem if you call unwrap, Nope. Try it. Call "unwrap" on a Vec, or a HashMap, or a File. You can't, there is no such method, it's a method on Option. > Seems to me this is an inherent problem of using an uninitialized value... so, what is the mistake? Goodness no. An actual uninitialized value by default would be a design mistake. They're currently trying to fix this mistake for C++ 26. If for performance reasons you need to delay initialization you need a trick like Rust's MaybeUninit<T> wrapper. You certainly can't paper over it with null.

by prerok 2y ago

tialaramex 2y ago

> I must say that this "billion dollar mistake" about nulls really baffles me. What's the mistake? The mistake is that Nothing isn't a kind of thing. It's a categorical mistake, enshrined in many programming languages because it was easy and they didn't realise it was a bad idea, that's what Tony's talk is about - he's the one who made the mistake originally. > I mean, when you start with a pointer, it's uninitialized You're talking about a language implementation detail. Indeed I'd say plainly, a language defect, particularly notable in C (and so C++) where it continues to cause problems. > We have Java, suffering the same problem That's correct, all non-primitive Java objects can be null instead. > Golang suffering the same problem That's correct, Go chooses "make representable states legal" rather than "make illegal states unrepresentable" and so every type must have a legal "zero" state. > and Rust, where you have the same problem if you call unwrap, Nope. Try it. Call "unwrap" on a Vec, or a HashMap, or a File. You can't, there is no such method, it's a method on Option. > Seems to me this is an inherent problem of using an uninitialized value... so, what is the mistake? Goodness no. An actual uninitialized value by default would be a design mistake. They're currently trying to fix this mistake for C++ 26. If for performance reasons you need to delay initialization you need a trick like Rust's MaybeUninit<T> wrapper. You certainly can't paper over it with null.