11 ms·

I don't think so. I think you're referring to static type checking. I'm referring to dynamic/runtime type checking. For instance, `1 + "hello"` will throw a `T

I don't think so. I think you're referring to static type checking. I'm referring to dynamic/runtime type checking. For instance, `1 + "hello"` will throw a `TypeError` at runtime because the `+` operator is not supported for use with `str` and `int` types. In a statically typed language, the code would not run or compile unless a `+` operator has been defined that takes a `str` type as it's first argument and an `int` type as it's second argument. I guess you could say that a `TypeError` at runtime isn't really "type checking" in a sense. I guess it would be more like "type enforcement".

KirinDave 9y ago
> I don't think so. I think you're referring to static type checking. I'm referring to dynamic/runtime type checking. No, you're referring to type-related errors at runtime. That's not checking. Nothing is checked. Code breaks and may recover, but it has no idea what the types of the arguments to the offending expression were, only that it didn't work with that bit of code. This is not type checking. > I guess you could say that a `TypeError` at runtime isn't really "type checking" in a sense. I guess it would be more like "type enforcement". All it does is say, "This code cannot execute with this implicit prior state." It has nothing to do with types except in the most tangential way.
- bendbro 9y ago
  1 + 'hello' resulting in a seg fault would be a "type related error" 1 + 'hello' resulting in an Exception would be a product of dynamic type checking. A language would not be able to explicitly throw a type related error unless it had some information regarding the type of the data. Most resources show little confusion on this, I think you are wrong. https://stackoverflow.com/questions/1347691/static-vs-dynamic-type-checking-in-c https://stackoverflow.com/questions/1347691/static-vs-dynami...
  - KirinDave 9y ago
    > 1 + 'hello' resulting in an Exception would be a product of dynamic type checking. Incorrect. It might be the product of a run time type check. It is not inherently so. You ca't even be sure you actually had a type error when you get a TypeError. But even then, this is using "type check" in the most vacuous and equivocal way possible. It's not the concept most people are referring to. > A language would not be able to explicitly throw a type related error unless it had some information regarding the type of the data. You (and this resource to some extent) are confusing strong vs weak typing with static vs dynamic typing. A + method might have a type check embedded (esp python since + is magical), but it's actually quite rare of that a.foo(b) is anything other than an assertion that the object A's vtable-analogue has an entry. This is sort of dynamic typing, in the sense that I can think of formalisms that model this (named extensible row types come to mind), but this is a profoundly useless defintion of "type." I'm not sure why we'd tolerate redefining type checking to a worthless concept and then using that divergent definition to imply that it's unhelpful. It's 2017, functional languages are fully baked. Powerful static type systems exist even for the Javascript environment and they are taking over that ecosystem rapidly.
    - bendbro 9y ago
      It seems python itself also confuses these topics then. https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...
    - blain_the_train 9y ago
      I find it amusing that the first look Google gives me on strong vs weak typing says there like static vs dynamic typing. Then wiki says there is no strong definition for either term. Maybe it would be easier to drop those terms and go one level deeper?
      - KirinDave 9y ago
        There isn't too much confusion, but people bend over backwards to avoid having their type system called "Weak."

KirinDave 9y ago

> I don't think so. I think you're referring to static type checking. I'm referring to dynamic/runtime type checking. No, you're referring to type-related errors at runtime. That's not checking. Nothing is checked. Code breaks and may recover, but it has no idea what the types of the arguments to the offending expression were, only that it didn't work with that bit of code. This is not type checking. > I guess you could say that a `TypeError` at runtime isn't really "type checking" in a sense. I guess it would be more like "type enforcement". All it does is say, "This code cannot execute with this implicit prior state." It has nothing to do with types except in the most tangential way.

bendbro 9y ago
1 + 'hello' resulting in a seg fault would be a "type related error" 1 + 'hello' resulting in an Exception would be a product of dynamic type checking. A language would not be able to explicitly throw a type related error unless it had some information regarding the type of the data. Most resources show little confusion on this, I think you are wrong. https://stackoverflow.com/questions/1347691/static-vs-dynamic-type-checking-in-c https://stackoverflow.com/questions/1347691/static-vs-dynami...
- KirinDave 9y ago
  > 1 + 'hello' resulting in an Exception would be a product of dynamic type checking. Incorrect. It might be the product of a run time type check. It is not inherently so. You ca't even be sure you actually had a type error when you get a TypeError. But even then, this is using "type check" in the most vacuous and equivocal way possible. It's not the concept most people are referring to. > A language would not be able to explicitly throw a type related error unless it had some information regarding the type of the data. You (and this resource to some extent) are confusing strong vs weak typing with static vs dynamic typing. A + method might have a type check embedded (esp python since + is magical), but it's actually quite rare of that a.foo(b) is anything other than an assertion that the object A's vtable-analogue has an entry. This is sort of dynamic typing, in the sense that I can think of formalisms that model this (named extensible row types come to mind), but this is a profoundly useless defintion of "type." I'm not sure why we'd tolerate redefining type checking to a worthless concept and then using that divergent definition to imply that it's unhelpful. It's 2017, functional languages are fully baked. Powerful static type systems exist even for the Javascript environment and they are taking over that ecosystem rapidly.
  - bendbro 9y ago
    It seems python itself also confuses these topics then. https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...
  - blain_the_train 9y ago
    I find it amusing that the first look Google gives me on strong vs weak typing says there like static vs dynamic typing. Then wiki says there is no strong definition for either term. Maybe it would be easier to drop those terms and go one level deeper?
    - KirinDave 9y ago
      There isn't too much confusion, but people bend over backwards to avoid having their type system called "Weak."