5 ms·

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 fix

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.

Spivak 5y ago
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.
- cogman10 5y ago
  Javascript array indexing is a MESS. This array["foo"] = "bar" is valid javascript.
  - Osiris 5y ago
    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.
    - cogman10 5y ago
      Because in most other languages, an array is an enumeration of values. That's it. In Javascript, arrays are actually dictionaries. But not full dictionaries, rather just dictionaries that can have either a string or numeric key. It's messy because an array in javascript isn't just "an array" it's this mismesh of features that are unexpected to a new-to-javascript developer. Unexpected is the enemy of readable code.
      - gsnedders 5y ago
        No, arrays are just objects with a magic "length" property (technically: a special [[DefineOwnProperty]] internal method which sometimes also mutates "length"). Like objects, they only support strings as keys. c.f. https://tc39.es/ecma262/#sec-array-exotic-objects https://tc39.es/ecma262/#sec-array-exotic-objects
      - ironmagma 5y ago
        It’s only unexpected if you’re bringing in expectations from somewhere else. Coming from JS as basically my first language, it was surprising and a bit annoying that you couldn’t assign properties to hardly anything in other languages, even functions in languages where functions were supposedly first class.
  - londons_explore 5y ago
    array["at"] = "lunchtime"; Is also valid javascript... And will break functionality in this proposal!
    - runarberg 5y ago
      I think this is the point of the stage 3 proposal. Browser makers start implementing the feature and releasing it in the development and beta versions of their browsers. Then if the users of the experimental features start noticing that webpage break, the proposal will get an update. If I remember correctly, this exact thing happened to `Array.prototype.flatten` which got renamed to `Array.prototype.flat` after it was realized that the former broke a lot of legacy webpages (and after a long discussion of `Array.prototype.smoosh`[1]) 1: https://developers.google.com/web/updates/2018/03/smooshgate https://developers.google.com/web/updates/2018/03/smooshgate
      - IainIreland 5y ago
        In fact, it already happened to this proposal, which started life as `Array.prototype.item` before it turned out that some libraries were using the presence of a `.item` property to duck-type DOM collections: https://github.com/tc39/proposal-relative-indexing-method#web-incompatibility-history https://github.com/tc39/proposal-relative-indexing-method#we...
- kevincox 5y ago
  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.
wereHamster 5y ago
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.
- eknkc 5y ago
  Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.
  - Slackwise 5y ago
    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.
    - dragonwriter 5y ago
      > 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.
  - JoBrad 5y ago
    I expect what we’ll end up with is languages like TS supporting a flag to convert all/most index lookups into .at() notation. Or maybe it’ll just be an eslint flag. I absolutely agree that some metadata at the top of a module enabling behavior like this would be ideal.
  - lhorie 5y ago
    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)
playpause 5y ago
New features are added to JavaScript very carefully to avoid breaking existing code on the web. The downside is you often end up with multiple ways to do the same thing, but there are ways to mitigate this, like using a linter to enforce using a modern subset of the language.
- jasonzemos 5y ago
  That's starting to sound an awful lot more like C++.
  - deleted 5y ago
    [deleted]
  - cxr 5y ago
    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 a spec somewhere, then that would be a failure, not just in the small, but on a societal level. Just rev the language is something that people who spend 40+ hours in an IDE or programmer's text editor think up when they're used to dealing in SDKs and perpetually changing interdependencies and fixing them and getting paid handsomely for it. But that's not what the Web is. The Web is the infrastructure for handling humanity's publishing needs indefinitely. To rely upon another observation: "[This] is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release." https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
    - londons_explore 5y ago
      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.
kevingadd 5y ago
Adding this wouldn't be backwards compatible, so it can't be done. Simple as that. It's not broken, either - it just doesn't do the thing you want.
JoBrad 5y ago
It is consistent with slice, though. Neither changes the implementation of the array, they just provide ergonomic benefit to the developer.
xdennis 5y ago
> fixing I dislike the abuse of this word. Lacking some shorthand notation doesn't make the language "broken". It reminds me of handling support tickets where clients say "X needs to be urgently fixed" even though X has never been possible. (Should it? Often yes, but it doesn't mean it's broken.)
please_recycle 5y ago
Why do you want JS to become more like Python? If you want to use Python, use Python. And, btw, your definition of "fixing" is broken.
deleted 5y ago
[deleted]

