3 ms·

> 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, gettin

• masklinn 13y ago
  > 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)
  • weland 13y ago
    > 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.
    • masklinn 13y ago
      > 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.
      • weland 13y ago
        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...
• anon1385 13y ago
  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: list(-3, 4, 10, 6, 1, 2) sort ==> list(-3, 1, 2, 4, 6, 10) And to show that you can implement the Javascript behaviour in a language without implicit type conversions: list(-3, 4, 10, 6, 1, 2) map(asString) sort ==> list(-3, 1, 10, 2, 4, 6) 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.