7 ms·
Let me agree with you but then turn that on its head.
You've argued that having `null >= 0` is the best that JS could do while having a coercion-based semantic
Let me agree with you but then turn that on its head.
You've argued that having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree: this confusing behavior may be the best you can possibly do with a coercion-based semantics. And it's not just this example, either. JavaScript is filled with gotchas, and a lot of them have to do with automatic coercion. For example, did you know there are number and string values x, y, and z, such that x<y, y<z, and z<x?
But if this is really the best you can do in the presence of automatic coercion, maybe that's an argument against coercion.
> having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree
Well, I disagree. You have to add a third condition for this to be the best you can do, and that is that the boolean type has to be two-valued. But that is not a given. Just as numerical types can include infinities and NaNs, a boolean type could include a third value that is neither true nor false. The IF statement would have a third clause to handle this value, something like:
IF condition
THEN [code if condition is true]
ELSE [code if condition is false]
OTHERWISE [code if condition is neither true nor false]
Like ELSE, the OTHERWISE clause would be optional so this would be a backward-compatible change. By default, existing code that encountered non-true-non-false conditions would do nothing.
Are you seriously suggesting that, widgety though JS's implicit type conversions might be, if its booleans had three values then things would be better?
Booleans having only three values would be an improvement for JavaScript where they actually have four : true, false, null and undefined
This is nonsense. If typeof(x) is 'boolean', then x is either true or false.
Now, if you don't know the type of x and try to use it as boolean without being careful, it might look like it has four values. That comes partly from being dynamically typed and partly from performing coercion instead of throwing errors. So one might argue that Javascript encourages people to write code that's not careful, or that it's very clumsy to write careful code in Javascript, but saying booleans have four values is just nonsense.
deleted 9y ago
[deleted]
Yes. Why would you doubt it? (i.e. why would you doubt that I'm seriously suggesting it, not why would you doubt that what I am suggesting has merit)
(Oh, and BTW, before you completely dismiss the idea that my suggestion might have merit, you might want to look me up. I didn't just fall off the turnip truck.)
I am intrigued by your ideas and would like to subscribe to your newsletter.
Jokes aside, a 3 value Boolean conditional could have some useful applications.
FWIW, for the downvoters: you really should look 'lisper up. I'm not sure I agree with him but the incredulity shown here is unwise.
Smart people can still say dumb things.
The down votes are likely for trying to invoke an ad hominem argument. No matter someone's credentials, it's still a logical fallacy and something to be avoided. If he is an authority on the subject, it should show through in his comments. I'm sure he's a very smart and knowledgable person. But there are a lot of smart and knowledgable people here and by invoking his credentials, he's presuming that the people he's talking to are less knowledgable, intelligent or entitled to their opinions. It's insulting and he's earned his downs.
Full disclosure: I downed his 'look me up' post and upped his more substantive posts.
Why not? SQL has three valued logic. It's not a novel idea.
I'm aware that SQL has "bit" values that can be 1/0/null, but that's not exactly three valued logic. Does it really have conditional checks that can have three possible outcomes, or something similar?
Indeed it does, and it's horribly error-prone because people don't actually understand it :/. It can also lead to quite convoluted query logic because you're giving up the "law of the excluded middle"[1] (amongst other things).
For my money, the only sane thing to do with e.g. "null >= 0" is to throw an exception. (Even better would be just rejecting it at compile time, but JS obviously doesn't have that luxury.)
[1] https://en.wikipedia.org/wiki/Null_(SQL)#Law_of_the_excluded_fourth_.28in_WHERE_clauses.29 https://en.wikipedia.org/wiki/Null_(SQL)#Law_of_the_excluded...
EDIT: Ninja edit: I do understand that NaN has 'reasons', but ideally it'd really want NaN == x to trap rather than just doing 'the weird thing'.
That's not a backward-compatible change. Branches that now take either the then or the else branch will take no branch instead. Obviously, that would change the meaning of many programs in ways the author didn't intend by not executing the code in those branches.
>> there are number and string values x, y, and z, such that x<y, y<z, and z<x
Again though < and > are numerical operators as poster pointed out so comparing a number to a string using these operators is... 'nonsensical' if that's perhaps the right term.
Consider checking if object foo > 1. What would that mean?
That's the point. JavaScript lets you do nonsensical operations that are easily detectable as nonsensical, but instead of throwing an exception, it goes out of its way to prevent you from noticing that anything is off.
It took me a bit to dig through the fringe cases to find the combination (or maybe an additional combination?) to pull that off.
x = ''
y = '-Infinity'
z = -1
x < y // true: '-Infinity' (y) doesn't get coerced into a number, so '' < 'any string with at least 1 character'
y < z // true: '-Infinity' (y) compares with a number, so it coerces to -Infinity, which is less than -1 (z)
z < x // true: '' (x) is compared with a number, so it coerces to 0, which is greater than -1 (z)
Thank you for the brain exercise!
P.S. - No one ever use crap like this in production code!
Except 'lisper wasn't making an argument. He was responding to a case of somebody being socially jerkish in a way that was pretty gentle, even for HN's coddling standards. That's important, because downvotes don't fix jerks--only pointing out the behavior does.
Coming in hot with "oh but fallacies, hmm hmm, heaven forfend" when what's being suggested is "maybe don't be a jerk?" is not a great look, don't you think?
> If he is an authority on the subject, it should show through in his comments.
The comment speculating on the "OTHERWISE" clause is the kind of brilliant off-beat thinking that challenges the level of understanding of the reader.
The people scoffing at and downvoting it are, however smart and knowledgeable they may be, ignorant or foolish. If they thought it through they might learn something.
It's a perfectly valid response to say, "Hey wait a minute, I know what I'm talking about here." It's not appeal to authority, and it is certainly not an ad hominem since the people he's talking to have shown that they don't understand.
> brilliant off-beat thinking
Those words must have new meaning since he was citing as an example a language that's existed since the 70s. Ternary booleans are far from a unique or novel concept. The main difference is that for most languages, including Javascript, that third value exists at the variable binding or expression level, not the value level. Other languages that don't allow nulls encode that third value in a Maybe type. SQL, being a thin abstraction over data storage that needs to be able to encode nulls, doesn't make that distinction. That his idea was poorly worded to state that the actual Javascript value would have a third possibility rather than the comparison expression being nullable doesn't add to his credibility. The distinction between an expression evaluation, variable binding and a value isn't exactly a newbie concept, but for someone with the credentials he's claiming, I'd expect him to know it and be more precise.
> since the people he's talking to have shown that they don't understand.
Perhaps you should go back and read the exchange. The comment he was replying to was specifically about the mixture of Javascript and ternary booleans, not just ternary booleans. Also, if you re-read the comment that you're calling ignorant in the context of the authors original confusing of expression evaluations and values there's at least the possibility that he's making a very valid point, albeit in a way that can be read as confrontational. Javascript could already add an otherwise block without adding a third boolean value...all that would be necessary is to allow comparison operators evaluate to null or undefined and then execute the otherwise block in that case. Adding a third value would mean that a boolean variable binding could now have 5 values, true, false, not_true_or_false, null or undefined. That's nonsensical and deserves to be called out. It's bad enough that the language has null and undefined, since it causes a ton of confusion that could have been avoided. Adding some special "not null but sort of null" boolean value would just add more confusion to the language.
> Adding a third value would mean that a boolean variable binding could now have 5 values, true, false, not_true_or_false, null or undefined. That's nonsensical and deserves to be called out.
FWIW, I actually agree with this. There's no need to add a new value. It would be fine with me (within the context of Javascript's already horribly broken design) to use an existing value (null or undefined) as the third "boolean" value.
The part that really matters is that whatever null>=0 returns it should be different from either 1>=0 or -1>=0.
I think we mostly agree, which is why I upped your original comment calling for an otherwise block, despite the unnecessary (or imprecise) call for a third boolean value. As a slightly more verbose option that didn't involve adding a new 'otherwise' keyword, it could also be implemented with a catch block with the comparison operator throwing an exception rather than silently coercing. I find both an improvement on than the current behavior.
I was merely explaining why I downed your other comment. I don't care if you're a fresh bootcamp grad or the former lead on AdWords...your argument is equally compelling. I'm calling it out because I think it discourages people from engaging in conversations where they can learn. If you are who you say you are and have the experience I think you do and someone significantly more junior disagrees with you, it's an opportunity for you to explain your thinking in a way that helps them improve theirs going forward. Instead, you took an expedient and, IMHO, intellectually lazy route. It's a small thing, but it's all part of making our field more welcoming to newcomers. What JavaScript beginner is going to argue with the ex-AdWords lead? Beyond being an appeal to authority, your comment possibly shut down someone's positive learning experience.
And if it seems like I'm quibbling with you or being overly hard on what you've said, that part is definitely about who you are. I feel like those of us who've been in the industry a while (I'm a few years behind you, but I'm still nearing my 20th year doing this stuff) have an obligation to be better about technical discussions and work towards positive conflict, even if the other side seems intent on going negative. It's hard and I fail at doing it constantly, so I say this with the full realization that I'm often the proverbial 'pot' to your 'kettle'.
Re: "their own fault". In one sense, yes, that's true, but this type of reasoning irks me, because you're kind of assuming that the language design is inconsequential -- when it clearly isn't. I could also (somewhat absurdly) also argue that Malbolge[1] is a perfectly reasonable language. After all, if you fully understand Malbolge, it shouldn't be that difficult to write correct programs in it, right?
This is obviously a bit of an Argumentum ad Absurdum, but I think it makes the point pretty well? There are concrete, important differences between languages regarding error-proneness, etc. The reality is that humans are lazy, fallible, etc. and we will make random mistakes, so if we can prevent mistakes (or at least catch them early), then that may be a worthwhile trade-off. Especially for such a trivial case. When was the last time you actually needed "null >= 0" to be true, for example? :)
[1] https://en.wikipedia.org/wiki/Malbolge https://en.wikipedia.org/wiki/Malbolge (pleasantly surprised to see that it has a Wiki entry)
One thing that helps with three-value logic is to insist that all conditionals ultimately have to boil down to just true or false, even if they are using the third value in it. This is the case in C#, which implements three-value using nullable bools. So e.g. if you have this:
bool? t = true;
bool? f = false;
bool? u = null; // "unknown"
Then you can do things like (t & u) or (f | u) or (!u), and it works as you'd expect. But you can't write:
if (t & u) ...
for example, because "if" requires a definite true or false. So e.g. if you want it to execute only if your expression is definitely true, you do:
if ((t & u) == true) ...
etc. Consequently, you don't get silent bugs because a null slips through somewhere - if your expression ends up introducing nulls at some point, you always have to decide what exactly it means for it to be null at the end of the pipeline.
Coincidentally, it also doesn't allow (t && u) or (f || u), for the same reason why it doesn't allow "if" - because the operators are short-circuited, and whether the second operand is evaluated or not has observable side effects, so null/unknown cannot be handled safely.
In SQL, on the other hand, the use of NULL is a conditional implicitly does what I did explicitly above - i.e. NULL is basically treated as FALSE - which IMO is wrong in principle, but more importantly, results in silent, hard to detect bugs.
It seems like this thread has gone several different directions. Surely suggesting that that (null>0) should return null or undefined is a separate topic from suggesting that if() statements have three different control branches?
FWIW, I totally buy the former. If (null>0) returned null, then most things would still work as expected, and you could easily check the result of the comparison to catch unintended behavior. One can easily imagine a world where JS was defined this way from the start, and it'd be pretty much the same language.
The latter (three-way IF control structures) strikes me as waaaay more tenuous - much bigger change, more complexity on the programmer, and no benefits I can see that you wouldn't get from the former bit.