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

61–70 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#61

Post by beaconstudios »

Cthulhu_ wrote: post #59
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 in…

in my experience, the vast majority of node modules I have installed don't provide these tiny little functions, but are:

- frameworks like react or express and extensions for the same

- meaningful libraries like axios, ramda, date-fns or qs

- transpiler/bundler enhancements like webpack loaders or babel presets

I would prefer that the JS committee focused on bringing meaningful new capabilities to node and the browser that are currently lacking, like they did with the various HTML5 libraries, fetch(), ES classes and so on, rather than providing tiny functions that aren't even providing new functionality (array indexing is easy and idiomatic in JS). If there was no opportunity cost then sure, add tiny pointless builtin functions all day long.

Re: Stage 3 Proposal: Array.prototype.at

#62

Post by chrismorgan »

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

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

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

Re: Stage 3 Proposal: Array.prototype.at

#63

Post by IainIreland »

pedrow wrote: post #26

In the proposal text, what's the meaning of the '?' and '!' - for example in "Let O be ? ToObject(this value)"

Roughly speaking, '?' means that the operation might throw an exception, which should be propagated if thrown, and '!' means that the operation should never fail. (In Rust terms, '? ToObject(this value)" -> "ToObject(thisValue)?", and "! ToObject(this value)" -> "ToObject(thisValue).unwrap()".)

See: https://tc39.es/ecma262/multipage/notational-conventions.htm...

Re: Stage 3 Proposal: Array.prototype.at

#64

Post by MsMowz »

maest wrote: post #60
zodiakzz wrote: post #51

Earlier quoted context omitted.

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.

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.

Re: Stage 3 Proposal: Array.prototype.at

#65

Post by lucideer »

beaconstudios wrote: post #61
Cthulhu_ wrote: post #59

Earlier quoted context omitted.

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

in my experience, the vast majority of node modules I have installed don't provide these tiny little functions, but are: - frameworks like react or express and extensions for the same - meaningful libraries like axios, ramda, date-fns or qs - transpiler/bundler enhancements like webpack loaders or babel presets I would prefer that the JS committee focused on bringing meaningful new capabilities to node and the browse…

You seem to be garnering a lot of downvotes without replies so I'll bite: it sounds from your comment like you've never looked into the subdependency tree of those frameworks and meaningful libraries that you list (which seems like it would be hard to miss tbh for anyone that's ever opened up the node_modules directory).

Those tiny little libs providing tiny little functions are likely not direct dependencies of your application, rather dependencies of a subdependency of a subdependency of a subdependency of your preferred "meaningful" library.

Re: Stage 3 Proposal: Array.prototype.at

#66

Post by lhorie »

beaconstudios wrote: post #61
Cthulhu_ wrote: post #59

Earlier quoted context omitted.

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

in my experience, the vast majority of node modules I have installed don't provide these tiny little functions, but are: - frameworks like react or express and extensions for the same - meaningful libraries like axios, ramda, date-fns or qs - transpiler/bundler enhancements like webpack loaders or babel presets I would prefer that the JS committee focused on bringing meaningful new capabilities to node and the browse…

ramda and date-fns are full of little such functions... The fact that util packs like these and lodash exist is a sign that Javascript's stdlib lacks mechanisms to deal with various common patterns.

FWIW, I consider `at` to be similar to some of the things you consider "new capabilities". `fetch` vs `XMLHttpRequest` is fairly analogous to `at` vs `arr[i]`, and similar arguments can be made about ES6 classes over prototypal classes, etc.

Re: Stage 3 Proposal: Array.prototype.at

#67

Post by zodiakzz »

chrismorgan wrote: post #62
zodiakzz wrote: post #51

Earlier quoted context omitted.

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

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

Re: Stage 3 Proposal: Array.prototype.at

#68

Post by lucideer »

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…

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

Re: Stage 3 Proposal: Array.prototype.at

#69

Post by beaconstudios »

lucideer wrote: post #65
beaconstudios wrote: post #61

Earlier quoted context omitted.

in my experience, the vast majority of node modules I have installed don't provide these tiny little functions, but are: - frameworks like react or express and extensions for the same - meaningful libraries like axios, ramda, date-fns or qs - transpiler/bundler enhancements like webpack loaders or babel presets I would prefer that the JS committee focused on bringing meaningful new capabilities to node and the browse…

You seem to be garnering a lot of downvotes without replies so I'll bite: it sounds from your comment like you've never looked into the subdependency tree of those frameworks and meaningful libraries that you list (which seems like it would be hard to miss tbh for anyone that's ever opened up the node_modules directory). Those tiny little libs providing tiny little functions are likely not direct dependencies of your…

I'm aware of that. Unfortunately that's always going to be the case that some people who write libraries you depend on indirectly are not very good at programming and lean heavily on other dependencies to provide basic functionality. That will be the case regardless of how all-encompassing the stdlib is, and is entirely dependent on the culture of practice of the language you're using. JS is both beginner-friendly and the culture is focused on personal marketability, so you're going to get a lot of beginners land-rushing to put out basic libraries that don't do anything to cater to other beginners, in order to put the number of stars/npm downloads on their blog or CV. That's not going to change with the number of new core features.

Re: Stage 3 Proposal: Array.prototype.at

#70

Post by jahewson »

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?

Array parameter should be last, surely? Or why not extend the prototype? If only we had some way to standardise such decisions...
Post reply on HN