Hacker News Reader

Comment by scriptkiddy | Hacker News Reader

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

View on HN

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

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

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

It seems python itself also confuses these topics then. https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

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?

There isn't too much confusion, but people bend over backwards to avoid having their type system called "Weak."

Reply on news.ycombinator.com