5 ms·

Each point doesn't really bear the same level of "unsoundness". Most are actually not problems at all the way I see it. 1. I can live with NaN. When the source

Each point doesn't really bear the same level of "unsoundness". Most are actually not problems at all the way I see it. 1. I can live with NaN. When the source of something becomes difficult to track, use a debugger. 2. Map vs map? Just another homograph, like there are hundreds in all spoken languages, yet most people manage to communicate. 3. The overhead of negative indices might be acceptable in JavaScript, but most languages probably don't benefit from having them. I think negative indices are actually hurtful, they tend to hide bugs which would otherwise be caught very early at runtime. 4. This is actually a serious issue. I don't get why so many people are in awe with TypeScript type system. Anything based on duck typing is a red flag to me. But still, better than no typing at all...

arduanika 6y ago
3. What he's calling unfortunate is not that negative indices don't work in JavaScript, but rather that it silently returns undefined instead of raising
- qsort 6y ago
  That behavior does make sense in the context of Javascript. > {a: 1, b: 2}['c'] undefined > {1: 1, 3: 2}[2] undefined If you're arguing that JS objects shouldn't be like that, you do have a point. But taking JS basic semantics as a given, I don't see what other behavior you would expect.
  - robertlagrant 6y ago
    The point is in the context of lists, not objects. It's in the article.
    - ulucs 6y ago
      But lists are objects, with negative indices as possible keys: > const l = [1,2,3]; undefined > l.a = l; [ 1, 2, 3, a: [Circular] ] > l === l.a true > l[-1] = 0; 0 > l [ 1, 2, 3, a: [Circular], '-1': 0 ]
      - Silhouette 6y ago
        Even without that argument, the behaviour is still consistent with other cases for arrays in JS anyway. > const a = [1, 2]; > a[0] 1 > a[2] undefined > a[-1] undefined
      - robertlagrant 6y ago
        And positive indices not as possible keys, but as array elements. It's crazily inconsistent. > l = [1,2,3] (3) [1, 2, 3] > l[3] = 4 4 > l (4) [1, 2, 3, 4] > l[-1] = "eek" "eek" > l (4) [1, 2, 3, 4, -1: "eek"] So adding a 4 as a "key" is a proper array element; adding -1 is an object key. I'm struggling to see how anyone could think this is a good idea. Saying that they're objects is not reasonable. Objects don't need to do this (in most languages lists are objects, and they don't also do key-value pairs at the same time); they just decided to make them do this.
        qsort 6y ago
        It's extremely consistent. I'd say that's the only consistent way to do it, if you want to preserve the semantics of JS objects. Lua does pretty much the same. > Saying that they're objects is not reasonable. This is a fair point, in the alternate universe where JS objects have different semantics. > in most languages lists are objects, and they don't also do key-value pairs at the same time This is a dynamic language we're talking about. You are very welcome to think dynamic languages are inferior choices, an opinion that I personally would share, but that's a discussion for another time. In the context of JS, that behavior is neither unreasonable nor inconsistent.
        robertlagrant 6y ago
        Python is also dynamic. That has nothing to do with this. >>> l = [] >>> l.x = "hello" Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'list' object has no attribute 'x' Always adding arbitrary properties to an object is not a dynamic thing, it's just a bit silly. At best you could say it's a weak typing thing, but even then, it doesn't need to be.
    - tsimionescu 6y ago
      In JS semantics, lists (by which I assume you actually mean arrays) are just objects with numeric keys. Nothing special about them, except that there are certain functions which assume the objects they take in have only numeric keys starting from 0 and always increasing (they usually ignore non-numeric keys that those objects might have). This is similar to LISP, where you can build many kinds of structures out of cons cells, and you have certain families of functions that assume that the cons cells you pass in have certain kinds of structures, defining lists or trees or association lists etc.
swyx 6y ago
4 is not an issue given that basically all other JavaScript typing systems that refused to make that tradeoff never became successful. so one could make a post hoc argument that unsoundness is simply a lesser evil than not having full JavaScript compatibility.
- Silhouette 6y ago
  A decision can be rational but still, as the article says, unfortunate. Yes, it probably is the lesser evil to accept the typing wart and maintain compatibility. It's still a glaring hole in the type system of a language whose main raison d'etre is its type system.
hibbelig 6y ago
I’m surprised about the map thing, too. The period also has two meanings and nobody complains. Compare 1.3 with a.b — same character, two meanings.

arduanika 6y ago

3. What he's calling unfortunate is not that negative indices don't work in JavaScript, but rather that it silently returns undefined instead of raising

qsort 6y ago
That behavior does make sense in the context of Javascript. > {a: 1, b: 2}['c'] undefined > {1: 1, 3: 2}[2] undefined If you're arguing that JS objects shouldn't be like that, you do have a point. But taking JS basic semantics as a given, I don't see what other behavior you would expect.
- robertlagrant 6y ago
  The point is in the context of lists, not objects. It's in the article.
  - ulucs 6y ago
    But lists are objects, with negative indices as possible keys: > const l = [1,2,3]; undefined > l.a = l; [ 1, 2, 3, a: [Circular] ] > l === l.a true > l[-1] = 0; 0 > l [ 1, 2, 3, a: [Circular], '-1': 0 ]
    - Silhouette 6y ago
      Even without that argument, the behaviour is still consistent with other cases for arrays in JS anyway. > const a = [1, 2]; > a[0] 1 > a[2] undefined > a[-1] undefined
    - robertlagrant 6y ago
      And positive indices not as possible keys, but as array elements. It's crazily inconsistent. > l = [1,2,3] (3) [1, 2, 3] > l[3] = 4 4 > l (4) [1, 2, 3, 4] > l[-1] = "eek" "eek" > l (4) [1, 2, 3, 4, -1: "eek"] So adding a 4 as a "key" is a proper array element; adding -1 is an object key. I'm struggling to see how anyone could think this is a good idea. Saying that they're objects is not reasonable. Objects don't need to do this (in most languages lists are objects, and they don't also do key-value pairs at the same time); they just decided to make them do this.
      - qsort 6y ago
        It's extremely consistent. I'd say that's the only consistent way to do it, if you want to preserve the semantics of JS objects. Lua does pretty much the same. > Saying that they're objects is not reasonable. This is a fair point, in the alternate universe where JS objects have different semantics. > in most languages lists are objects, and they don't also do key-value pairs at the same time This is a dynamic language we're talking about. You are very welcome to think dynamic languages are inferior choices, an opinion that I personally would share, but that's a discussion for another time. In the context of JS, that behavior is neither unreasonable nor inconsistent.
        robertlagrant 6y ago
        Python is also dynamic. That has nothing to do with this. >>> l = [] >>> l.x = "hello" Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'list' object has no attribute 'x' Always adding arbitrary properties to an object is not a dynamic thing, it's just a bit silly. At best you could say it's a weak typing thing, but even then, it doesn't need to be.
  - tsimionescu 6y ago
    In JS semantics, lists (by which I assume you actually mean arrays) are just objects with numeric keys. Nothing special about them, except that there are certain functions which assume the objects they take in have only numeric keys starting from 0 and always increasing (they usually ignore non-numeric keys that those objects might have). This is similar to LISP, where you can build many kinds of structures out of cons cells, and you have certain families of functions that assume that the cons cells you pass in have certain kinds of structures, defining lists or trees or association lists etc.

swyx 6y ago

4 is not an issue given that basically all other JavaScript typing systems that refused to make that tradeoff never became successful. so one could make a post hoc argument that unsoundness is simply a lesser evil than not having full JavaScript compatibility.

Silhouette 6y ago
A decision can be rational but still, as the article says, unfortunate. Yes, it probably is the lesser evil to accept the typing wart and maintain compatibility. It's still a glaring hole in the type system of a language whose main raison d'etre is its type system.

hibbelig 6y ago

I’m surprised about the map thing, too. The period also has two meanings and nobody complains. Compare 1.3 with a.b — same character, two meanings.