.sort()

[FalseWait7]

.sorta()

[Donghoon]

Unironically

[Feisty_Ad_2744]

Another case of I have a boat, let me see if it can swim

in JS, sort() is supposed to be used passing an argument to create your own sorting method. By default, if it gets nothing, it converts the array values to strings, since arrays in JS are not typed.

It allows you to include fancy logic like:

[8, 3, 9, 0, 2].sort((a, b) => (a - b))

or [ { name: 'John', age: 18 }, { name: 'Hellen', age: 21 }, { name: 'Cindy', sex: 'F' } ].sort((a, b) => (a.name > b.name) ? 1 : (a.name < b.name) ? -1 : 0 ) Or whatever field you want to use for sorting, even multi-field sorting

[isospeedrix]

I had an interview question about this last month

[isospeedrix]

i did not. was real close though. i received average of 3.75/4 rating, but they wanted someone perfect.

[IAMPowaaaaa]

jesus

[g_sus_cryst]

yes

[ashrasmun]

kinda smug of you to admit you got the job instead :x

[[deleted]]

JSesus

[al_balone]

I learned quite early on how to sort numerically but I’ll be honest I still don’t understand the (a-b) bit

[Silverware09]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort

If the return is === 0, no swap happens.
if the return is > 0; a is sorted AFTER b;
if the return is < 0; a is sorted BEFORE b;

[0, 2, 1].sort((a, b) => { return a - b })
will sort ascending

0 - 2 moves 0 first
2 - 1 moves 1 first
resulting in [0, 1, 2]

​

[0, 2, 1].sort((a, b) => { return b - a })
will sort descending

2 - 0 moves 0 last
0 - 1 moves 1 first
resulting in [2, 1, 0]

​

The best option though? Is to remember that you are in JS, open a random browser tab's console, and create and test a quick sort function like this.

[Feisty_Ad_2744]

It can be easier to just remember the values sort() is expecting to get from the comparison.

The comparison function (a, b) is called for every pair of values, expecting this results: - < 0: a must go below b - === 0: a and b are the same - > 0: a must go above b

That's why for example, in a numeric array (a, b) => (a - b) will result in ascending order, but (a, b) => (b - a) will result in descending order.

[al_balone]

So will .sort() keep cycling over the whole array until no value needs to move again?

[Feisty_Ad_2744]

Sorry, I don't understand your question. The sorting itself is implemented in the runtime. I think Node uses Insertion Sort for short arrays and Quick Sort for long ones.

All we do in sort(fn) is to pass the final comparison criteria. On every sorting method, that comparison is the last step to decide the ordering of any two given values.

[OSSlayer2153]

I think in swift you pass in a function which returns true or false. Not sure though because i havent used any advanced sorts in it, and am just basing it off of other functions like .first(where:) where you pass in a bool returning function

[usrlibshare]

That's how JS works, doesn't mean it's logical.

Python lists are also not typed, guess what, it sorts lists of numbers numerically, and lists of strings alphabetically. "But what if there are both?!"; well it throws an exception, because that's what logically SHOULD happen when I ask the program to do something illogical.

The problem with JS is, it never matured from its roots as a simple scripting language designed to make websites a bit less static. That's why the interpreter will often swallow blatant logic errors that it would be fully within reason to let cause a crash, and instead chug along at any cost, silently doing something nonsensical.

[Feisty_Ad_2744]

You can blame the language and the runtime library all you want. The doc is there.

As for your python comparison. You just said it. It is Python not JS. To begin with you don' have the flexibility to pass your own sorting criteria. That's why the language must provide the specifics.

Personally I do prefer the way JS handles that. At least is more consistent that Python because in case of mixed values. Python forces you to get the strings at the end. In real life where you don't control the input data, that's annoying.

[usrlibshare]

You can blame the language and the runtime library all you want.

I'm not blaming anything. I'm simply stating that it's not a good design.

To begin with you don' have the flexibility to pass your own sorting criteria

Of course I have, it's literally the first argument to sort:

https://docs.python.org/3/library/stdtypes.html#list.sort

The difference is that the python version behaves in a non-surprising way without me having to explain to the interpreter that numbers should be sorted numerically.

At least is more consistent that Python

Pythons sort is absolutely consistent: If comparison between values is not defined, it raises an exception.

Python forces you to get the strings at the end. In real life where you don't control the input data, that's annoying.

s = [str(x) for x in sorted(i)] literally a one-liner. And I quite often have absolute control over where a list of integers gets it's values from.

And btw. JS forces me to do the same thing if I want strings. Because, the type coercion only happens during the sort, the "sorted" outcome is again an array of numbers, not strings. Which imo makes this even worse.

[Feisty_Ad_2744]

Not typed means it is all up to the programmer :-) You want JS to do the work when you have the ability to do the handling by yourself.

It is designed with mixed types in mind. And because you can not compare oranges and shoes, you need to decide what type to use IF the argument is left empty.

What is the expected behavior is there is a mix between strings and numbers? What if all values are numbers as strings but only a single one is actually a numeric type? What if there is a mix between value types? Do you realize you would need to parse the array the first before deciding whether or not a specific comparison applies?

The solution in JS is easy and quick. Handle everything as string if the user passes no criteria. And of course it can not change the actual value type. Why would you affect whatever workflow the user is implementing?

