4 ms·

I don’t mean to hate on ECMAScript, but is anyone else slightly surprised these features weren’t in earlier? Like I wonder how many bugs were introduced becaus

I don’t mean to hate on ECMAScript, but is anyone else slightly surprised these features weren’t in earlier? Like I wonder how many bugs were introduced because the developer didn’t realize Array.sort() was unstable.

haxiomic 7y ago
Another sort() quirk that catches people out is not realising it uses string comparison by default [1,2,10].sort() = [1,10,2]
- croo 7y ago
  js never ceases to amaze me... O_o
- tempguy9999 7y ago
  > is not realising it uses string comparison by default Hell, really?? That's gross. As for the parent's comment about a dev "not realising array.sort() was unstable", the dev should know his tools. I can't see anyway why a stable sort is better, I've never sorted on x then sorted on x, you just sort on x & y.
  - inferiorhuman 7y ago
    Hell, really?? That's gross. It's just using the == operator, no? Which, yes, is really gross.
- alkonaut 7y ago
  It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. If the comparison function argument was mandatory in sort() this wouldn’t be a problem.
  - masklinn 7y ago
    > It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. Stupid defaults is not "the curse of optional arguments", it's the curse of stupid defaults. Most languages have defaults for these two operations yet have proper defaults rather than stupid ones. Python's list.sort() and int() certainly do, so do Java's Collections.sort() and Integer.parseInt(). Uniquely awful defaults is a historical (and defining) feature of javascript, not of having default values, or optional arguments.
    - alkonaut 7y ago
      The horror that arises in js is due to a combination of unfortunate things like function arity, and coercion. The one I was thinking of is the famous [1,2,10].map(parseInt) It’s several things that on their own aren’t mad which taken together produces a crazy result. 10 as the default for an optional second argument of parseInt is fine. But map should only use a single argument closure by default. So map(parseInt) must be equivalent to map(x -> parseInt(x)).
  - Legogris 7y ago
    A different comparison function would not make efficient QuickSort stable.
    - alkonaut 7y ago
      It’s not the stability that bothers me but the fact that the comparison function is implicit and basically is (a, b) -> a.toString().compareTo(b.toString()) Unlike say int.parse() where 10 is a reasonable default for radix, doing string comparison as default is almost never what the caller wants, so is a bad default. Functions where there is no obvious (99% of the time the desired value) should not have a default value when the argument is omitted. I’d much rather have things.sort() just fail and force me to specify the comparison, than to see it sort alphabetically. As a side note: a second optional argument specifying stability true/false would be reasonable. True could be the default too, since unstable sorting is effectively an optimization with a tradeoff.
- willtim 7y ago
  Wow, who came up with that idea? And people say Haskell is hard to learn...
  - marcosdumay 7y ago
    Weak types. When neither the function nor the parameters have hard types, you have to create heuristics. There could be a test for numbers there, but it would also be surprising because at the older days people expected "10" and 10 to behave the same.
    - willtim 7y ago
      Most would expect 10 to parse as an integer. To specify a string, most would be happy with putting quotes around it. So I don't think dynamic types fully explains the bizarre behaviour.
      - matthuggins 7y ago
        What if you tried to sort an array of objects or functions?
        willtim 7y ago
        If one doesn't specify a comparator and there is no obvious/sensible default, then an error would be perfectly reasonable.
    - bernawil 7y ago
      It's not because of "weak types" since the types inside the array don't get their type information erased. It's because Array.sort takes a comparison function but the default function instead of being something like [1, 10, 2].sort((a,b) => a > b ? 1 : -1) // -> [1, 2, 10] is something like // [1, 10, 2].sort((a,b) => a.toString() > b.toString() ? 1 : -1) // -> [1, 10, 2] because someone thought that it was "best" to cast stuff to string in case whatever you put in the container didn't implement comparison.
paulddraper 7y ago
> developer didn’t realize Array.sort() was unstable You seem to think stable sort is much more important than most of the rest of the field. By default, C sort isn't stable, C++ sort isn't stable, Ruby sort isn't stable, C# sort isn't stable, Perl sort isn't stable. Hell, not even GNU's sort utility is stable. JavaScript has some unexpected idiosyncracies, but sort() stability isn't one of them.

