Think of digits like you would letters. You’re essentially sorting numbers alphabetically. It’s not the right way to do it, of course, but it’s the natural way to do it using a system like computers use that doesn’t necessarily differentiate between digits and letters unless you tell it to specifically.
I think the main shortcoming here is that there isnt a way to specify the type to sort as, instead you have to write the function to compare them as numbers yourself. If it’s such a simple implementation, why isn’t it officially implemented? Why isn’t there a sortAs() that takes two args, the input list, and a Type value? Check every element matches the type and then sort, otherwise return a Type Error.
I mean, there’s a sort() method that takes a comparator(a,b) such that if a comes first it returns 1, if b comes first it returns -1 and if they’re equivalent wrt sortinf it returns 0. If you absolutely need type safe number sorting you can use that to get it.
Right, but you have to make that comparator yourself, it’s not a built-in part of the language. The only built-in comparator converts values to strings and compares them in code units orders.
Also, that technically isnt type-safe, is it? If you threw a string or a NaN at that it would fail. As far as I knew, type safe means that a function can handle type errors itself, rather than throwing an exception. So in this case the function would automatically convert types if it was type-safe to prevent an unhandled exception.
Not every use case can be the built-in default. I wouldn’t have made JS weakly typed if I were designing it, but once the decision was made to use weak typing it made sense to either have no default sort method or to have a default sort method that assumes a type.
What I’ve outlined for you is the interface for a comparator, not the implementation. You can type check and convert and do anything else you want under the hood of the comparator you write.
It doesn’t have to be the default to be built in, tho. It could be an overloaded function, having the “default” be the typical convert-to-string sorting, and an overloaded function that allows to specify a type.
It’s just such a common thing, wanting to sort a list by different types, that I’m surprised there hasn’t been an official implementation added like this. I get that it a simple “fix” to make, but I just think that if it’s that simple yet kind of obscure (enough that people are still constantly asking about it) there should be an official implementation, rather than something you have build yourself.
Thats just JS for you. If you’re being generous, it’s a “quirky” language. If you’re being ungenerous, it’s a steaming pile of arbitrary decisions, gotchas, unexpected behaviors and problems that no one bothered to solve because there’s a workaround.
Yeah, JS always seemed like the red-headed stepchild of modern languages. I’d be curious to know if other ECMAScript languages like JScript are as, eh, “quirky”, suggesting that the ECMA spec is the source of the quirkiness, or if JavaScript itself is the one making silly decisions. Technically, I mostly work with Google’s AppScript when I use ECMAScript stuff, but I’m fairly certain AppsScript is based off of JavaScript instead of directly based on the ECMA spec, so I don’t think it’s separate enough for me to draw a conclusion there.
Think of digits like you would letters. You’re essentially sorting numbers alphabetically. It’s not the right way to do it, of course, but it’s the natural way to do it using a system like computers use that doesn’t necessarily differentiate between digits and letters unless you tell it to specifically.
I think the main shortcoming here is that there isnt a way to specify the type to sort as, instead you have to write the function to compare them as numbers yourself. If it’s such a simple implementation, why isn’t it officially implemented? Why isn’t there a sortAs() that takes two args, the input list, and a Type value? Check every element matches the type and then sort, otherwise return a Type Error.
I mean, there’s a sort() method that takes a comparator(a,b) such that if a comes first it returns 1, if b comes first it returns -1 and if they’re equivalent wrt sortinf it returns 0. If you absolutely need type safe number sorting you can use that to get it.
Right, but you have to make that comparator yourself, it’s not a built-in part of the language. The only built-in comparator converts values to strings and compares them in code units orders.
Also, that technically isnt type-safe, is it? If you threw a string or a NaN at that it would fail. As far as I knew, type safe means that a function can handle type errors itself, rather than throwing an exception. So in this case the function would automatically convert types if it was type-safe to prevent an unhandled exception.
Not every use case can be the built-in default. I wouldn’t have made JS weakly typed if I were designing it, but once the decision was made to use weak typing it made sense to either have no default sort method or to have a default sort method that assumes a type.
What I’ve outlined for you is the interface for a comparator, not the implementation. You can type check and convert and do anything else you want under the hood of the comparator you write.
It doesn’t have to be the default to be built in, tho. It could be an overloaded function, having the “default” be the typical convert-to-string sorting, and an overloaded function that allows to specify a type.
It’s just such a common thing, wanting to sort a list by different types, that I’m surprised there hasn’t been an official implementation added like this. I get that it a simple “fix” to make, but I just think that if it’s that simple yet kind of obscure (enough that people are still constantly asking about it) there should be an official implementation, rather than something you have build yourself.
Thats just JS for you. If you’re being generous, it’s a “quirky” language. If you’re being ungenerous, it’s a steaming pile of arbitrary decisions, gotchas, unexpected behaviors and problems that no one bothered to solve because there’s a workaround.
Yeah, JS always seemed like the red-headed stepchild of modern languages. I’d be curious to know if other ECMAScript languages like JScript are as, eh, “quirky”, suggesting that the ECMA spec is the source of the quirkiness, or if JavaScript itself is the one making silly decisions. Technically, I mostly work with Google’s AppScript when I use ECMAScript stuff, but I’m fairly certain AppsScript is based off of JavaScript instead of directly based on the ECMA spec, so I don’t think it’s separate enough for me to draw a conclusion there.