Spivak 5y ago

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.

cogman10 5y ago
Javascript array indexing is a MESS. This array["foo"] = "bar" is valid javascript.
- Osiris 5y ago
  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.
  - cogman10 5y ago
    Because in most other languages, an array is an enumeration of values. That's it. In Javascript, arrays are actually dictionaries. But not full dictionaries, rather just dictionaries that can have either a string or numeric key. It's messy because an array in javascript isn't just "an array" it's this mismesh of features that are unexpected to a new-to-javascript developer. Unexpected is the enemy of readable code.
    - gsnedders 5y ago
      No, arrays are just objects with a magic "length" property (technically: a special [[DefineOwnProperty]] internal method which sometimes also mutates "length"). Like objects, they only support strings as keys. c.f. https://tc39.es/ecma262/#sec-array-exotic-objects https://tc39.es/ecma262/#sec-array-exotic-objects
    - ironmagma 5y ago
      It’s only unexpected if you’re bringing in expectations from somewhere else. Coming from JS as basically my first language, it was surprising and a bit annoying that you couldn’t assign properties to hardly anything in other languages, even functions in languages where functions were supposedly first class.
- londons_explore 5y ago
  array["at"] = "lunchtime"; Is also valid javascript... And will break functionality in this proposal!
  - runarberg 5y ago
    I think this is the point of the stage 3 proposal. Browser makers start implementing the feature and releasing it in the development and beta versions of their browsers. Then if the users of the experimental features start noticing that webpage break, the proposal will get an update. If I remember correctly, this exact thing happened to `Array.prototype.flatten` which got renamed to `Array.prototype.flat` after it was realized that the former broke a lot of legacy webpages (and after a long discussion of `Array.prototype.smoosh`[1]) 1: https://developers.google.com/web/updates/2018/03/smooshgate https://developers.google.com/web/updates/2018/03/smooshgate
    - IainIreland 5y ago
      In fact, it already happened to this proposal, which started life as `Array.prototype.item` before it turned out that some libraries were using the presence of a `.item` property to duck-type DOM collections: https://github.com/tc39/proposal-relative-indexing-method#web-incompatibility-history https://github.com/tc39/proposal-relative-indexing-method#we...
kevincox 5y ago
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.

wereHamster 5y ago

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.

eknkc 5y ago
Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.
- Slackwise 5y ago
  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.
  - dragonwriter 5y ago
    > 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.
- JoBrad 5y ago
  I expect what we’ll end up with is languages like TS supporting a flag to convert all/most index lookups into .at() notation. Or maybe it’ll just be an eslint flag. I absolutely agree that some metadata at the top of a module enabling behavior like this would be ideal.
- lhorie 5y ago
  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)

playpause 5y ago

New features are added to JavaScript very carefully to avoid breaking existing code on the web. The downside is you often end up with multiple ways to do the same thing, but there are ways to mitigate this, like using a linter to enforce using a modern subset of the language.

jasonzemos 5y ago
That's starting to sound an awful lot more like C++.
- deleted 5y ago
  [deleted]
- cxr 5y ago
  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 a spec somewhere, then that would be a failure, not just in the small, but on a societal level. Just rev the language is something that people who spend 40+ hours in an IDE or programmer's text editor think up when they're used to dealing in SDKs and perpetually changing interdependencies and fixing them and getting paid handsomely for it. But that's not what the Web is. The Web is the infrastructure for handling humanity's publishing needs indefinitely. To rely upon another observation: "[This] is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release." https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
  - londons_explore 5y ago
    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.

kevingadd 5y ago

Adding this wouldn't be backwards compatible, so it can't be done. Simple as that. It's not broken, either - it just doesn't do the thing you want.

JoBrad 5y ago

It is consistent with slice, though. Neither changes the implementation of the array, they just provide ergonomic benefit to the developer.

xdennis 5y ago

> fixing I dislike the abuse of this word. Lacking some shorthand notation doesn't make the language "broken". It reminds me of handling support tickets where clients say "X needs to be urgently fixed" even though X has never been possible. (Should it? Often yes, but it doesn't mean it's broken.)

please_recycle 5y ago

Why do you want JS to become more like Python? If you want to use Python, use Python. And, btw, your definition of "fixing" is broken.

deleted 5y ago

[deleted]