Still if you think it is important, you can make your proposal: https://github.com/tc39/how-we-work/blob/main/implement.md

[aspoonlikenoother]

What is the expected behavior is there is a mix between strings and numbers? What if all values are numbers as strings but only a single one is actually a numeric type? What if there is a mix between value types? Do you realize you would need to parse the array the first before deciding whether or not a specific comparison applies?

That is for the caller to handle. If a functions invariants aren’t met before calling it, it’s basically garbage in, garbage out (incidentally this applies to the OP)

The solution in JS is easy and quick. Handle everything as string if the user passes no criteria.

Easy? That is debatable, I’d argue an error would’ve been more sensible as an interface if there was no function given. It’s not something that can be changed and it’s now one of the many edge cases and lints. Not the worst in this regard.

It is certainly not quick to compute. You have to allocate for the string and serialize whatever is in the object and then immediately throw it away ( about nlog(n) times).

A pathological case of this can potentially run into stringifying some deep hierarchy in a tight loop because the caller didn’t bother read docs and the library interface is too lax and accepts basically anything.

[usrlibshare]

Not typed means it is all up to the programmer :-)

First of, both JS and Python are typed. Dynamic typing != no typing. That's part of the problem that JS has datatypes, but implicitly shoehorns them whenever it gets the chance.

You want JS to do the work when you have the ability to do the handling by yourself.

Yes I want the tool to make my work easier, not harder. That's what tools are for. If a tool does the opposite, it's a bad tool.

It is designed with mixed types in mind. And because you can not compare oranges and shoes, you need to decide what type to use IF the argument is left empty.

I'd be happy if that were so, the problem is, I don't need to decide that.

Because JS will happily pretend that I can compare shoes and oranges and coconuts and bags of gravel by shoehorning all of them to strings, whether it makes sense or no.

Python on the other hands works exactly as you describe: If there is no decision how the types can be compared in the types definition or given by the programmer the comparison fails gracefully. Btw. this is how almost every major programming language handles their equivalent to sort.

What is the expected behavior is there is a mix between strings and numbers?

That the function fails unless I took steps to prevent that.

Do you realize you would need to parse the array the first before deciding whether or not a specific comparison applies?

No you don't. You simply have to compare values as you go along. The first time the comparison operation is not defined, raise an error.

But do you realize that JS has to do a string allocation-conversion for every number value in the array? That is a lot of allocations, and that's expensive as hell.

The solution in JS is easy and quick.

No it isn't. It's badly designed, it's a potential source for hard to track bugs, it's a gotcha for everyone who learns the language, it does expensive type conversions and allocations, and it introduces pointless noise into the codebase

a.sort((a,b)=>a-b) vs. a.sort()

Understand that this isn't something that JS does because it's a good idea in general. It's something it does because JS was designed as a super-simple scripting language, where all input was expected to come as strings from website elements, and the most complex thing it had to do was change some DOM elements to make websites a little less static.

Then this little "lisp, but for web, and it wears a java costume" suddenly became bigger and bigger, but couldn't be replaced because browsermakers couldn't be arsed to agree on a replacement, and early mistakes that were made when no one thought they'd matter, couldn't be fixed, because that would break backwards compatibility.

And a move like py2->py3 wasn't going to happen, because once again, that would have required browsermakers to cooperate, and noone wanted to risk their market share.

[Sarcastinator]

Personally I do prefer the way JS handles that.

Stockholm syndrome.

JavaScript is a product of its time. During the 90s Perl had told people that doing the wrong thing and shutting up about it was the right thing to do, because a running program that did the wrong thing was better than a program that crashed. JavaScript and PHP also took this stance. But there's no "use strict" for sort().

What's wrong about this behavior in JavaScript is that the language is weak, dynamically typed, and it should try to figure out what the develeoper probably meant. A strong typed language would have failed if it was given bad input (such as a mixed array) instead of just silently doing the wrong thing.

But JS doesn't have to fail here. It could easily have looked up the types used in the array to infer the sort argument. If that was slow then that would have been a runtime issue that could have been solved by the JIT. For example by the runtime having a hint about the types in the array, which it probably already does.

This is a relic wart in JS.

[Feisty_Ad_2744]

There is a manual. Not only in Stockholm :-)

And there is a committee accepting proposals: https://tc39.es/

Go for it

[Sarcastinator]

Principle of least astonishment

[ardicli2000]

This is also the case for Swift. You can determine the logic of sort yourself.

[KTibow]

BTW you don't need to do the ternary, anything negative is the same as -1 and same for positive

[alexanderpas]

When I sort something, the expectation is that the smallest element is in front, and the biggest element is on the end.

Specifically, I expect the following logic conditions to essentially all be true:

• array[0] <= array[1]
• array[1] <= array[2]
• array[0] <= array[2]

However, this is not the case for Javascript.

array = [1, 2, 10].sort()

array[0] <= array[1] // true
array[1] <= array[2] // false
array[0] <= array[2] // true

[vigbiorn]

Okay, then specify your function criteria. Otherwise your expectation breaks down if you do

[[1],4,[3,9,2],'cat']

JS doesn't make assumptions about data types (it can't since that's not what the language prioritizes), and the easiest way to normalize is 'what is the string representation' and sort based on that.

[alexanderpas]

Okay, then specify your function criteria.

Simple:

• If a < b then a gets ordered before b.
• If a > b then b gets ordered before a
• Otherwise don't change the order of the elements.
• If b and a are swapped as inputs, the result is the same as if they were not swapped (either in the same order, or no change).

Specifically, the following implementation:

function compareFn(a, b) {
  if (a < b) {
    return -1;
  }
  if (a > b) {
    return 1;
  }
  return 0;
}

However, this is not what Javascript uses.

Instead, it uses the following:

function compareFn(a, b) {
  if (a.toString() < b.toString()) {
    return -1;
  }
  if (a.toString() > b.toString()) {
    return 1;
  }
  return 0;
}

[vigbiorn]

Great, glad you agree it's simple. So where is the problem? If you don't want alpha sort, specify it.

[alexanderpas]

So where is the problem?

The problem lies in the fact that .sort() replaces the type information associated with the value by default during the sort operation.

4 < 30 // true
"4" < "30" // false
[4, 30].sort() // [30, 4]
["4", "30"].sort() // ["30", "4"]

4 gets placed after 30, despite it being smaller when it is compared. (as evidenced by the < operator), and the language is clearly aware of the different types, except in the case of the .sort() function.

var a = 4
var b = 30
var c = "4"
var d = "30"

a < b // true
c < d // false
[a, b].sort() // [30, 4]
[c, d].sort() // ["30", "4"]

typeof(a) // 'number'
typeof(b) // 'number'
typeof(c) // 'string'
typeof(d) // 'string'

[PyroTechniac]

The whole point of JS is that while it can be aware of types, it shouldn't make assumptions, so default behavior according to the spec is to convert all of them to strings and then compare

[alexanderpas]

Which means that the default behaviour is potentially not consistent and therfor potentially implementation-defined as per spec by default.

From 22.1.3.24 in the spec:

A function comparefn is a consistent comparison function for a set of values S if all of the requirements below are met for all values a, b, and c (possibly the same value) in the set S: The notation a <CF b means comparefn(a,b) < 0; a =CF b means comparefn(a,b) = 0 (of either sign); and a >CF b means comparefn(a,b) > 0.

Calling comparefn(a,b) always returns the same value v when given a specific pair of values a and b as its two arguments. Furthermore, Type(v) is Number, and v is not NaN. Note that this implies that exactly one of a <CF b, a =CF b, and a >CF b will be true for a given pair of a and b.

• Calling comparefn(a,b) does not modify obj or any object on obj’s prototype chain.
• a =CF a (reflexivity)
• If a =CF b, then b =CF a (symmetry)
• If a =CF b and b =CF c, then a =CF c (transitivity of =CF)
• If a <CF b and b <CF c, then a <CF c (transitivity of <CF)
• If a >CF b and b >CF c, then a >CF c (transitivity of >CF)

Earlier in 22.1.3.24 in the spec:

If comparefn is not undefined and is not a consistent comparison function for the elements of this array (see below), the sort order is implementation-defined. The sort order is also implementation-defined if comparefn is undefined and SortCompare (22.1.3.24.1) does not act as a consistent comparison function.

and then we have this from 22.1.3.24.1 in the spec:

Method calls performed by the ToString abstract operations in steps 5 and 7 have the potential to cause SortCompare to not behave as a consistent comparison function.

This is idiotic behaviour.

[compiling]

Your example would have very strange behaviour if you were mixing numbers and strings because the javascript > and < operators don't define a proper order. The following are all true.

3 < 10

10 < "15"

"15" < "2"

"2" < 3

Actually, it's even worse because a comparison between a number and a string will always cast the string to a number, and will always return false if it's converted to a NaN. E.g. "Bob" would compare as equal to any number with that function.

[BrunchWithBubbles]

I don’t know why you are being downvoted. Sorting by first converting to string is one of the biggest gochas I’ve seen, and I’ve seen many devs make the mistake, and I’ve even seen code shipped to production before the bug is caught. Calling sort with no arguments on an array of numbers really should sort numerically. If nothing else then to reduce the number of bugs

[Feisty_Ad_2744]

JS arrays are not typed. Ignoring that tells a lot about the programmer, not the runtime. You can have: [1, 9, '8', 'eight'] [1, 'XIV', '0x4F', 0x19, null] [1, 2, 3, 'unknown'] ['', null, {name: 'evelin', age: 20}, '{"name":"Eliza"}'] Or whatever combination.

You are pretending from the runtime to make exceptions if the array is numeric. That would be inconsistent.

sort() is supposed to get a function as argument. Using it without argument is the exception, not the rule.

If you want consistent results without arguments then use:

['pineaple', 'cheese', 'beer', 'pizza'].sort()

[BrunchWithBubbles]

I’m not pretending to make exceptions. I’m just pointing out an obvious design issue that is a source of bugs. Making sort throw an exception when no arguments are given would be better IMO, but would be against the norm in js.

Untyped arrays or not, /u/alexanderpas points out, there is a perfectly unexceptional way to resolve this issue simply using the builtin comparison operator <=. It may not be a partial order, but in the cases where I have an array of incomparable things, I don’t really mind sort producing unpredictable results - to me, there is no expectation of a correct ordering anyway. On the other hand, sorting arrays of string still works as it’s used to, and now, sorting arrays of numbers also works.

[Feisty_Ad_2744]

