The MDN documentation for Array.prototype.at is easier to understand than the linked proposal: https://developer.mozilla.org/docs/Web/JavaScript/Reference/...
Stage 3 Proposal: Array.prototype.at
131–140 of 153 posts
Re: Stage 3 Proposal: Array.prototype.at
#132Earlier quoted context omitted.
There's still a ton of overhead for WASM and it's not first class. Using WASM is a lot like using C code in python. It's still nice to have features as first class citizens :)
Isn't most python just stringing together c and Fortran libraries that expose a python interface?
It amazes me at Python web engineers and Python ML engineers who go along completely unaware of the existence of the other group in any large numbers. (I say this as someone who went to my local pycon 5-6 years ago and was surprised that ML talks were like 30% of the topics)
Re: Stage 3 Proposal: Array.prototype.at
#133Earlier quoted context omitted.
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.
There's nothing broken about parseInt. The problem is, it can take a second argument(radix), and .map will feed it current item's index as the second argument(and the whole array as the third, but that one will get ignored).
const arr = ['1','2','3']; arr.map(parseInt) is equivalent to: [ parseInt('1', 0, arr), parseInt('2', 1, arr), parseInt('3', 2, arr) ];
Re: Stage 3 Proposal: Array.prototype.at
#134Earlier 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…
or
const leftpad = (str, len, char = ' ') => str.padStart(len, char);Re: Stage 3 Proposal: Array.prototype.at
#135JS urgently needs support for decimals [1] and thus be able to enter sectors such as scientific and financial. V8 + dynamic language + better math support = perfect environment for many applications out there [1] https://github.com/tc39/proposal-decimal
Very good point. I'm just now fully understanding why at my last fin-tech job we stored all monetary amounts in pennies. I thought at first it was just ideal to keep everything as integers in the database but I see now that due to our Node backend, something as simple as 0.20 + 0.10 could pose a problem.
Re: Stage 3 Proposal: Array.prototype.at
#136Earlier 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…
or const leftpad = (str, len, char = ' ') => str.padStart(len, char);
Haha yes that would be the modern option.
Re: Stage 3 Proposal: Array.prototype.at
#137Im a JS veteran, and not a single word in the article made any sense to me.
Re: Stage 3 Proposal: Array.prototype.at
#138Earlier quoted context omitted.
Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.
TC39 explicitly rejected this sort of approach a few years ago, because of the unpleasant way it would fork the web. They _did_ automatically clean up some behavior in a module context when you knew you were using a modern JS engine, but they kept that to a minimum. Unfortunately, I couldn't find any links to articles written at the time about this, but they definitely did consider "use" options or script type="es202…
I can see where they're coming from; backwards compatibility is often a hard problem, and this is no exception. But the downside of this approach is that we'll be living with these sort of backward-compatible hacks for decades to come :-/
Imagine learning JS in 5 years: "you can index arrays with subscripts, but actually, if you want to get negative indexes you need to use .at()"
vs.
"Always add 'use es2021'; at the top of your scripts. You can index arrays with subscripts."
I'm hardly a huge Perl fan, but their approach made a lot more sense IMHO and is a good trade-off between making sure existing code works, and not complicating the language for future use. The "fork" (which seems a bit hyperbolic to me) is a very minor short-term pain at best for significant long-term gains.
I don't know of any other mainstream language that's so conservative as JavaScript in never breaking anything, even optionally with flags.
Besides, compatibility is important but not holy. Some programs probably also rely on "[9] * 2" resulting in Number 18, but we really ought to fix that (with or without flag) IMHO because these sort of gotchas result in people writing bugs every single day where it works for an array length of 1 and then it has 2 values and you get NaN. The pain of breaking backwards compatibility is minor compared to the pain of new bugs being created every single day.
Golden opportunities are being missed here, and it's a shame.
Re: Stage 3 Proposal: Array.prototype.at
#139Earlier quoted context omitted.
Subtle readability improvements on patterns that see extensive use actually make a difference. I had the exact same thoughts when `.includes()` was proposed to be added to the spec - it's just `.indexOf() !== -1`! - but time has proven me wrong, and I suspect it will prove us wrong about `at` as well. I've written an `.indexOf() !== -1` check hundreds if not thousands of times, and I've gotten the conditional wrong e…
Indeed, and as others have stated it is really hard to allow `[-1]` without breaking old code. Also: `[1, NaN, "hi"].indexOf(NaN)` is -1 but `.includes(NaN)` returns true as expected.
> `[1, NaN, "hi"].indexOf(NaN)` is -1 but `.includes(NaN)` returns true
Brutal.
Re: Stage 3 Proposal: Array.prototype.at
#140Earlier quoted context omitted.
Honest (possibly stupid) question: Do people working on statistical and probability application never need a numeric type optimized for probability values (i.e. values between 0 and 1 that can get really close to either; for example the really almost certain value of p = 1 - 10^-13)? In the same way that financial application needs a decimal type? I’ve only worked on probability applications at a surface level for a…
Log probabilities are used a bit for this, and most numeric packages (numpy for instance) have special functions for computing log(1+x) which are more accurate when x is tiny.
[deleted]