Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

The problem isn't really that null isn't an object, it's that the type system allows any object reference of a particular class to also be null.

After using Typescript for the past couple years, it's such a joy when you define a variable of type Foo and know it won't contain null. Granted, TS also has to deal with undefined vs null weirdness (and even more weirdness in that an object not containing a property is subtly different from that object property being undefined), but in general the support for "optional" typing works very well.

Java tried to add things like the Optional class, but without first-class language support it's just a mess and you have developers doing crazy things, like having a method return an Optional that will sometimes also return null, by design (yes I've actually seen this).

View on HN

I'm writing some powershell at the moment, after a few weeks of work I realized that sometimes my return types for some functions would change even though I explicitely declare them (for exemple a 'hashtable' would become a 'System Object[]' which is short for 'table full of garbage').

Turns out some ops without assignment and some printed messages would go into the pipeline (as in, to be piped in with `|`) and become part of the return value of the functions ; to make that work powershell changes the return type, appends the message or the non-assigned op to the hashtable and returns that as an object table.

To this day I'm not aware of any language doing this kind of thing, but maybe js does ? Anyway I fear I'm going to get some grey hair because of that.

> having a method return an Optional that will sometimes also return null

Wow that's terrible. When Optional landed in Java (8?) I came to the conclusion that the point was to use it as a contract from the developer of a method: "I return an Optional in this method so I guarantee it won't ever be null". If this is not respected, there's absolutely no reason to use Optional.

Totally agree, which is why I was baffled when I saw this code. But it goes to show that if something isn't enforced at the compiler level, "clever" developers will find a way around it.

> it's such a joy when you define a variable of type Foo and know it won't contain null

Why is that? I've never seen a good explanation of this point of view.

This all feels like just syntactic sugar to me. Sure you might not have null, you might have an empty object or any other variation. At the end of the day, if a value was expected to be available but is not available (for whatever reason), reliable code is going to have to deal with that absence. No matter how it is expressed.

The point is that every function is explicitly telling you if it can or can not return null. Your editor and typechecker will tell you if you need to handle null after calling that function.

If you have a non-null returning function that you need to change so it can return null, then your typechecker will tell you all the places where you now need to handle the new null return.

It doesn't need to be a very large codebase before this becomes a very useful tool to help when refactoring.

Seeing all this discussion reinforces the idea that no new programming language should have this "every type implicitly contains null" thing

Yes, sum types and generics solve this nicely.

It's a shame Java was designed before they had generics, so the core of the language can't take advantage of them.

It’s still possible to do something like TypeScript, where everything is like generics in Java. But Java try to be consistent, while TypeScript purposefully not. There are a ton of features in TypeScript which are awesome, but it breaks in some rare cases. Java won’t allow that.

Also no new languages should default to mutable variables, fields, and types, when the language supposed to be in the same field as Java, eg. large enterprise services. And for both problems, they should be consistent, because now they are mess (there is an example in the article regarding nulls in collections, and for mutability a great example is collect(Collectors.toList()) vs toList()).

Tony Hoare calls it (null) his Billion Dollar Mistake.

https://www.infoq.com/presentations/Null-References-The-Bill...

We use None in Python - is that similar?

Yes, and no dynamically typed language can do much better than this, because in those your value of type X can always be another type (and you need to defensively check if you want to catch errors)

Reply on news.ycombinator.com