haxiomic 7y ago

Another sort() quirk that catches people out is not realising it uses string comparison by default [1,2,10].sort() = [1,10,2]

croo 7y ago
js never ceases to amaze me... O_o
tempguy9999 7y ago
> is not realising it uses string comparison by default Hell, really?? That's gross. As for the parent's comment about a dev "not realising array.sort() was unstable", the dev should know his tools. I can't see anyway why a stable sort is better, I've never sorted on x then sorted on x, you just sort on x & y.
- inferiorhuman 7y ago
  Hell, really?? That's gross. It's just using the == operator, no? Which, yes, is really gross.
alkonaut 7y ago
It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. If the comparison function argument was mandatory in sort() this wouldn’t be a problem.
- masklinn 7y ago
  > It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. Stupid defaults is not "the curse of optional arguments", it's the curse of stupid defaults. Most languages have defaults for these two operations yet have proper defaults rather than stupid ones. Python's list.sort() and int() certainly do, so do Java's Collections.sort() and Integer.parseInt(). Uniquely awful defaults is a historical (and defining) feature of javascript, not of having default values, or optional arguments.
  - alkonaut 7y ago
    The horror that arises in js is due to a combination of unfortunate things like function arity, and coercion. The one I was thinking of is the famous [1,2,10].map(parseInt) It’s several things that on their own aren’t mad which taken together produces a crazy result. 10 as the default for an optional second argument of parseInt is fine. But map should only use a single argument closure by default. So map(parseInt) must be equivalent to map(x -> parseInt(x)).
- Legogris 7y ago
  A different comparison function would not make efficient QuickSort stable.
  - alkonaut 7y ago
    It’s not the stability that bothers me but the fact that the comparison function is implicit and basically is (a, b) -> a.toString().compareTo(b.toString()) Unlike say int.parse() where 10 is a reasonable default for radix, doing string comparison as default is almost never what the caller wants, so is a bad default. Functions where there is no obvious (99% of the time the desired value) should not have a default value when the argument is omitted. I’d much rather have things.sort() just fail and force me to specify the comparison, than to see it sort alphabetically. As a side note: a second optional argument specifying stability true/false would be reasonable. True could be the default too, since unstable sorting is effectively an optimization with a tradeoff.
willtim 7y ago
Wow, who came up with that idea? And people say Haskell is hard to learn...
- marcosdumay 7y ago
  Weak types. When neither the function nor the parameters have hard types, you have to create heuristics. There could be a test for numbers there, but it would also be surprising because at the older days people expected "10" and 10 to behave the same.
  - willtim 7y ago
    Most would expect 10 to parse as an integer. To specify a string, most would be happy with putting quotes around it. So I don't think dynamic types fully explains the bizarre behaviour.
    - matthuggins 7y ago
      What if you tried to sort an array of objects or functions?
      - willtim 7y ago
        If one doesn't specify a comparator and there is no obvious/sensible default, then an error would be perfectly reasonable.
  - bernawil 7y ago
    It's not because of "weak types" since the types inside the array don't get their type information erased. It's because Array.sort takes a comparison function but the default function instead of being something like [1, 10, 2].sort((a,b) => a > b ? 1 : -1) // -> [1, 2, 10] is something like // [1, 10, 2].sort((a,b) => a.toString() > b.toString() ? 1 : -1) // -> [1, 10, 2] because someone thought that it was "best" to cast stuff to string in case whatever you put in the container didn't implement comparison.

paulddraper 7y ago

> developer didn’t realize Array.sort() was unstable You seem to think stable sort is much more important than most of the rest of the field. By default, C sort isn't stable, C++ sort isn't stable, Ruby sort isn't stable, C# sort isn't stable, Perl sort isn't stable. Hell, not even GNU's sort utility is stable. JavaScript has some unexpected idiosyncracies, but sort() stability isn't one of them.