Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No need for 2 "absence representations" #26

Open
DavidBruant opened this issue May 3, 2013 · 14 comments

Comments

Projects
None yet
6 participants
@DavidBruant
Copy link
Owner

commented May 3, 2013

Forked out of #25.
JavaScript has both undefined and null while only one could be enough.

@DavidBruant

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2013

Words from the language creator:

Java has null but only for reference types. With untyped JS, the uninitialized value should not be reference-y or convert to 0.

This makes sense to me. Keeping the issue open nonetheless and I'll write something about it one day. It seems like an interesting piece of information to be aware of if designing a compile-to-JS language.

@medikoo

This comment has been minimized.

Copy link

commented May 5, 2013

I disagree with that. null is confirmed lack of value, undefined is unknown value (never defined).
In data oriented projects I work with, there's clear distinction between those two types.

@michaelficarra

This comment has been minimized.

Copy link

commented May 5, 2013

Ah, so JavaScript values are Maybe Maybe Ts. undefined is Nothing, null is Just Nothing, and actual values are Just Just v. I've never thought of it like that.

@heapwolf

This comment has been minimized.

Copy link

commented May 5, 2013

@michaelficarra undefined indicates an absence or a lack of initialization. null values indicate an intentionally empty value on a variable that has been initialized. I find this is pretty reasonable in the context of this language.

@azder

This comment has been minimized.

Copy link

commented May 11, 2013

This shouldn't be a regret, but a win for the language. Having both undefined and null makes it so much easier to make those 3 in 1 accessor methods (setter, getter and deleter) discriminating if the value parameter is undefined (getter), null (deleter) or some primitive or object (setter). Example: https://gist.github.com/azder/5559489

@Gozala

This comment has been minimized.

Copy link

commented Jun 27, 2013

Some how all other languages do just fine without distinction not existing values and intentionally emptied values. If one for some reason wants to empty a value but signify the fact that it exists never the less usually new special Type / Constants are used in other languages that do job well, also discouraging that pattern.

So sure there is a difference between null and undefined, but that's exactly an issue adds complexity of differentiating things that don't need to be different.

@azder

This comment has been minimized.

Copy link

commented Jun 27, 2013

The same argument can be used on the reverse: JavaScript has both null and undefined and does just fine with that distinction. The developers don't, out of probably subjective reasons.

Now,

usually new special Type / Constants are used in other languages that do job well

special type like... lets see.... undefined type in JavaScript or a constant like the undefined (in ES5 strict though) ???

I'd argue that even those languages with only null would've been better off without it (using Null Object Pattern) or at least implementing safe navigation operator.

null and undefined should've been made into Null Object Pattern-ed objects.

@Gozala

This comment has been minimized.

Copy link

commented Jun 27, 2013

My point is Null objects are quite exotic, JS makes them mainstream and more things to comprehend is rarely makes things simpler.

@azder

This comment has been minimized.

Copy link

commented Jun 27, 2013

Simple languages produce complex frameworks, complex languages produce simple frameworks. It is only a matter of subjective preference where you want the complexity in.

And why are Null objects exotic, but CONSTANTS not? Simply because they don't teach you that pattern at school.

So, exotic is only what you don't quite understand. And not understanding null and undefined should be a greater regret than having them both ;)

@Gozala

This comment has been minimized.

Copy link

commented Jun 27, 2013

Take a look at lua very similar to JS with much less misfeature than in JS (including this one). Does great without Null objects or special Constants etc.. Very simple designed such that you don't need to have that distinction. It's just a good language design! For example clojure data structures are immutable (like strings in JS) but language designed such that it's just feels great, in contrast try writing JS without mutations and it will be a pain. My point is sure every feature can be justified, although some can be just simplified.

Either way I don't feel like continuing this discussion as it clearly isn't taking us anywhere. Claiming that only JS got it right is just ridiculous, all good ideas are usually adopted by new languages that come after, I'm afraid this one does not seems to pick up.

@medikoo

This comment has been minimized.

Copy link

commented Jul 8, 2013

@Gozala Looking from right angle we can say that concept of null and undefined exists in most languages.
The differences are:

  1. When you try to access undefined variable or property, most languages throw and JavaScript returns special undefined value.
  2. In JavaScript we can assign undefined as a value to property or variable.

While I find 1 as expected behavior, which I like in JavaScript and definitely wouldn't change, 2 is indeed controversial thing, we're probably questioning.

I think it would be more logical if assignment of undefined would have no effect, but deleting the variable would clear it's property, so:

var x; // x === undefined
x = 3;
x = undefined; // No effect, throw in strict mode
delete x; // Brings back x === undefined

Currently it's exactly opposite, delete on local variable has no effect and throws in strict mode, and assignment of undefined brings back undefined state to local variable.

Same way with properties, but here delete works as intended, it clears property which then fallbacks to value of same property of its object's prototype.
However JavaScript allows us also to assign undefined to property, through that we can shadow lower prototype value with undefined. Looks interesting, but honestly I don't see a real use case for that, it would be totally fine if we could shadow properties only with null and other real values, and assignment of undefined would have no effect as I demonstrated above with local variables.

So reassuming both are needed, what's controversial is that undefined works as any other value and that's confusing.

@Gozala

This comment has been minimized.

Copy link

commented Jul 8, 2013

There are languages where nil is used in cases where JS uses either null or undefined (for example take a look at Lua). Works great and no one really misses distinction between "not yet existing" and "not existing value". All I'm saying JS could be a lot simpler if it did the same.

Also please do not explain me difference between null & undefined I know it very well, I just think there's a very little value to it to justify it's existence and added complexity to a language.

That being said, I'm happy(more honestly sad) to see so many people be so passionate about this (miss)feature.

@medikoo

This comment has been minimized.

Copy link

commented Jul 9, 2013

@Gozala in data related logic it's sometimes important to know, whether value is intentionally null or has was it never defined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.