> And yes saying "oh but it is because it has dynamic types" doesn't excuse it
It has nothing to do with dynamic types[0]. It has to do with
> If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in lexicographic[0]
period end of the story. You might argue it's a shitty default, but please argue against reality, not what you (wrongly) believe it is.
[0] this is the MDN translation, the exact specification is steps 14 to 18 of the SortCompare abstract operation, defined in ECMA-262 5.1 15.4.4.11 "Array.prototype.sort (comparefn)":
13. If the argument comparefn is not undefined, then
a. If IsCallable(comparefn) is false, throw a TypeError exception.
b. Return the result of calling the [[Call]] internal method of comparefn passing undefined as the this value and with arguments x and y.
14. Let xString be ToString(x).
15. Let yString be ToString(y).
16. If xString < yString, return -1.
17. If xString > yString, return 1.
18. Return +0.
[0] your edition to "weak types" is just as wrong as the previous version I quoted was.
The correct answer is it has to do with weak types.
> `If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in lexicographic` period end of the story.
As I said explaining the historical context or labeling the brokennes with something like "weak typing" doesn't excuse. It still stays broken.
> You might argue it's a shitty default, but please argue against reality, not what you (wrongly) believe it is.
Surprise, I know it is possible to eventually sort things in JS. I too have seen sorted tables in JS done entirely in JS. That's not the point. The point is, it is has fundamentally broken type system.
> The correct answer is it has to do with weak types.
No, it does not. You could define the exact same default function in Java, Haskell (requiring that the sorted type be a Show instance) or Python (hell, getting the exact same behavior in Python could hardly be simpler: `ar.sort(key=str)`. There, I broke it. That is near literally how the ECMAScript spec very explicitly defines the default comparison function. The behavior of the sort function is not a consequence of weak typing).
> As I said explaining the historical context or labeling the brokennes with something like "weak typing" doesn't excuse.
Which you'd know is not what I'm doing, if you could be arsed to read instead of trying to substitute your imagination for objective reality.
> The point is, it is has fundamentally broken type system.
That might well be, but the default sort comparison function is not a demonstration of it. As opposed to the comparison table of 0 and null for instance:
> Yes it is. It demonstrates weak typing which I also think is broken.
For the third time, no. There is no implicit conversion process during the comparison, the default comparison is explicitly specified to convert both of its arguments to strings before doing the comparison.
Javascript does not trigger conversions to compare two numbers, so relying on the type system would actually do exactly what you want.
> You broke it by writing more code.
Meanwhile you completely missed the point of posting the snippet.
> Javascript is broken __unless__ you write additional code.
And as I replied the first time around, I have no objection with the assertion that the default sort comparison function is garbage, I have an issue with your assertion that it is a consequence of weak typing because it is not.
> No, it does not. You could define the exact same default function in Java, Haskell (requiring that the sorted type be a Show instance) or Python (hell, getting the exact same behavior in Python could hardly be simpler: `ar.sort(key=str)`
I don't use JavaScript but to me this looks like a really broken implementation over weak typing. Of course, this isn't a trait of the typing system per se as it is a trait of the "interface", if you will, that it offers to the programmer.
What OP was probably annoyed by was the typical excuse the JS community offers for this behaviour: "it's weakly-typed so you can treat the arguments as anything you want". This misses the point of having a weak typing system: instead of using it to infer the type of the arguments and get a sane default comparison function, avoiding the verbosity typical of strongly-typed languages (where you have to specify the comparison function with the correct type signature), you have to specify the comparison function for anything that isn't a string. Bummer :-(.
I hope I haven't missed anything here; as I said, I'm not quite fluent in JavaScript.
Well as masklinn says this is a standard library function; the bad design is a property of that API and not inherent to the type system. It does perhaps reflect the 'philosophy' of Javascript, as evidenced by all the people in this thread defending this awful behaviour. Take the example of Io, which has a lot of similarities to JS but has stronger typing and syntax that I hope is fairly self explanatory:
Javascript merely defines the standard sort function to be the latter.
One difference between Io and Javascript is that
"10" > 2
throws an exception in Io (argument 0 to method '>' must be a Sequence, not a 'Number') so you can't sort a list that is a mixture of strings and numbers without explicitly converting them first (or using a custom comparator), since the standard sort function won't convert things for you (how would it know what you wanted to convert them to?). However that code is valid in Javascript, and actually returns 'true'. So the amusing thing here is that the > operator in Javascript actually does what you want (converts to numbers rather than strings) and if you sort with a custom comparator using the greater than operator then I presume it would give the correct result for an array of numbers. Something like this (disclaimer I'm not a Javascript developer, following code may be wrong):
[7, -3, 6, 10, 1].sort(function(a, b){return a > b ? 1 : -1;});
[-3, 1, 6, 7, 10]
For whatever bizarre reason the standard sort function is defined to convert to strings first.
> this looks like a really broken implementation over weak typing
No dammit, javascript does not coerce numbers to strings when comparing them, a "weak typing" implementation would behave exactly as he wants.
> What OP was probably annoyed by was the typical excuse the JS community offers for this behaviour: "it's weakly-typed so you can treat the arguments as anything you want".
That makes OP fractally wrong instead of merely broadly wrong.
> avoiding the verbosity typical of strongly-typed languages (where you have to specify the comparison function with the correct type signature)
Which you don't, not every language is Java and some actually have defaults. Which work. In fact, even in Java bloody java you don't have to provide a comparator to sort a list, as long as the list's items implement Comparable (that is, they can be compared to one another)
> No dammit, javascript does not coerce numbers to strings when comparing them, a "weak typing" implementation would behave exactly as he wants.
Please note that I wrote it's a broken implementation over weak typing, not of weak typing. The typing system is fine, at least as far as this matter is concerned, but the standard library is badly applied over it.
> Please note that I wrote it's a broken implementation over weak typing, not of weak typing.
But weak typing is a complete red herring, as I noted previously the behaviour of the default sort function is independent from the typing system, you could have a default sort function doing more or less the same thing in a very strict statically typed system.
Haskell's `sort` is defined (more or less) as
sort :: Ord a => [a] -> [a]
sort = sortBy compare
it could be (uselessly) defined as
sort :: Show a => [a] -> [a]
sort = sortBy (comparing show)
resulting in the same behaviour you see in javascript.
Yes, of course it is a red herring! OP's rage was against the JS community taking it as an excuse for shity implementation, that's all I was trying to clarify...
It has nothing to do with dynamic types[0]. It has to do with
> If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in lexicographic[0]
period end of the story. You might argue it's a shitty default, but please argue against reality, not what you (wrongly) believe it is.
[0] this is the MDN translation, the exact specification is steps 14 to 18 of the SortCompare abstract operation, defined in ECMA-262 5.1 15.4.4.11 "Array.prototype.sort (comparefn)":
[0] your edition to "weak types" is just as wrong as the previous version I quoted was.