Hacker News new | ask | show | jobs
by cle 3530 days ago
performance
1 comments

There's no reason it shouldn't be a typed null though. It doesn't have to be a tagged Option type.
I'm talking about practical reasons to use null.

Theoretically it's not necessary, but given real-life constraints, there are most definitely times when null is more appropriate than e.g. Java's Optional.

I agree! I'm just saying there's no theoretical reason for null not to be typed (which is quite different from Optional).
Then we agree :). From a correctness perspective, nulls are awful.

My point was not specifically aimed at typed nulls and compiler optimization, it was that there will always be practical constraints that force us to compromise static guarantees in order to get things done in a reasonable amount of time. As software engineers, our problems are first practical before they are theoretical.

That's an extremely weak argument. Java's Optional is broken and should never be used.
If that is true, then it's another example supporting my point.
No. Java messing things up as usual, doesn't have any broader impact on the usefulness of the concept.

Error handling with null is wrong and broken, regardless of whether the null is "typed" or not.

null might have some very limited other uses, but they will never compete with those structures designed for error handling, because they do something fundamentally different.

My argument is practical, not theoretical. Platitudes and ideals are disposable when you have to actually build something.
Could you expand on this?
Optional#map is implemented incorrectly.

   someOptional.map(a).map(b) NOT EQUAL TO someOptional.map(a.andThen(b)
Ah, that's unfortunate.

Because of the order in which side effects occur, or is there something else as well? (I haven't Javaed in anger since before Optional).