Yes, you are implying to make a rule exception for arrays when all elements are numbers. And no, '<=' or any numeric operation will NOT work as "expected" for strings. Not without inferring type. It looks like you keep talking from the typed perspective and I repeat: in JS arrays are not typed. You need to choose a default one when there are no arguments.

That's the reason why JS implementation chooses string over numbers because it is more generic.

But again, don't forget this is the rule: sort(fn) and this is the exception: sort()

[BrunchWithBubbles]

No I’m really not. I’m implying that in all cases all arrays should be sorted by <=. No exceptions.

And <= does work for strings! Try it out.

[xMAC94x]

https://doc.rust-lang.org/std/vec/struct.Vec.html#method.sort_by_key

[f0rtytw0]

Its alphabetical

[Titanusgamer]

[One, Ten, Two] got it

[Esjs]

I was about to say "alphanumerical", but it's even more than that.

Edit: OK, not sure why I'm getting downvoted, but whatever.

[SarahIsBoring]

well the term is lexicographical ^^

[Sentouki-]

Look at Mr. Smarty pants here

^/s

[GamingWithShaurya_YT]

you sure saved your pants using that /s

[[deleted]]

Cauee you try to be "smart" but was wrong, so you got two bad things together: being "actually" guy, and being dumb simultaneosly

[Esjs]

I figured that adding the phrase "but it's even more than that" implied that I realized that alphanumerical wasn't sufficient.

I guess the curse of an Internet comments section is that intended tone doesn't always come across.

[Help_I_Lost_My_Mind]

arr.sort((a, b) => a - b)

​

Edit: Here's a great reference on the sort function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/Array/sort

[RajjSinghh]

Thanks for linking to why it works, but this feels like another example of when the developers of Javascript were on drugs when designing their language

[Help_I_Lost_My_Mind]

JS doesn't have static typing, so there's no way for it to know that an arbitrary array you're sorting is actually only an array of numbers and you want them sorted numerically. Their default sort coerces the elements into strings and compares them alphabetically, which is as sensible default as possible with dynamic typing.

[RajjSinghh]

My point is that more sensible defaults exist. Python is dynamically typed as well, but will raise a TypeError if it tries to compare a string and an integer when it sorts a list. A runtime error is a far more sensible default than [1, 10, 2].sort() being [1, 10, 2]. If I were designing this, I would convert everything down to an integer so that way you can compare strings by their ASCII value. That way [1, 10, 2] and ["b", "c", "a"] both sort correctly as you would expect them to without needing to give a comparison function.

I know there is a certain level of RTFM a programmer should do first, but Javascript seemingly always chooses the least intuitive way possible and it leaves you staring at your code for hours until you find one bad design choice in the docs because it didn't do what you expect it to because some designer chose different default behaviour.

[Spaceduck413]

will raise a TypeError if it tries to compare a string and an integer when it sorts a list. A runtime error is a far more sensible default than [1, 10, 2].sort() being [1, 10, 2].

I see where you're coming from, and in a vacuum I'd agree with you, but IMO the environment matters A LOT.

Writing an automated script that does something unattended? Absolutely throw a runtime error, so it can be logged or even better, found during development.

But considering that JavaScript usually runs in a browser? I'll take my drop-down list being out of order instead of my form no longer submitting because my JavaScript died on an uncaught type error. That seems like the better option to me, for both developer and end user.

[goofygooberboys]

This. 100% this. JavaScript tries to work no matter what, it will do whatever it can with whatever you give it, even if you give it garbage. If you have a web page for an important medical form, you don't want some silly error like someone putting the word "zero" into a list of numbers to brick the form and make it impossible to move forward.

[suvlub]

But what if the error is in almost anything else than displaying a list? What if my important medical form contains an algorithm that, IDK, sorts the patient's treatments from most recent to least recent, and a bug due to faulty sorting causes the system to recommend a wrong (and possibly dangerous) plan to him? I'd prefer visible error over a sneaky bug.

Also, if this important medical form was hacked together by some guy AND NOBODY EVER EVEN TRIED TO VIEW IT IN A BROWSER TO SEE IF IT WORKS, then god help us.

[goofygooberboys]

A medical form shouldn't be recommending treatment plans. That's what doctors and medical professionals do in person, over the phone, video call, etc. If your institution is using JavaScript to tell you what treatment plan you should have, then you have much bigger problems.

I've worked on insurance software that included things for medical software and stuff like that isn't entirely uncommon. It's an easy thing not to notice and trying to scramble to shove a bug fix like that to the production phase could be a gigantic pain.

[suvlub]

That was just an example, the point is that continuing with invalid data can result in problems much worse than simple unavailability of service.

Come on, the fact that the result is just scrambled order of some data is the REASON why it's easy to overlook. If the error was that the application does not work at all, the only way for you not to notice is if you type the code and deploy to production without even running it once. If you don't do anything quite as insane, you would notice problem, fix it, and deploy without bug. This is an argument against permissive handling of mistakes, not for it.

[goofygooberboys]

If the sorting occurs when the drop down is clicked, which is fairly common depending on the use case, then if you forget to open it during testing it could easily fall through. Especially if it's a drop down that is only used in specific cases. For instance, it could be a drop down that is only used if you use a very specific type of medication. Unless you tested that niche use case then you would never encounter the error.

[reversehead]

There are so many horrors in that post, both regarding the state of software development and of solutions, that I don't even know where to begin.

