[dartos]

> Not true. In TypeScript…

Not talking about typescript.

Typescript wasn’t nearly as wide spread or as complete back then anyway. Facebook was still on flow.

> they operate on kv-pairs in form of 2-element arrays.

So… Not tuples…

> So your assertion that tuples are something alien to JS ecosystem isn't accurate simply because of that.

My words were “almost nothing else.” I’m sure someone somewhere uses the idea of tuples in their js code (implemented as arrays, ofc) but it’s extremely far from the norm.

Also none of that refutes my point that it’s poor api design. Thanks for being pedantic tho.

[kaoD]

> Not talking about typescript.

TS is just encoding JS semantics into a type system.

A function returning a fixed-size array in JS is effectively returning, semantically, a tuple. They're just not a different type unlike in other languages (for different reasons).

JS arrays are not even arrays since they (1) are not contiguous and (2) do not require items to be of the same size (typed arrays are actual arrays though) except by their backing implementation (which uses js vals, but that's a property of the implementation, not the language). They're sparse vectors. But nobody cares about that technical distinction and we still call fixed-size arrays tuples and variable-size arrays arrays. You can even attach properties to them because arrays are not vectors, they are objects. Or can be, for that matter. The backing implementations are complex and very dynamic.

JS was intentionally made this simple so it could have emergent semantics. Scheme-ish.

> Typescript wasn’t nearly as wide spread or as complete back then anyway. Facebook was still on flow.

It was when they introduced hooks.

[dartos]

That’s a lot of words unrelated to my point about the API being poorly designed.

Typescript is irrelevant.

The implementation of arrays in js is irrelevant.

Js being intentionally simple is irrelevant (and might even strengthen my point)

[xpl]

Your very definition of "poorly designed" is overly rigid and unproductive. When you design APIs for everyday human use, you value expressiveness and succinctness over verbosity and explicitness. Because such APIs are more of a "human interface" (like UI) than a "program interface" in a sense.

One thing is some random payment processor API that you encounter only once in your career (it doesn't need to be terse and it is better to avoid any magic here) — and whole another thing is stuff like jQuery or React, which I can produce/read in thousands of lines per day. You would design such APIs with different objectives, like being easy to type, easy to read (once you know the API).

The mantra "explicit is better than implicit" is wrong, because it really depends.