if null was the billion dollar mistake https://hackernoon.com/null-the-bil...

then what is javascript with null and undefined

We need a movie where the protagonist wears a yellow jump suit with a black stripe. Their goal is to eradicate null for destroying their software projects. The show will be called "Cull Null".

I don't quite buy this argument.

When I tried using the null object pattern. I then ran into another problem.

"Is this null object valid? or is this supposed to be null"

I like having an unset state for my variables. It's useful in lots of places. Maybe I'm just not programming hard enough for it to matter.

Repeating the mistake and inventing a new one.

@Lensflare at least you can't crash because you called a method on a null object in js.

I've heard the "null was a mistake" argument so many times and I've never agreed once. These guys are probably smarter than me though, so evidence would suggest I'm part of the problem.

I just think that "nothing" is something and we need a way to represent that in code.

@AlgoRythm Yes, that's why we have Option or Maybe (depending on dialect). The problem is that in languages with null, any data is allowed to be absent, or alternatively what is and isn't is decided by low level details regarding storage.

And what's worse, most of the time nullable values are null by default, as if the most natural state of all optional relations was the empty state, even though quite often even if a value is allowed to be missing that is still the rare case that's worth explicitly stating.

It's true that *some* data *may* have *some* relations that are optional. Most relations however are not, and therefore the absence of most relations should be unrepresentable.

Js has no type checking and generally tries to continue doing something in cases that are almost definitely invalid and produced by programmer error (such as adding a function to a string), or at least defer the inevitable crash until preferably some but not all state has been committed. Null is not its biggest issue.

Still doesn't beat Python in malicious compliance though. Python throws certain kinds of statically identifiable syntax error only when you call the offending function.

@lorentz I get the arguments behind, and love, static typing. But when it comes to the default of objects being null, that just makes sense to me. What else would it be? Garbage? Zero? Those would be even harder issues to spot, because they're valid values. Null is a very convenient way to know something's in an empty state.

JavaScript - fuck me - has an even nicer system where it defines the difference between both null and undefined. While this itself isn't a solution to the problem at hand, we can learn from it. Maybe something like null and unset, where null explicitly means empty, and unset explicitly means uninitialized memory.

In general, I really do agree with null's existence. Having an explicit way to indicate nothingness is better than magic numbers such as -1 = does not exist

@AlgoRythm have you considered simply not having uninitialized data?

I used Rust for a full year before I encountered the first time I needed to allocate something that I simply couldn't initialize - I wanted to write a generic function that populates a vector (smart array) from an iterator of known length in reverse order.

@lorentz I've considered it, but my instinct tells me that if it were so simple as that, it would be the default no matter what the language allowed. I have no specific examples for you, but off the cuff, I could see this being specifically difficult to accomplish in async programming where some things literally might not exist yet, but may at any moment.

@AlgoRythm In async programming you _especially_ want to be very explicit about what's allowed to be null, so an Option is preferable. I'd say that implicitly optional values are only justifiable in isolated, small scenarios that are easy to reason about.

Actually, thanks to this discussion I researched my situation with the reverse-populated Vec a bit more and apparently I can cast a VecDeque to a Vec which generally doesn't move anything if I only interacted with one end of the deque so this is apparently also doable without dealing with uninitialized values.

@AlgoRythm What if null is a legal value but it must be explicitly assigned to the variables and fields you don't have a value for upon construction? Now when someone gets a null pointer exception and starts looking for the source, they can be presented with a nice list of all nulls produced - because it's now produced - in the relevant modules and they can see which one managed to dodge all initialization steps.

@lorentz I can't say I'm 100% convinced, born anew, but I can definitely say that I understand the argument against null more now and agree more.

As someone, who worked with the empty pattern to remove null.

Null is a good thing

@KDSBest you don’t get it. Null is not the problem. The problem is when everything can be null and is null by default.
Replacing null by empty or whatever doesn’t solve anything.
You can have a look at Rust, Swift or Kotlin to see how the null problem is solved.

To clarify, the billion dollar mistake isn't the word "null", it's the normalization of implicit separation between the creation and initialization of references.

@Lensflare rust is pretty much the same way we implemented the empty pattern.

@iceb what's the null object pattern?

@YADU it's mentioned in the article. Basically create a special empty object to represent to avoid crashes

https://en.wikipedia.org/wiki/...

@iceb that seems bad most of the time.

I'd rather use an option type or something...