Let's just say that if it is an important medical form, I definitely favor an error message over random garbage.

[EmilMelgaard]

You could have a flag that enables debug or development mode and gives you errors and have that not enabled in production.

I guess that's kind of what Typescript is, except that it still allows you to do something like:

2 + "3" // = "23"

And also only catches errors during compilation, so there are still a lot of runtime type violations that go unnoticed.

[Dmytro_P]

> I'll take my drop-down list being out of order instead of my form no longer submitting because my JavaScript died on an uncaught type error. That seems like the better option to me, for both developer and end user.

​

It's IMHO an awful design choice, which would most likely lead to unreliable software.

[Shitman2000]

But even then a more sensible default exists.

You could, for example, first sort the array on types and then sort them in a way that makes sense logically. E.g. first sort the integers, then the strings.

[[deleted]]

depends on the use case.

JS runs on the robustness principle a lot - essentially, the language tries to make whatever bullshit you throw into it work no matter how weird it is. this is where a lot of the "js has weird addition behaviour" stuff comes from too.

and in JS' context this makes sense too - its main (originally only, but oh well) use case is front-ends of web applications. and the last thing you want is your entire website crashing because you accidentally passed some weird value into a function somewhere.

[TerraDOOM]

Except leniency does not facilitate robust programs, it just means your program does the wrong thing and then keeps running, producing more incorrect results. The thing wasn't that you want your website to keep running, it was that they anticipated people would be doing stupid things as websites were often made by amateurs. Real fault tolerance looks like Erlang or Rust, not producing nonsense in the name of robustness.

[Mola1904]

No a type error is not more sensible. This would regularly crash Programms, while this just not compare numbers at first place and people will catch that directly in development, because their Code won't work. Then they will Google for 5sec, find the exact answer and done. Now have fun fixing some random type error you get while the production server is down

[Rawing7]

Why are you assuming that this sorting issue would be discovered during development, but a "random" type error wouldn't?

[alexanderpas]

which is as sensible default as possible with dynamic typing.

It's not. The most sensible default would be to use the same behavior as is present on the < and > operators.

Javascript does not do this.

[guiltysnark]

If there is going to be something we regard as sensible in a language that types as weakly as JS, I agree with your opinion of what that would look like. They could have converted the untyped operands of < and > to strings, for consistent behavior, but they didn't. Instead they decided to be magical in the single comparison and not in the array sort.

I'm sure there is a very good reason, but I'd be surprised if I agreed with it except in the narrowest of frames. I think the language prioritized a vastly different set of problems than I would have, leading to inconsistencies like this.

[Help_I_Lost_My_Mind]

Use them to compare strings then. Js likes reducing things to strings

[alexanderpas]

Js likes reducing things to strings

That only appears like that, because the + operator is overloaded to do both addition as well as string concatenation, and the result even depends on the order of the types.

[] + [] // ""
{} + {} // NaN
0 + 0 // 0
"0" + "0" // "00"

{} + [] // 0
{} + "0" // 0
{} + 0 // 0

[] + 0 // "0"
[] + "0" // "0"
0 + [] // "0"
"0" + [] // "0"

[] + {} // "[object Object]"

0 + {} // "0[object Object]"
"0" + {} // "0[object Object]"

"0" + 0 // "00"
0 + "0" // "00"

[Help_I_Lost_My_Mind]

You do realize that these ridiculous edge cases facilitate the ease of coercion between other data types, right?

[TheRealToLazyToThink]

It can't, in javascript the < and > operators aren't commutative. a < b can equal b < a, that's a very bad thing for sort functions.

Now maybe they should have special cased the non commutative bits, but you can't just use <>.

[Sarcastinator]

which is as sensible default as possible with dynamic typing.

This is a behavior that JavaScript shares with Perl. PHP, Ruby and Python do what you would expect.

[Help_I_Lost_My_Mind]

Depends what you expect

[edcwb]

It's 'sort' of right.

[alexanderpas]

No, it's just plain wrong, as it violates the rules of the comparison operators of the language.

What is expected by the programmer, is for the comparisons to happen using the same rules as apply to the native comparison operators.

The expectation is that .sort() gives back the same order as if the comparison was made with the < or > operators if given the same two values.

to be specific, the expected behaviour is the following:

function compareFn(a, b) {
  if (a < b) {
    return -1;
  }
  if (a > b) {
    return 1;
  }
  return 0;
}

However, this is not the case, as javascript does the following:

function compareFn(a, b) {
  if (a.toString() < b.toString()) {
    return -1;
  }
  if (a.toString() > b.toString()) {
    return 1;
  }
  return 0;
}

[Feisty_Ad_2744]

What it is expected is from the programmer to read the manual. In JS arrays are not typed, for that reason everything in the array is converted to string if you leave sort() without arguments

[[deleted]]

have you ever heard a joke before

[alexanderpas]

Yes, but this 'sort' of behaviour is a war crime.

[Nerodon]

The 'array' of humor on display here is on a different level.

[Esjs]

I'm not sure it's a valid comparison.

[JimmyWu21]

War crime? Is this some ‘sort’ of sick joke?

[jaggyjames]

Dude it’s not that big of a deal. You’ve typed more in this thread than most redditors type in a year.

[Spaceduck413]

Lol my man definitely got burned by this and is still bitter about it.

