<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">>>> Practical usefulness:</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">>>> * ES5: JSON stringification of object: `null` means `null`, and `undefined` means "no value, don't include the corresponding key".</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">>>> * ES6: default values in function arguments (and maybe destructuring assignment?): `null` means `null`, and `undefined` means "no value, take the default".</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">>> This is all after-the-fact justification. I understand the usefulness made of this feature now that we have the 2 values, but I wonder if given the choice to start over a newJS would be designed with 2 such values.</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">>Even if the two particular cases I've mentioned were not forecasted when designing JavaScript, it does not diminish the value of the feature. When designing JS, some decisions had been taken, whose usefulness or badness has been understood only after experience.</span><div>
<font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">That we've found uses for these types don't mean that they're the best we could have done. In fact, we could have achieved the same without having a Null type (let alone two!)</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">As for JSON serialisation, `Null` could be a special type for JSON alone, that would not be able to be mixed with other types. And if accessing object properties that are not there threw an Error instead, we wouldn't have to worry about these things.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">In this case, `foo.bar` would always yield a useful value if `foo` is an object, because `bar` is guaranteed to be present in `foo` and to be an actual value (not undefined/null). It can't be mixed with other things, and we have no problems with iterating over `foo`.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">If we are not sure `bar` exists in `foo`, a function would be defined in `foo's` prototype that would return a `Maybe<T>` type. So instead of blindly doing `foo.bar` when you're not sure `bar` exists, you'd use `foo.get('bar') // => Maybe<T>` or `foo.getOrElse('bar', 'defaultValue') // => T | defaultValue`.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">The benefits of this is that we get early errors where it matters, and people are less likely to forget to deal with possible errors in their applications, because dealing with such is made explicit  this still plays well with the delegation semantics, since errors are thrown after we've searched all the prototype chain.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Destructuring assignments could also have an explicit "I know this might not exist, but I want a value anyways" semantics. ES6 Modules have this *because* people want early errors (and for static linking I suppose?).</font></div>
</div>