Hacker News Reader

Comment by zodiakzz | Hacker News Reader

Reinventing the wheel is error prone. Noone wants to bloat their code/time with unit tests for all these utility methods.

Just look at your at() function, I already spotted a bug, if a numeric string is passed: `([].length + '-1') === '0-1'`

View on HN

Quite incidentally, this is fixed with the addition of one character:

    const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + +i];

Nit: it throws if you wanna use a negative bigint as `i` hehehe :(

  let i = -1n;
  let test = +i;
  > Uncaught TypeError: can't convert BigInt to number

See this is where standard libraries shine, they consider all the pieces of the puzzle. There's no good reason to disallow bigints here.

P.S: Unary plus operator is neat but this TypeError with BigInt is why I am starting to prefer the more verbose `Number(i)`.

Hmm, I had completely forgotten about that distinction. I also can’t find it in the spec <https://tc39.es/ecma262/>, which says that Number “performs a type conversion when called as a function rather than as a constructor.” <https://tc39.es/ecma262/#sec-number-constructor>. What this means isn’t spelled out, which seems poor. I would have thought it meant ToNumber <https://tc39.es/ecma262/#sec-tonumber>, but that would throw an exception on BigInt (like unary plus does, <https://tc39.es/ecma262/#sec-unary-plus-operator>). So now I’m guessing it means ToPrimitive <https://tc39.es/ecma262/#sec-toprimitive> with preferredType number, which seems to match. This being the case, I believe BigInt is the sole difference between +x and Number(x).

> Reinventing the wheel is error prone.

Having a standard lib for these sort of functions is a common pattern many languages adopt.

Isn't that really a pattern that the runtime adopts (i.e. not the language itself)? For ES, the libraries are dependent on the runtime environment; for browsers, there are the web APIs, and for Node, there's npm. I'm not sure how you could have anything more standard given the nature of things.

This might be just a few levels of people talking past each other, but just in case:

Yes, the full "standard libarary" you can expect to be present on any given JS VM may vary, but there's no plausible reason that e.g. at() should not work on almost any conceivable platform.

> for Node, there's npm

True, NodeJS runtime comes with its own «standard library» but npm has nothing to do with it.

Their example does no argument validation. It doesn't check that arr is array, or that i is an integer, etc. The spec actually addresses the argument validation.

yes that is obvious - my point was that the functionality is minimal. with guards:

    const at = (arr, i) => {
      if(!(Array.isArray(arr) && typeof i === 'number')) {
        throw new Error('invalid arguments');
      }
      // same as before
    };

you wouldn't just commit a single-line function in your code. But there are 10,000 micro-functions that could be in the core of JS. Why bother to add this, especially if it's so easy to implement? There are surely better things the JS committee could be putting their time towards, like providing functionality that is presently lacking in JS (maybe they could finally get around to advancing the pipe operator through the TC stages).

Your number guard is insufficient. NaN, infinity, 2.23 are all Number but not supported values for the function.

This goes to show that it's NOT trivial to implement in a robust way.

It is trivial. It requires a few more lines than my example, but my example was intended to show the core use case. All I'm getting in replies is nitpicking about my example case... Can't you just assume when reading that I know how to write some simple guard statements? It's hardly rocket science.

Because it is such a common case?

To invert your argument, why would you want millions of developers to have to waste their time writing this sort of thing for such a common need?

Yes, it's clear that you could write the function correctly.

Could everyone?

What about bugs that aren't obvious? The runtime errors that result?

Why would we want to waste so much developer time and effort globally, when we can just add .at() to the language?

If we're going to nitpick, those are actually all valid values for `arr[i]`... (though, to be fair, they don't exactly do what one might necessarily expect)

I want you to look at some other languages beside javascript. Take a look at Swift or Ruby. Compared to them it feels like 60% of js code is boilerplate. 200 lines of js can be fit in 60 lines of Swift. All because js stdlib is just sucks. I’m tired of this silly ‘someArray.length ? someArray[someArray.length - 1] : null’, I want just ‘someArray.last()’

Reply on news.ycombinator.com