Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: The Curious Case of null >= 0

blog.campvanilla.com

Post reply on HN
Print view View original

41–50 of 152 posts

Re: JavaScript: The Curious Case of null >= 0

#41

Post by irascible »

zzalpha wrote: post #11
outoftacos wrote: post #8

Earlier quoted context omitted.

Yes I can contrive examples in any language that are nightmarish. Fortunately we manage to muddle through somehow, at least those of us who have work to do in lieu of walking through trivia to prove how smart we are to other hackers.

Okay. Find an equivalently surprising example in... Let's use the other poster's choice, python. I'll wait. Edit: didn't have to wait long, way to go Python! Maybe I'll just claim it probably has fewer of these types of bizarre idiosyncrasies? I hope it has fewer... I'm always baffled by JavaScript apologists... Look, your baby is ugly. We know it's ugly. You know it's ugly. But if we point out the problems, hey, may…

If everyone else's baby is ugly, maybe it's your baby who's ugly.

Re: JavaScript: The Curious Case of null >= 0

#42

Post by mistercow »

nine_k wrote: post #26
alangpierce wrote: post #10

Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…

Aggressive coercion in an attempt to execute clearly faulty code is exactly the problem.

The most common mistake I see when people talk about JS quirks is to assume that this kind of feature is always about fault tolerance rather than convenience.

For example, many languages treat conditions as "if nonzero". From a certain perspective, you could argue that

  if (i--) {
is "clearly faulty code".

From another perspective, you would say it's a shorthand whose meaning is obvious to anyone familiar with the rules of the language.

In my view, JavaScript's sin is that its rules are complicated, and it's difficult to statically analyze, so tools intended to guard against its pitfalls can only do so much.

Whether or not the complicated rules are about faulty code is pretty irrelevant. ASI is an error correction mechanism, but its pitfalls are easy to detect, so in modern environments it doesn't matter. The behavior of comparison operators seems to me like more of a convenience feature, but it's still a problem; the rules are easy to forget, and only a very draconian linter rule can protect you.

Re: JavaScript: The Curious Case of null >= 0

#43

Post by YSFEJ4SWJUVU6 »

alangpierce wrote: post #10

Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…

>Also worth noting that it's not always true that `a >= b` means `!(a = null` and `'a' That also means that the concluding section of the article is simply wrong. To be honest, it's a pretty poor read – a waste of many words to explain a spec that's pretty straightforward itself, and ending up in a major misunderstanding.

Re: JavaScript: The Curious Case of null >= 0

#44

Post by lisper »

justinpombrio wrote: post #35
alangpierce wrote: post #10

Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…

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 kn…

> 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.

Re: JavaScript: The Curious Case of null >= 0

#45

Post by wavefunction »

justinpombrio wrote: post #35
alangpierce wrote: post #10

Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…

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 kn…

>> there are number and string values x, y, and z, such that xAgain though 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?

Re: JavaScript: The Curious Case of null >= 0

#47

Post by YSFEJ4SWJUVU6 »

microcolonel wrote: post #39
deburo wrote: post #36

Earlier quoted context omitted.

But the code using twisted features is hard to maintain afterward. You will have to put comments around them just to be sure the next guy (it might even be the author himself) doesn't waste its time understanding what the hell the code is doing.

> But the code using twisted features is hard to maintain afterward. let a = 0; for (const record of records) a += record.bool; What's so bad about this? (aside from mutable accumulator, but that can be restricted to one scope). The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type. If anything, the solution is to fold Boolean and null into Number to begin with. > Y…

Non-zero does not imply `1'.

>The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type.

There has been a boolean type in the current standard for C for longer than some of the younger people here have been alive.

Re: JavaScript: The Curious Case of null >= 0

#48

Post by ratboy666 »

infogulch wrote: post #3

Dynamic typing is a nightmare.

No. In SNOBOL4 (one of the first dynamic typing languages) -- ident(x) yields true if x is "null", eq(x) is true if x is 0, gt(x) is ">" and ge(x) is ">=". The program "code" is a repl.

Notice -- free format dynamic typing, and, it gets it "right". This language/run-time was originally from the late '60s, last official update in 1975 (with some updates in the intervening decades).

Yes, according to the Javascript spec, the JS behaviour is correct. However, something as old as SNOBOL4 should have taught us that keeping type converting numerical operators dis-similar from object comparision would be good: "==" and "===" vs ident() and eq() and then relating ge() le() etc to the numeric class of operations consistently.

  : fred@dejah wittgenstein $; code
  The Macro Implementation of SNOBOL4 in C (CSNOBOL4BX)   Version 2.0
      by Philip L. Budne, January 1, 2015
  SNOBOL4 (Version 3.11, May 19, 1975)
  BLOCKS (Version 1.10, April 1, 1973)
    Bell Telephone Laboratories, Incorporated
  EXTENSIONS (Version 0.25, June 16, 2015)
    Fred Weigel

  No errors detected in source program

  CODE (TUE AUG  4 10:28:58 EDT 2015)
  RUNNING ON CSNOBOL4 MAINBOL WITH SPITBOL, BLOCKS, EXTENSIONS
  ENTER SNOBOL4 STATEMENTS (TRY ? FOR HELP)
  5,541,616 BYTES FREE
  CODE: ident()
  SUCCESS
  CODE: ident(0)
  FAILURE
  CODE: eq(0)
  SUCCESS
  CODE: eq()
  SUCCESS
  CODE: gt()
  FAILURE
  CODE: ge()
  SUCCESS
  CODE:quit
  Normal termination at level 1
  code.lss:660: Last statement executed was 938
  SNOBOL4 statistics summary-
          5.384 ms. Compilation time
         90.585 ms. Execution time
          20577 Statements executed, 121 failed
          20004 Arithmetic operations performed
            122 Pattern matches performed
              2 Regenerations of dynamic storage
         29.481 ms. Execution time in GC
              0 Reads performed
             10 Writes performed
       4402.237 ns. Average per statement executed
        227.157 Thousand statements per second
  : fred@dejah wittgenstein $;
and, keeping in the spirit:

  CODE: ge('a')
  EXECUTION ERROR #1, Illegal data type
  FAILURE
Allow the explicit capture of "type" errors. We knew this in 1975. Why was this forgotten?

Re: JavaScript: The Curious Case of null >= 0

#49

Post by microcolonel »

YSFEJ4SWJUVU6 wrote: post #47
microcolonel wrote: post #39

Earlier quoted context omitted.

> But the code using twisted features is hard to maintain afterward. let a = 0; for (const record of records) a += record.bool; What's so bad about this? (aside from mutable accumulator, but that can be restricted to one scope). The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type. If anything, the solution is to fold Boolean and null into Number to begin with. > Y…

Non-zero does not imply `1'. >The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type. There has been a boolean type in the current standard for C for longer than some of the younger people here have been alive.

Wow, I would never have known about stdbool. I have never seen it used (explicitly), even though it's been around since I was two years old. Thanks for bringing this to light! :- )

Nonetheless, bool or _Bool (aside from having implicit saturating arithmetic and assignment) is a one-bit integer type. It seems it mostly just formalizes the (implied, fictional) narrowing conversion involved in testing conditions, which is probably why I've not seen it used explicitly. The macros true and false seem to expand to 1 and 0 respectively.

Re: JavaScript: The Curious Case of null >= 0

#50

Post by __s »

alangpierce wrote: post #10

Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…

Yet 1 == "1". & comparisons also apply to string/string not through numerical conversion
Post reply on HN