101–110 of 153 posts
Earlier quoted context omitted.
For financial makes sense, but science should be independent of numerical base?
I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.
const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?
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 enough times to actually need to revert a change in prod.
I have similar thoughts about .at(). Taking an element from the end of the array is ever-so-slightly error prone. Sure, you won't make a mistake this time, or the next time, but write it a hundred times, or a thousand, and I bet a bug will slip in. It's darn near impossible to get `.at(-1)` wrong, however.
const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?
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…
Am I reading this correctly — it's an alias for arr[i] and str[i]? I know languages like Ruby have arr.at(i), but why?
In addition to negative index support, a function is more easily composable e.g. converting a list of indices to a list of objects: `indices.map(myObjectArr.at)` I've lost count on how many times I've wrote this function manually.
> Uncaught TypeError: Cannot convert undefined or null to object
because `myObjectArr.at` doesn't bind `this` to `myObjectArr`. When the internals of `map` call the `at` function, `this` is just `undefined` instead of the original array and it'll throw.
Luckily Array.prototype.map takes a second argument just for this purpose
indices.map(myObjectArr.at, myObjectArr)Earlier quoted context omitted.
For financial makes sense, but science should be independent of numerical base?
I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.
Earlier quoted context omitted.
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 introd…
> hacks
Flash was not standardized. Same with IE's proprietary recommendations (and Mozilla's for that matter—XUL is proprietary, even though people often use "proprietary" as an antonym for "open source"). Most of the "web features" that people have in mind are in the same boat: experimental and draft-level proposals that eventually fall by the wayside for one reason or another. The Web is actually the single most successful attempt at a vendor-neutral, stable platform that exists. It's why we're having this conversation now.
The argument is that, because some people did something hacky or bleeding edge and then bled from it, then there's no real point in any amount of stability, so we should punish everyone. What a double whammy that would make for! First, you spend all your time taking care to do things correctly, so you pay the penalty inherent in that—what with moving more slowly than all those around you—and then someone decides, "ah, nevermind screw the whole thing", doubles back on the original offer and then breaks your shit? I can't say I'm able to abide by that. Imagine all your friends getting drivers licenses and receiving a bunch of speeding tickets for their recklessness, then one day you get pulled over and ticketed, too, regardless of the fact that you weren't speeding.
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?
The Web probably has a longer history of not breaking things, but also has a smaller feature set to keep track of than Windows.
All in all, very hard to compare. But both undoubtedly epic.
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?
Earlier quoted context omitted.
> 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.
Yes, the full "standard libarary" you can expect to be present on any given JS VM may vary, but there's no plausible reason that e.g. at() should not work on almost any conceivable platform.
Earlier quoted context omitted.
In addition to negative index support, a function is more easily composable e.g. converting a list of indices to a list of objects: `indices.map(myObjectArr.at)` I've lost count on how many times I've wrote this function manually.
That will break with > Uncaught TypeError: Cannot convert undefined or null to object because `myObjectArr.at` doesn't bind `this` to `myObjectArr`. When the internals of `map` call the `at` function, `this` is just `undefined` instead of the original array and it'll throw. Luckily Array.prototype.map takes a second argument just for this purpose indices.map(myObjectArr.at, myObjectArr)
There should really be a whole new standard library made from ground up without `this`, mutability and all the other legacy stuff.