For me, the flexibility that comes from loose typing is one of the biggest strengths in JavaScript. For example, using loose equality (double equals) is truthful for both null and undefined, but false for 0.
I consider loose equality to be a bug not a feature. It's nice that `undefined != null` is true but to me it's a "trick" and not something that I want to see used all that often. It's really not that much extra to do `x !== undefined && x !== null` and keep the code intuitive.
As long as you are comparing with a literal then == with nulls is very intuitive.
I agree that if it did not exist it would be not worth to be added and that almost every other use is bad, but != null and == null are very easy to learn idioms.
I like how Groovy defines truth.
Anything that is not one of these is true:
* 0
* null
* false
* empty String/collection
It may seem like too many rules, but it's very intuitive.
For example, it's common in Java to do:
if (str != null && str.length > 0)
Or:
if (str != null && !str.isEmpty())
There's even a apache.commons helper function for that:
if (!StringUtils.isNullOrEmpty(str))
While in Groovy that's just:
if (str)
It's just handy. It also reminds me of Common Lisp, where `false` is defined to be the empty list itself! It just makes sense and in Common Lisp code the same idiom can thus be used, which makes it very easy to read and write.
> An empty string being false encourages the poor practice of using empty strings to mean "there is no value here".
That is not bad practice, as I said before, you almost always want to only process non-empty Strings, but sometimes an empty String comes in from user input or whatever and you either have to check it everywhere like in Java, or in Groovy that is just the default... you can still do 'if (str != null)' to be more explicit, but in my experience that is almost never what you want. Bad practice is making the more usual case look more unusual.
Also, it's nothing like JS because in JS empty lists and maps are `true`! The commonality with Common Lisp is exactly that "not being empty" is what the concept of true represents.
This is so arbitrary. State what you want, make it explicit.
if ( list_of_names ) { ... }
doesn't make any sense at all. For one thing, `list_of_names` should only be allowed to be `null` in exceptional cases; disallowing it removes a whole class of errors.
Second, imagine you have two handy operators / functions `not` and `is_empty`, then the above becomes either
if ( not is_empty list_of_names ) { ... }
or
if ( is_empty list_of_names ) { ... }
as the case may be. In which universe is that too long for a load-bearing program that people depend on?
Loose typing and truthy/falsy values are a disaster waiting to happen, not least b/c it obfuscates intention and also because every language that has it at all has slightly different rules. If I had a say I'd want an opt-in for JS that makes it illegal (a runtime error; compilation error for constants) to have anything but a Boolean in the conditional part of an `if` statement.
