5 ms·

> Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type chec

> Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong. This seems like it's split between compiled and interpreted languages, no? Typescript and Python (I believe) will let you override types in their type system, I assume because doing so has no effect on the underlying code. I'm assuming that compiled languages with integrated type-checkers actually use the type checker for allocations so changing types has runtime implications. E.g. Typescript doesn't care if you use `as` to force the type of a variable because it has no impact on the runtime. Javascript will create objects and allocate memory the same regardless of what Typescript thinks the type is. That's not true of something like Go, where changing the type of a variable would require different allocations and changing a struct to a string would break low-level features like GC.

duped 4y ago
It's not interpreted vs dynamic, it's static vs dynamic typing. Python and Typescript are dynamically typed languages with optional AOT type checking, meaning it is valid to write code that would fail typechecking or is impossible to typecheck at parse-time (in other words, types are only guaranteed to be checked when the code is executed, but types are always checked!). There's also a sliding scale of "weak" to "strong" typing (I don't want to attempt to define it). C is the canonical example of a "weakly" typed languages, but imo C++ fits that as well - unless you follow the idioms of "type safe" programming, which makes it difficult for a programmer to write code that is not type checked. The difference between a weak-but-statically typed language and dynamically typed language is that it's possible for a programmer to write code that is never type checked, leading to potentially undefined behavior. C++ needs a notion of "type safe" programming because it is possible for a programmer to write such code. Contrast to a language like Rust or Haskell, where it's close to impossible to write type-unsafe code (without explicitly saying you want to). My point is that implying "safe" programming also implies type safety misunderstands that such safety is close to meaningless in safe programming languages. It's just so much harder to write type-unsafe code it's kind of pointless to bring it up, unless you're writing C and C++.
WorldMaker 4y ago
Many compiled languages with strict type checking still have various sorts of "unsafe" type coercions for when you think you know better than the compiler (things like structs that have the same layout but are still nominally different types). In many of those languages the goal is that you need to opt in to the unsafe type coercion sometimes literally with a language keyword even named something like "unsafe" and know that you are doing something dangerous up front, in direct contrast to a language like C/C++ asking you to opt in to type safety and not doing anything about it up front unless you ask.

duped 4y ago

It's not interpreted vs dynamic, it's static vs dynamic typing. Python and Typescript are dynamically typed languages with optional AOT type checking, meaning it is valid to write code that would fail typechecking or is impossible to typecheck at parse-time (in other words, types are only guaranteed to be checked when the code is executed, but types are always checked!). There's also a sliding scale of "weak" to "strong" typing (I don't want to attempt to define it). C is the canonical example of a "weakly" typed languages, but imo C++ fits that as well - unless you follow the idioms of "type safe" programming, which makes it difficult for a programmer to write code that is not type checked. The difference between a weak-but-statically typed language and dynamically typed language is that it's possible for a programmer to write code that is never type checked, leading to potentially undefined behavior. C++ needs a notion of "type safe" programming because it is possible for a programmer to write such code. Contrast to a language like Rust or Haskell, where it's close to impossible to write type-unsafe code (without explicitly saying you want to). My point is that implying "safe" programming also implies type safety misunderstands that such safety is close to meaningless in safe programming languages. It's just so much harder to write type-unsafe code it's kind of pointless to bring it up, unless you're writing C and C++.

WorldMaker 4y ago

Many compiled languages with strict type checking still have various sorts of "unsafe" type coercions for when you think you know better than the compiler (things like structs that have the same layout but are still nominally different types). In many of those languages the goal is that you need to opt in to the unsafe type coercion sometimes literally with a language keyword even named something like "unsafe" and know that you are doing something dangerous up front, in direct contrast to a language like C/C++ asking you to opt in to type safety and not doing anything about it up front unless you ask.