4 ms·
> And then someone comes along and points out a lesson they didn't implement and everyone goes "Oh. Oops." I don't think that's the case here. It's not "Oh. O
by mrkeen 2y ago
> And then someone comes along and points out a lesson they didn't implement and everyone goes "Oh. Oops."
I don't think that's the case here. It's not "Oh. Oops". It's "Yes, we like it that way".
I think that readers of Java source code have the right to see a BufferedReader, and think "That's a BufferedReader".
Writers of Java source code have decided that that's too onerous. They would like the 'opposite' right - of taking a 0x0000, and declaring that to be a BufferedReader. That's really the core of it.
The debates always involve adding extra types, annotations, IDEs or external tooling into the mix, as if nulls naturally arise in nature, and some genius-level engineering is required to mitigate against them. But people routinely include them in their source code. I don't think you can win the war on accidental nulls if you can't swing opinion on deliberate nulls.
- 12_throw_away 2y agoI mean, I don't know if nulls "arise in nature" exactly, but null pointers arise quite naturally in computer memory when setting stuff up and tearing stuff down. I agree that it's vastly preferable, in a PL, for nulls to be semantically distinct from live pointers. But still, null pointers model something real, and it took a lot of research to get us to the point where we could build languages that can make the semantic distinction.
- mrkeen 2y agoI completely accept them in an operating systems context. I have a soft spot for C. But they have no business in application programming. As you say, they are about the state of your computer's memory, (not your application!) Then of course Rust came along and I'm questioning even that level of tolerance for them.