I'm not the author, but:
> Or perhaps you meant null pointers.
A major problem in languages like Java is that objects can always be null. A better solution would be to force strict null checks a la Typescript, where if you want to take or return an optionally null reference, you have to explicitly encode that property in the type of the variable.
NullPointerExceptions are frankly a really stupid thing we have to deal with. A proper type system could check for that at compile time.
> but you're talking about RTTI, or "reflection"
OP is talking about ML-style type destructuring, which is kind of the opposite of this.
> I don't understand the obsession with immutable variables.
Mutating variables leads to all kinds of invisibile problems and makes the code a lot harder to reason on. When I write Java, most of my variables are final, the author is right that we should be taking the opposite convention a la Rust, variables should be immutable by default with mutability explicitly annotated.
> Or perhaps you meant null pointers.
A major problem in languages like Java is that objects can always be null. A better solution would be to force strict null checks a la Typescript, where if you want to take or return an optionally null reference, you have to explicitly encode that property in the type of the variable.
NullPointerExceptions are frankly a really stupid thing we have to deal with. A proper type system could check for that at compile time.
> but you're talking about RTTI, or "reflection"
OP is talking about ML-style type destructuring, which is kind of the opposite of this.
> I don't understand the obsession with immutable variables.
Mutating variables leads to all kinds of invisibile problems and makes the code a lot harder to reason on. When I write Java, most of my variables are final, the author is right that we should be taking the opposite convention a la Rust, variables should be immutable by default with mutability explicitly annotated.