Coz there's a difference between "dynamic type system" and "type system that's thrown together with bits of string and rubber bands":

https://www.destroyallsoftware.com/talks/wat

Python has is own 'wat' stuff, especially Python 2.

https://stackoverflow.com/questions/3270680/how-does-python-...

"CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address."

> objects of different types always compare unequal, and are ordered consistently but arbitrarily

Seems like a completely reasonable thing to do?

> When you order two incompatible types where neither is numeric, they are ordered by the alphabetical order of their typenames:

????????

That's entirely an implementation detail. The thing that matters for programmer experience is the specification of behavior: There's going to be an arbitrary order. You certainly can argue that you think it would be less surprising if trying this just failed, or that promising a stable order ties down implementations too much, but I don't think providing an order is that surprising.

None (as far as I remember) of the common "wat" examples about JS are interpreter implementation details, but specified behavior.

I'm mildly curious why CPython chooses to implement it this way, but if I had to guess: I'm assuming it is to provide a stable order between objects of different classes with the same hash() value. Hash-value being what I suspect is what the quoted answer misrepresents as "their address" (the address being in CPython the default fallback for objects that do not implement a hash() function), and being a good candidate to establish an arbitrary order.

Sorry, I'm not sure I understand at all the difference between this and the 'wat' stuff.

That's just GIGO. There's simply no good way to order "two incompatible types where neither is numeric".

There's always an option to just treat it as an error, especially given that 1+"2" already is.

None of those surprising behaviors exist in python 3.

I wouldn't say "100" < "2" really counts, since, alphabetically it makes sense (an equivalent would be "baa" < "c").

Yes, Python2 was called out explicitly. Reference equality is definitely 'wat' shit IMO, though it's really mainstream too.

Honestly, with JS flow (https://flow.org) it's very manageable, I almost never have WAT sort of issues

I don't see any reason to use Flow over TS.

Maybe! But I had to implement some tools (chrome extensions) on Javascript with no prior JS experience, so was trying to stick to vanilla side.

Lack of strong typing is low on the very long list of problems with JS