Hacker News Reader

Comment by beaconstudios | Hacker News Reader

    const leftpad = (str, len, char = ' ') => str.length >= len ? str : (char.repeat(len - str.length) + str);

Anybody who installs a dependency instead of writing a one line function is just leaving themselves exposed for no real benefit.

Providing the at function outside of the prototype chain like I did above will not incur the cost you mentioned, even in the unlikely case that such calls are the bottleneck of your application.

Plus, if array lookup calls are your bottleneck then you probably need a different data structure.

View on HN

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'`

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()’

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

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

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.

You're assuming this is a decision available to each app developer. In fact these dependencies are usually chosen by the developer of a library that's a dependency of a dependency of a dependency of a dependency of a library you choose as an app developer.

Auditing the entire dependency tree of every library you choose is extremely arduous without proper tooling, and the tooling here has never been good (and even the more recently available better tooling is CVE-focused so won't highlight tells like package size/maintenance status/whatever other heuristics you might devise as a proxy for quality).

I agree that dependency hell is a problem, but I don't agree that reinventing the wheel is better. Including things a lot of developers will need in the language is probably the best way to approach things like left_pad, at least given these three options (reinvent, third-party, language inclusion).

    const leftpad = (str, len, char = ' ') => str.padStart(len, char);

Haha yes that would be the modern option.

Reply on news.ycombinator.com