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

71–80 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#71

Post by dragonwriter »

Slackwise wrote: post #40
eknkc wrote: post #23

Earlier quoted context omitted.

Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.

I've been thinking this for ages . We need more special contextual comments to change a file or scope to behave better so we can move forward and scrape away all the bad legacy of JS.

> We need more special contextual comments to change a file or scope to behave better so we can move forward and scrape away all the bad legacy of JS.

I don’t think making the JS world into even more of a “set of subtly different languages that look mostly similar” is necessarily a solution so much as an extra problem.

Re: Stage 3 Proposal: Array.prototype.at

#72

Post by cogman10 »

dlojudice wrote: post #33

JS 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

Couldn't that be done with WASM today? It looks like a few people have managed to build GMP targeting WASM.

You might miss out on some SIMD operations, but you'd be able to do 90% of what you'd want with scientific calcs. (admittedly, it'd be nice if this were part of the language).

Re: Stage 3 Proposal: Array.prototype.at

#73

Post by beaconstudios »

lhorie wrote: post #66
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…

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

ramda is an immutable library - javascript is immutable. Some functions of date-fns could probably be part of the core, and in fact that's one of the areas I wish the JS WG would focus on as Date is just not a very useful class.

> `fetch` vs `XMLHttpRequest` is fairly analogous to `at` vs `arr[i]`

If you consider all syntactic sugar to be equivalent, no matter how minor the change, then anything above a basic Turing machine implementation is fairly analogous. The problem with XHR is that the interface was really bad. The interface for arr[i] is not really bad.

Re: Stage 3 Proposal: Array.prototype.at

#74

Post by lhorie »

eknkc wrote: post #23
wereHamster wrote: post #11

Earlier quoted context omitted.

There is existing code out there which relies on negative indexes to return undefined. Or relies on being able to assign items to negative indexes and then retrieve them, this is perfectly valid code: `a=[];a[-1]=42;console.log('the answer is',a[-1])`. The web tries really hard to be backwards compatible and not break existing code.

Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.

IIRC Google actually experimented with the idea of an even stricter mode in V8 at some point but dropped it when it didn't materialize the perf gains they were hoping for.

From a spec perspective, ES6 modules were a good milestone to "flip the switch" over to strict mode by default, but even with that being a fairly successful strategy (IMHO), it still left some nasty corner cases around the language (namely, there are now two distinct top level grammars, which led to the whole .mjs bikeshedding rabbit hole)

Re: Stage 3 Proposal: Array.prototype.at

#75

Post by cogman10 »

Spivak wrote: post #10
Phenix88be wrote: post #9

So instead of fixing the language and allow to use array[-1], they add an other way to access array element. This is why I don't like JavaScript, instead of fixing feature, they add new feature to fix previous feature.

The problem with JS language development is the mountain of code that it would break if you do anything except append features. array[-1] = “foo” This already works in JS but doesn’t do what you expect and just assigns the property.

Javascript array indexing is a MESS. This

    array["foo"] = "bar"
is valid javascript.

Re: Stage 3 Proposal: Array.prototype.at

#76

Post by londons_explore »

cxr wrote: post #38
jasonzemos wrote: post #17

Earlier quoted context omitted.

That's starting to sound an awful lot more like C++.

No, even then, they're fundamentally different. An organization can go through and update its C++, because ultimately they're distributing binaries (or doing everything internally and not distributing anything at all). Web "pages" aren't called that for no good reason. If in 2005 you bought a novel, or some punk writer–artist's printed pamphlet, and now you can't read it because in the meantime some engineers changed…

Your post sounds good... Until you realise that nearly any nontrivial web page from 10+ years ago is broken today...

No Flash... Iframes don't work properly anymore... HTTPS servers from 10 years ago are unsupported by todays browsers... Most of the IE hacks no longer work (remember progid:DXImageTransform?)... Any images/resources hosted elsewhere are likely now nonexistent...

Plenty of web features have been introduced and then dropped just a few years later. Backwards compatibility is great... But if it's practically broken anyway, I think there is a good argument for breaking it further. People who need to read an old page will probably need to use IE6 in a VM anyway.

Re: Stage 3 Proposal: Array.prototype.at

#77

Post by lhorie »

beaconstudios wrote: post #73
lhorie wrote: post #66

Earlier quoted context omitted.

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

ramda is an immutable library - javascript is immutable. Some functions of date-fns could probably be part of the core, and in fact that's one of the areas I wish the JS WG would focus on as Date is just not a very useful class. > `fetch` vs `XMLHttpRequest` is fairly analogous to `at` vs `arr[i]` If you consider all syntactic sugar to be equivalent, no matter how minor the change, then anything above a basic Turing…

I mean it in the opposite sense, actually (that XMLHttpRequest - or more precisely, Microsoft's original version of it - was a leap forward, whereas fetch/axios/friends are, for the most part, merely a convenience over now established capabilities)

Similarly, sure you can do point-free style w/ ramda's `R.add` but realistically, do you really? The fundamental game changer capability is the language's ability to do math in the first place; anything on top is arguably cherry on the cake. `at` seems uncannily similar in that regard.

Wrt something being in a 3rd party library vs stdlib, I'll generally prefer a batteries included approach in JS because module resolution is complex enough to cause difficult problems to troubleshoot (peerDeps hell, complex symlinking semantics, library duplication in bundles, core.js explosion, package manager specific breakages, etc)

Re: Stage 3 Proposal: Array.prototype.at

#78

Post by Osiris »

cogman10 wrote: post #75
Spivak wrote: post #10

Earlier quoted context omitted.

The problem with JS language development is the mountain of code that it would break if you do anything except append features. array[-1] = “foo” This already works in JS but doesn’t do what you expect and just assigns the property.

Javascript array indexing is a MESS. This array["foo"] = "bar" is valid javascript.

Why does this make it a mess? Array already has a bunch of properties that aren't elements in the Array that come from the prototype, like join and slice. Your example is just adding a custom property to the array.

Re: Stage 3 Proposal: Array.prototype.at

#79

Post by runarberg »

dlojudice wrote: post #33

JS 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

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 tiny bit and never really needed it, but I kept wondering whether there were such a numeric types, and if not, what people did if they needed it.

Re: Stage 3 Proposal: Array.prototype.at

#80

Post by kevincox »

Spivak wrote: post #10
Phenix88be wrote: post #9

So instead of fixing the language and allow to use array[-1], they add an other way to access array element. This is why I don't like JavaScript, instead of fixing feature, they add new feature to fix previous feature.

The problem with JS language development is the mountain of code that it would break if you do anything except append features. array[-1] = “foo” This already works in JS but doesn’t do what you expect and just assigns the property.

To be clear this is equivalent to array["-1"] (unless you do horrible things overriding the built in types). Since arrays are "just" objects in JavaScript it is completely valid to add a property called "-1" to it.
Post reply on HN