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

Stage 3 Proposal: Array.prototype.at

tc39.es

Post reply on HN
Print view View original

51–60 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#51

Post by zodiakzz »

beaconstudios wrote: post #49
zodiakzz wrote: post #48

Earlier quoted context omitted.

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.

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

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

Re: Stage 3 Proposal: Array.prototype.at

#52

Post by antris »

e1g wrote: post #31
antris wrote: post #18

Earlier quoted context omitted.

Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.

A function that works in some cases will be a nightmare to debug. The pattern of `indices.map(myObjectArr.at)` is discouraged in JS because it often fails in unexpected ways. For example - ["1","2"].map(parseFloat) // works as expected ["1","2"].map(parseInt) // nope

I've learned ages ago that parseInt cannot be used like this, so it's not a problem for me, but I thought linters already take care of this case? Also I wasn't talking about using parseInt, a broken function like this so I'm not sure what the quirks of old, widely known bad parts of Javascript have to do with using functions as arguments, which is one of the most powerful features of the language.

Re: Stage 3 Proposal: Array.prototype.at

#53

Post by Aachen »

beaconstudios wrote: post #49
zodiakzz wrote: post #48

Earlier quoted context omitted.

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.

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

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

Re: Stage 3 Proposal: Array.prototype.at

#54

Post by antris »

jakelazaroff wrote: post #34
antris wrote: post #18

Earlier quoted context omitted.

Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.

That won’t work in this case. TypeScript won’t yell at you if you pass a function that doesn't use all its arguments. If a second number argument is ever added to `at`, your code using it this way will break and TypeScript will not warn you. This blog post explains why what you’re proposing is dangerous: https://jakearchibald.com/2021/function-callback-risks/#type...

I guess I'm then somehow doing subconscious mental gymnastics to prevent this, because me and several of my colleagues have coded like this for years and it hasn't been a problem even once.

Re: Stage 3 Proposal: Array.prototype.at

#55

Post by beaconstudios »

zodiakzz wrote: post #51
beaconstudios wrote: post #49

Earlier quoted context omitted.

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

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

Re: Stage 3 Proposal: Array.prototype.at

#56

Post by antris »

benjaminjackman wrote: post #32
antris wrote: post #18

Earlier quoted context omitted.

Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.

TypeScript definitions don't block and VS Code does not warn for `indices.forEach(console.log)` When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ... It also defends / insulates against more parameters being added in the future. Additionally, t…

>TypeScript definitions don't block and VS Code does not warn for `indices.forEach(console.log)`

Sure, it's a valid way of logging all the arguments that pass through forEach. I don't see a problem here?

>When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ...

My VSCode setup shows all arguments of functions automatically. Also, I always avoid optional arguments in my code and writing functions that take in a variable amount of arguments or arguments of different types. I always refactor these out of my codebase.

>Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction.

`this` is another smell that I always avoid using in my codebase, and refactor code that uses it to work without `this`. I thought `this` being harmful is common knowledge?

Re: Stage 3 Proposal: Array.prototype.at

#57

Post by rand_r »

Fire-Dragon-DoL wrote: post #47
rand_r wrote: post #44

Earlier quoted context omitted.

The web as a platform is the most elaborate and epic showcase at not breaking backwards compatibility in the entire history of computing. In the face of disasters like Python 2->3 and Apple M1 macs no longer being able to play Starcraft Remastered, the web is an aspirational beacon. Let’s keep it going.

Isn't Windows even more epic?

You might well be right! Would be fun to see them go head-to-head over the title.

Re: Stage 3 Proposal: Array.prototype.at

#59

Post by Cthulhu_ »

beaconstudios wrote: post #37

const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?

Because at some point someone will - and probably has - make a library out of this, adding yet one more to the tens of thousands of files that my cruddy server can't handle already because of the sheer quantity.

Plus you're probably missing a few dozen edge cases and optimizations that the native version would incorporate.

We wouldn't have been in node_modules dependency hell if they incorporated a few more things into the standard library or language.

Re: Stage 3 Proposal: Array.prototype.at

#60

Post by maest »

zodiakzz wrote: post #51
beaconstudios wrote: post #49

Earlier quoted context omitted.

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

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

> Reinventing the wheel is error prone.

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

Post reply on HN