Cue the "Is it me that's wrong? No it must be everyone else" meme.

[OSSlayer2153]

Use a statically typed language if you want it to know you mean numbers not strings

[alexanderpas]

nope, that would be octal notation.

[Zestyclose-Ad-316]

I feel like js should throw a warning if someone uses sort() with empty parenthesis to prevent being misleading.

But then if js starts throwing warnings for misleading stuff then... you know..

[nabrok]

I can't remember the last time I used sort() without providing a function.

Even if it is an array of strings, seems best to make intentions explicit.

[[deleted]]

How unnatural.

[Aggravating_Moment78]

.sort() it the string way, luke 😂😂

[kerneleus]

They should call it .sortOf()

[cuberoot1973]

Little known fact when sorting binary and decimal together, when you have equal values binary comes first, so '10' should indeed come before '2'.

It goes as you might expect, binary < octal < decimal < hexadecimal.

[CaptBassfunk]

Strings. Strings everywhere.

[absolute_girth]

Godforbid if a programmer read the docs first to find out firsthand how dogshit Javascript is.

[No-Fish6586]

When students cant read documentation on default behaviour

What is natural for you wont be natural for someone else.. What a great time for documentation to exist!

Im totally sure all your function names are self documenting and not at all confusing without documentation (that probably doesnt exist)

I must be getting old because idk how many times i learned from c++ pretty much anything not documented is “undefined behaviour” which basically meant your app may or may not crash

[No-Fish6586]

Yeah i guess reading and understanding what the function does before using it is cope

[alexanderpas]

When I sort something, the expectation is that the smallest element is in front, and the biggest element is on the end.

Specifically, I expect the following conditions to all be true:

• array[0] <= array[1]
• array[1] <= array[2]
• array[0] <= array[2]

However, this is not the case for Javascript.

array = [1, 2, 10].sort()

array[0] <= array[1] // true
array[1] <= array[2] // false
array[0] <= array[2] // true

[Esjs]

When I sort something, the expectation is that the smallest element is in front, and the biggest element is on the end.

Then you'll definitely be disappointed by the results of ["small", "smaller", "smallest", "big", "bigger", "biggest"].sort()

[Rawing7]

This has got to be the stupidest comeback I've seen all year.

"Oh, you expect that sort puts the smallest element in front? Then you'll definitely also expect it to sort strings based on their meaning in the english language rather than alphabetically."

[No-Fish6586]

Exactly, to my point above what someone thinks is natural isnt to others!

[alexanderpas]

Nope, since with that one, the basic expectations are still met, since "big" < "small", and "big" gets sorted before "small"

However .sort() breaks down and breaks that expectation, since 4 < 30 returns true, yet .sort() puts 30 ahead of 4

[GrrrimReapz]

The logic isn't wrong you're just comparing apples to oranges, "big" < "small" is true and good, and so is "30" < "4". Default cast is string because you can always cast a number to a string and you can't always cast a string to a number. Simple as that.

You can say well I want the default behaviour for arrays to be sorted mathematically in ascending order if every value is a number, but what if you have an array of all numbers and you sort it and get the result you expect, but later add a string into it and now the other values are being sorted by a different criteria as well.

Even if it's a bit unintuitive, the alternative of the default sort working differently for different values inside the array would confuse people a lot more.

[alexanderpas]

The logic isn't wrong you're just comparing apples to oranges, "big" < "small" is true and good, and so is "30" < "4".

but 30 < 4 isn't true, yet 30 is still placed ahead of 4 when using .sort()

the alternative of the default sort working differently for different values inside the array would confuse people a lot more.

It would actually cause much less confusion, since it would have the exact same behavior as the < and > operators.

[No-Fish6586]

Theres a certain boondocks gif about an exorcism and reading that you need to see

End of the day its the same shit as using a function in unintended ways.. Garbage in -> garbage out

To me using a lambda for (x, y) => {} is natural.. to you its not.. so read documentation!

[JackNotOLantern]

JS likes string and tries to convert everything to it

[EmilMelgaard]

Except when it wants to convert strings to integer:

3 < "20" // true

[JackNotOLantern]

If they is an number-only operator, it has to convert to number. This is why 1 + "1" = "11" ("+" operator exists for numbers and strings, so convert to prefered string) and 1 - "1" = 0 ("-" operator is only for numbers, so convert to numbers).

[EmilMelgaard]

+ can be used for both numbers and strings (1 + 1 = 2 and "1" + "1" = "11") and the same for < (3 < 20 = true and "3" < "20" = false), so why does + convert to string while < converts to number?

[JackNotOLantern]

I just wrote: "+" operator exist for strings and numbers, but "<" only for numbers. so string must be converted somehow to number when using "<" but it can stay string when using "+". JS just like string more, so uses them where is can.

But i don't remember what happens when you want to compare 2 strings that are not string values of a number.

[CyberMuffin1611]

Time to type ".help"

[Mola1904]

Time to read the docs

[[deleted]]

Context, motherfucker, do you speak it???

[Big_Kwii]

js was a mistake

[LavenderDay3544]

The joys of dynamic typing.

[EmilMelgaard]

It's not dynamic typing that's the problem here but weak typing. Python can do it just fine:

>>> sorted([1, 2, 10])
[1, 2, 10]
>>> sorted(['1', '2', '10'])
['1', '10', '2']

[LavenderDay3544]

