5 ms·

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 truthfu

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.

throwaway0665 2y ago
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.
- afiori 2y ago
  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.
8n4vidtmkvmk 2y ago
This is handy, and I take advantage of it all the time. Not sure I'd call it a strength so much as a shortcut so that the botchery isn't as painful.
jamil7 2y ago
This might be useful in limited situations in which you don't control something you're interaction with, but otherwise it seems like a codesmell.
boredtofears 2y ago
which is exactly why you normally don't use double equals
brabel 2y ago
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.
- kazinator 2y ago
  The situation of multiple falsy values is more like Javascript than Common Lisp. If you have only one false value, it means that this test if (str) can mean "we have a string object here". If we make str take on the false value, such as nil, then that is not a string. If an empty string is false, then we cannot use this test. An empty string being false encourages the poor practice of using empty strings to mean "there is no value here". You might as well code in Bash.
  - brabel 2y ago
    > 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.
- DemocracyFTW2 2y ago
  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?
DemocracyFTW2 2y ago
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.

throwaway0665 2y ago

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.

afiori 2y ago
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.

8n4vidtmkvmk 2y ago

This is handy, and I take advantage of it all the time. Not sure I'd call it a strength so much as a shortcut so that the botchery isn't as painful.

jamil7 2y ago

This might be useful in limited situations in which you don't control something you're interaction with, but otherwise it seems like a codesmell.

boredtofears 2y ago

which is exactly why you normally don't use double equals

brabel 2y ago

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.

kazinator 2y ago
The situation of multiple falsy values is more like Javascript than Common Lisp. If you have only one false value, it means that this test if (str) can mean "we have a string object here". If we make str take on the false value, such as nil, then that is not a string. If an empty string is false, then we cannot use this test. An empty string being false encourages the poor practice of using empty strings to mean "there is no value here". You might as well code in Bash.
- brabel 2y ago
  > 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.
DemocracyFTW2 2y ago
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?

DemocracyFTW2 2y ago

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.