4 ms·

It's not just Java. It's C, C++, Ruby, Python, Go, BASH, C#, Javascript, PHP, PERL... It's about making our systems human-tolerant. Humans are absolutely terri

It's not just Java. It's C, C++, Ruby, Python, Go, BASH, C#, Javascript, PHP, PERL... It's about making our systems human-tolerant. Humans are absolutely terrible when it comes to consistent (or even correct) behavior, so we must design our systems such that the path of lowest cognitive load is also the path of highest safety and least astonishment. For example, C++ has the concept of a const method. And that's great, because you can label which methods won't mutate an object's data. But it's actually backwards. It should be that mutator methods must be marked as such (because they're the ones with a higher likelihood of causing problems), whereas any non-marked method is assumed to be non-mutating. In Rust, you must specially mark mutable objects. In Kotlin, you must specially mark nullable things. Each of these newer languages is taking on some of the lessons learned, but nobody is taking a serious holistic look at human psychology and how it contributes to system failures - it's always just a few pieces here and there that the designers had learned along the way. And then someone comes along and points out a lesson they didn't implement and everyone goes "Oh. Oops." You don't get that in civil engineering because the lessons have been codified (and people who skimp out on them are liable). Psychology really needs to have more of a center focus when designing software systems, because we can't take the human fully out of the works.

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 ago
  I 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 ago
    I 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.
kazinator 2y ago
I didn't mean to imply there's just one village learning about boiling water killing germs.

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

kazinator 2y ago

I didn't mean to imply there's just one village learning about boiling water killing germs.