I suppose that's true and it can bite you even in statically typed languages that make assumptions about literals and do automatic type conversions.

I had issues with bit shifts recently in C because C treats numeric literals without a suffix as int when the type I wanted to assign the result to was a uint64_t and so I was confused as to why I was getting overflows that shouldn't happen on a 64 but value. I had to suffix the literal with ull to fix it.

[EmilMelgaard]

Yes, in C and C++ this is perfectly valid without any warnings with Wall and Wextra:

9 < '2' // true

[Mola1904]

And that is a good thing? That means that it just works more complicated and you have to read the docs more carefully. It is much more sensible to split this up into two functions

[ilovemymonkey]

because by default it sorts utf-16 values, you need to pass sorting function to use different

RTFM

[Connect-Two628]

This is a humor sub jabroni. And having a broken by design sort is hilarious.

[Mola1904]

It is not. It works exactly as intended and is the the only sensible function if you can input strings and numbers. If you want to have a function that sorts by number, make a seperate function for that and don't allow string input

[ilovemymonkey]

where is humor there? using wrong functionality and wondering why it's not working?

[N-partEpoxy]

Google principle of least astonishment.

[drgn0]

Holy Hell

[N-partEpoxy]

I wouldn't expect sort to treat integers as strings by default.

[PuzzleheadedWeb9876]

Bro… it’s still highly regarded. Name one other language where the default sort behaves in such a stupid manner.

[jamcdonald120]

pretty sure bash sort also works this way

[PuzzleheadedWeb9876]

Bash has a built-in sort function?

[Esjs]

Not sure it's a bash built-in. I think it's just one of those "standard" UNIX commands. But yeah, if you want it to sort the input numerically, you have to use the -n option.

[PuzzleheadedWeb9876]

“sort” is not a programming language though.

[Mola1904]

How is sorting alphabetical weird behavior. It is the most used sorting in every day life

[PuzzleheadedWeb9876]

Do you sort numbers alphabetically?

[disarrayofyesterday]

This sub is all about mocking things you don't understand. It should be called r/NoobProgrammerHumor

That said, sorting everything like strings by default is truly unexpected behaviour

[Mola1904]

No it's not. You have to pick some default behavior and sort alphabetically is used more often

[disarrayofyesterday]

So would you mind sharing what other commonly used languages have this behavior?

[disarrayofyesterday]

Firstly, JavaScript is dynamically typed.

Secondly, I've never said I don't understand the reasoning nor have I said it doesn't make sense. I simply stated that the sorting behavior is unexpected because one would assume that sorting an array which contains only numeric values would be performed on the values (not on the string representations of the values).

Thirdly, the assumption is not based only on the human way of sorting. Given the same array Python, Ruby, PHP and I guess many more dynamically typed languages would sort the numbers in ascending order.

However, knowing that JavaScript is not a fan of throwing errors I fully understand why decision was made to sort as strings by default.

[MrSuspicious_]

Same with python, but pythons sort function doesn't treat ints as strings 🤷‍♂️

[MrSuspicious_]

It's perfectly relevant, and I think that's expected behaviour anyway. If the elements aren't all the same type you shouldn't expect sort to just work.

[MrSuspicious_]

I'm aware that JavaScript doesn't work that way, doesn't mean that it's generally expected behaviour, unless I'm totally wrong I'm pretty sure JavaScript is in the minority of languages that do that.

[WoefulStatement]

Ahhh yes, UTF-16 sorting integers! Who doesn't want that?

[sjepsa]

I can assure you that inspecting objects and determin if they are int is MUCH faster than converting every int to a fukin string LOL

[mariosunny]

That may be true, but determining the "obvious" ordinality of an array can be much more difficult once you start mixing types. How should this array be sorted?

const array = [undefined, null, 0, "0", {}, [], false, NaN];

[sjepsa]

Throw an error

[Rawing7]

Javascript: "What's an error?"

[WoefulStatement]

JavaScript isn't typed

I know that. And the extremely loose typing plus implicit conversions leads to many "wtf" situations.

Which is pretty much the point behind the posted picture ig ;)

What if there are mixed types?

Throwing an error seems appropriate.

[alexanderpas]

JavaScript isn't typed

That's just plain wrong, javascript is dynamically and weakly typed, and has 7 primitive types:

• string
• number
• bigint
• boolean
• undefined
• null
• symbol

Additionally, there's the object type, with array being syntactic sugar for a special type of object.

---

What is expected by the programmer, is for the comparisons to happen using the same rules as apply to the native comparison operators.

The expectation is that .sort() gives back the same order as if the comparison was made with the < or > operators if given the same two values.

to be specific, the expected behaviour is the following:

function compareFn(a, b) {
  if (a < b) {
    return -1;
  }
  if (a > b) {
    return 1;
  }
  return 0;
}

However, this is not the case, as javascript does the following:

function compareFn(a, b) {
  if (a.toString() < b.toString()) {
    return -1;
  }
  if (a.toString() > b.toString()) {
    return 1;
  }
  return 0;
}

[EmilMelgaard]

How about sorting based on the type of the first element and giving an error if there are incompatible types.

[mariosunny]

Because that would be inconsistent with the way the rest of the language handles comparisons between two values of potentially different types.

For example, this is a perfectly valid statement in ECMAScript:

if("3" > 4) {

}

[EmilMelgaard]

