> Do programming languages really need any of these two?
"Need," no, but when this distinction is useful, it's really useful. There's no other way (in JS, at least) to distinguish between "no value set" and "it has been set but not to a real value."
A common example is inbound JSON data: when checking for property X, it's "undefined" if it's not set at all, and "null" if the property was set to null via JSON. JSON doesn't have "undefined," and uses "null" in that context. That distinction can be used to assign a non-value (null) to a property name which might otherwise be inherited via the prototype chain and cause confusion.
Hmmm... that example suggests, because the engine will have native JSON support, that i'll _need_ a "null" value whether or not i've also got an "undefined" value.
> How do you accurately model real world problemds where nulls happen without this entity?
After having considered JSON, it seems that both null and undefined are necessary in this frame so that consumers of the json can differentiate between "property not set" and "property set to a non-value."
This framework's JSON support is still on the TODO porting list from its predecessor, so that aspect hadn't yet come up in the day-to-day development.
"Need," no, but when this distinction is useful, it's really useful. There's no other way (in JS, at least) to distinguish between "no value set" and "it has been set but not to a real value."
A common example is inbound JSON data: when checking for property X, it's "undefined" if it's not set at all, and "null" if the property was set to null via JSON. JSON doesn't have "undefined," and uses "null" in that context. That distinction can be used to assign a non-value (null) to a property name which might otherwise be inherited via the prototype chain and cause confusion.
Hmmm... that example suggests, because the engine will have native JSON support, that i'll _need_ a "null" value whether or not i've also got an "undefined" value.