4 ms·

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.destroyallsof

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 https://www.destroyallsoftware.com/talks/wat

staticassertion 7y ago
Python has is own 'wat' stuff, especially Python 2. https://stackoverflow.com/questions/3270680/how-does-python-2-compare-string-and-int-why-do-lists-compare-as-greater-than-n 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."
- pytester 7y ago
  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").
  - staticassertion 7y ago
    Yes, Python2 was called out explicitly. Reference equality is definitely 'wat' shit IMO, though it's really mainstream too.
- detaro 7y ago
  > objects of different types always compare unequal, and are ordered consistently but arbitrarily Seems like a completely reasonable thing to do?
  - staticassertion 7y ago
    > When you order two incompatible types where neither is numeric, they are ordered by the alphabetical order of their typenames: ????????
    - icebraining 7y ago
      That's just GIGO. There's simply no good way to order "two incompatible types where neither is numeric".
      - int_19h 7y ago
        There's always an option to just treat it as an error, especially given that 1+"2" already is.
    - detaro 7y ago
      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.
      - staticassertion 7y ago
        Sorry, I'm not sure I understand at all the difference between this and the 'wat' stuff.
karlicoss 7y ago
Honestly, with JS flow (https://flow.org https://flow.org) it's very manageable, I almost never have WAT sort of issues
- tuesdayrain 7y ago
  I don't see any reason to use Flow over TS.
  - karlicoss 7y ago
    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.

staticassertion 7y ago

Python has is own 'wat' stuff, especially Python 2. https://stackoverflow.com/questions/3270680/how-does-python-2-compare-string-and-int-why-do-lists-compare-as-greater-than-n 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."

pytester 7y ago
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").
- staticassertion 7y ago
  Yes, Python2 was called out explicitly. Reference equality is definitely 'wat' shit IMO, though it's really mainstream too.
detaro 7y ago
> objects of different types always compare unequal, and are ordered consistently but arbitrarily Seems like a completely reasonable thing to do?
- staticassertion 7y ago
  > When you order two incompatible types where neither is numeric, they are ordered by the alphabetical order of their typenames: ????????
  - icebraining 7y ago
    That's just GIGO. There's simply no good way to order "two incompatible types where neither is numeric".
    - int_19h 7y ago
      There's always an option to just treat it as an error, especially given that 1+"2" already is.
  - detaro 7y ago
    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.
    - staticassertion 7y ago
      Sorry, I'm not sure I understand at all the difference between this and the 'wat' stuff.

karlicoss 7y ago

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

tuesdayrain 7y ago
I don't see any reason to use Flow over TS.
- karlicoss 7y ago
  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.