Hacker News Reader

Comment by vvoyer | Hacker News Reader

I stopped at the first example (true + false).

If you write code like this, you have bigger problems than using JavaScript. For most of the examples, it's like saying "Here's what happens when you plug a fan to a faucet". There's no point really.

JavaScript is weird just like any other language can be weird when you use it in weird ways. And yes, it's certainly one of the weirdest.

If you want to talk about things weird in JavaScript, let's talk about ES modules in Node.js and the Browser, or the number of decisions you have to make to bootstrap a simple web app in JavaScript, and how a language written in 10 days is shipped to billion of devices today.

But, this kind of content, (while well made technically) is always the same one about JavaScript.

View on HN

Not really, it's a nice shorthand for "exactly one of these must pass":

  x = checkFoo()
  y = checkBar()
  z = checkBaz()
  if (1 === (x + y + z)) {
      ....
  }

It's a rare construction but I have used it intentionally once or twice in the past decade.

> I stopped at the first example (true + false).

So you never did something like this:

  x = performCalculation(getParam1())
  y = performCalculation(getParam2())
  sum = x + y

only to discover that "performCalculation()" sometimes returns a boolean instead of a number? JS is a dynamically typed language after all and functions like

  function f(x) {
    if (x >= 0) {
      return Math.sqrt(x)
    } else {
      return false
    }
  }

are perfectly valid. If you use a 3rd party library that uses return values like this, you might run into such case without realising it.

Sure, you won't explicitly write "true + false", but "f(x) + g(x)" is not uncommon and might indeed evaluate to "true + false".

I've not run into that kind of issue in years. Read the docs of the function you're attempting to call.

Also, in this case, the function should return NaN so it's not polymorphic.

> Also, in this case, the function should return NaN so it's not polymorphic.

Sure. But what if that's function comes from a 3rd party component that doesn't have great documentation or relies on another package and thus a behaviour like this simply bubbles up through the call chain?

And don't think this can't happen - NPM in particular notorious for this kind of deep dependencies. Also mixins and monkey patching are a thing in JS, so just importing a module can lead to an unexpected change in behaviour.

some people will be quick to say "oh but then the library is just awful". Yes. Yes it is. Sometimes one has to work with brain-dead stupid libraries, and in those cases, it'd be much easier if JS would just give you an error saying what happened: You're trying to multiply apples with oranges.

Typescript to the rescue ;)

Reply on news.ycombinator.com