4 ms·

Just Google "left-pad" to know why. I think .at() also doesn't have to look up the entire prototype chain so it has performance benefits as well.

beaconstudios 5y ago
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.
- zodiakzz 5y ago
  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'`
  - beaconstudios 5y ago
    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).
    - Osiris 5y ago
      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.
      - beaconstudios 5y ago
        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.
        claytongulick 5y ago
        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?
      - lhorie 5y ago
        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)
    - borschtplease 5y ago
      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()’
  - maest 5y ago
    > Reinventing the wheel is error prone. Having a standard lib for these sort of functions is a common pattern many languages adopt.
    - MsMowz 5y ago
      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.
      - Quekid5 5y ago
        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.
      - tomstoms 5y ago
        > for Node, there's npm True, NodeJS runtime comes with its own «standard library» but npm has nothing to do with it.
  - chrismorgan 5y ago
    Quite incidentally, this is fixed with the addition of one character: const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + +i];
    - zodiakzz 5y ago
      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)`.
      - chrismorgan 5y ago
        Hmm, I had completely forgotten about that distinction. I also can’t find it in the spec <https://tc39.es/ecma262/ 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 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 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 https://tc39.es/ecma262/#sec-unary-plus-operator>). So now I’m guessing it means ToPrimitive <https://tc39.es/ecma262/#sec-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).
  - Osiris 5y ago
    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.
- Aachen 5y ago
  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).
- lucideer 5y ago
  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).
- easrng 5y ago
  or const leftpad = (str, len, char = ' ') => str.padStart(len, char);
  - beaconstudios 5y ago
    Haha yes that would be the modern option.

beaconstudios 5y ago

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.

zodiakzz 5y ago
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'`
- beaconstudios 5y ago
  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).
  - Osiris 5y ago
    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.
    - beaconstudios 5y ago
      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.
      - claytongulick 5y ago
        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?
    - lhorie 5y ago
      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)
  - borschtplease 5y ago
    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()’
- maest 5y ago
  > Reinventing the wheel is error prone. Having a standard lib for these sort of functions is a common pattern many languages adopt.
  - MsMowz 5y ago
    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.
    - Quekid5 5y ago
      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.
    - tomstoms 5y ago
      > for Node, there's npm True, NodeJS runtime comes with its own «standard library» but npm has nothing to do with it.
- chrismorgan 5y ago
  Quite incidentally, this is fixed with the addition of one character: const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + +i];
  - zodiakzz 5y ago
    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)`.
    - chrismorgan 5y ago
      Hmm, I had completely forgotten about that distinction. I also can’t find it in the spec <https://tc39.es/ecma262/ 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 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 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 https://tc39.es/ecma262/#sec-unary-plus-operator>). So now I’m guessing it means ToPrimitive <https://tc39.es/ecma262/#sec-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).
- Osiris 5y ago
  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.
Aachen 5y ago
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).
lucideer 5y ago
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).
easrng 5y ago
or const leftpad = (str, len, char = ' ') => str.padStart(len, char);
- beaconstudios 5y ago
  Haha yes that would be the modern option.