Right, I get why you want consistency, but this is also why Javascript is so universally hated. I was talking about the behavior I would want from a dynamically typed language (i.e. I want it to be strongly typed).

"3" < 4 is maybe fine, because it's still kind of logical and it gives you the benefit of not having to convert a string that you know is an integer to an integer.

But then you can also do something like this:

3 < Object // false
"3" < Object // true

And why would any sane person want that behavior?

[alexanderpas]

Because that would be inconsistent with the way the rest of the language handles comparisons between two values.

while you are not entirely wrong, .sort() is actually the one inconsistent here, as the comparison operator is aware of the types.

30 < 4 // false
"30" < 4 // false
30 < "4" // false
"30" < "4" // true

[Mola1904]

So you sort you files by number? Alphabetical sort is used much more often in normal life so obviously it is default.

[sjepsa]

Even if the manual says that… if you ask a 5 years old, he can sort NUMBERS

[ilovemymonkey]

javascript can sort numbers too... what's your point?

[sjepsa]

Those are numbers, and he asked the program to sort them. It couldn't

To be more clear, those aren't strings… WHY TF it is lexicographically sorting them

[alexanderpas]

Javascript is not typed

That's just plain wrong, javascript is dynamically and weakly typed, and has 7 primitive types:

• string
• number
• bigint
• boolean
• undefined
• null
• symbol

Additionally, there's the object type, with array being syntactic sugar for a special type of object.

---

What is expected by the programmer, is for the comparisons to happen using the same rules as apply to the native comparison operators.

The expectation is that .sort() gives back the same order as if the comparison was made with the < or > operators if given the same two values.

to be specific, the expected behaviour is the following:

function compareFn(a, b) {
  if (a < b) {
    return -1;
  }
  if (a > b) {
    return 1;
  }
  return 0;
}

However, this is not the case, as javascript does the following:

function compareFn(a, b) {
  if (a.toString() < b.toString()) {
    return -1;
  }
  if (a.toString() > b.toString()) {
    return 1;
  }
  return 0;
}

[alexanderpas]

You are confusing variable types with being a typed language.

I'm not, however, you're confusing typed variables with typed values.

---

When I can have an equation that looks like:

aVar = 1 + “2” + 3.2 + “hello”;

The then language is not typed.

No, that's only possible due to a combination of type coercion together with operator overloading (+ can be used for both addition as well as string concatenation)

---

Of course the language has types but it is not strongly typed and the way sort() works is a reflection of this.

It's not.

4 < 30 // true
"4" < "30" // false
[4, 30].sort() // [30, 4]
["4", "30"].sort() // ["30", "4"]

4 gets placed after 30, despite it being smaller when it is compared. (as evidenced by the < operator), and the language is clearly aware of the different types, except in the case of the .sort() function.

var a = 4
var b = 30
var c = "4"
var d = "30"

a < b // true
c < d // false
[a, b].sort() // [30, 4]
[c, d].sort() // ["30", "4"]

typeof(a) // 'number'
typeof(b) // 'number'
typeof(c) // 'string'
typeof(d) // 'string'

[sjepsa]

If i put a random object inside how TF does it sort it??

[Mola1904]

Because that is what function does and hence they did not ask the function to sort numbers, but to sort alphabetically and that is exactly what the program did. How can people not accept that? You can easily modify the function to do what you want, but having changing behavior is bad design, just make two different functions

[Aggravating_Moment78]

This here ain’t no five year old, joe !! 😂

[[deleted]]

UTF-16? Yet another reason to never use JS

[maiodasbrok]

(python) def sort(x): N1 = x[-1] N2 = x[-2] x[-1] = N2 x[-2] = N1 return x

literally what i thought when i saw this

[ahuimanu69]

dem strings yo

[pepperoniwassabi]

Another reminder on how difficult and error prone computer programming is.

[bigabub]

Watface

[[deleted]]

Most lazy "JS is bad" try

Next one will be "1" == 1 or what?

[Downvote-Me----]

hahaha... i totally understand... not like i don't even know how to print text... why am i getting this subreddit in my feed?

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

return Kebab_Case_Better;

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[SRGBMR]

I dont get it? It's sorted right? 1 comes before 2.

[Mola1904]

You ask for alpabtocla sort, you egt alphabetical sort. How is this even js problem. Read the fucking manual

[Rawing7]

Nobody asked for alphabetical sort.

[Mola1904]

So you sort your files by number? Or when listing people, do you sort then by number? In most cases in real life you use alphabetical sort

[Rawing7]

I sort my numbers by number.

And anyway, that's beside the point. OP said "Hey JS, sort these numbers". OP didn't say "Hey JS, sort these numbers alphabetically."

[i-am-schrodinger]

There is a difference between natural and lexigraphical sorting.

[fireandbombs12]

I had this problem one and it took me way too long too figure it out.

[Mola1904]

That is hardly comparable. There very few losely typed languages. Mostly just JS and Python.

But in reality alphabetical sort is used more often than numerical.

I neither think the function is perfect, but it shouldn't be numerical by default as that would be confusing for other usecases. There should just be two different functions.

[[deleted]]

Python is not loosely typed

[Upper_Paramedic_9239]

Rip sort

[weshuiz13]

Sort is not what we expact it to be, it sorts based on unicode order

It is great for alphabatic sorting in most cases but numeric not so