3 ms·

> In fact, C and C++ are both strongly typed, but they are both memory unsafe. You are refuting my point but provide no evidence and implicitly redefine severa

by lvh 8y ago

> In fact, C and C++ are both strongly typed, but they are both memory unsafe. You are refuting my point but provide no evidence and implicitly redefine several terms in a way contrary to common usage. Is there a definition you can pen down? Because C sure isn't strongly typed in the Liskov, Jackson or modern usage senses of the term. > Also, tools like valgrind get you 99% of the benefit of memory safety, which is good enough for debugging. C++ lets you override the allocator, and build in inexpensive (fast enough for production) checks for most use after frees, memory consumption profilers / leak detection/ etc. Would you say that de facto C/C++ has a memory safety problem? If it does, why? (Also, not germane to my point.) > I’d argue that python is memory unsafe in practice, since we get segfaults from third party dependencies in python about as often as we see them in c/c++. Do you have extraordinary evidence to go with this extraordinary claim, or are you just talking about your own anecdata? (Also, not germane to my point.) > If you use std::string, adding a in integer does something well-defined (rtfm). My argument was not that it is poorly defined. Weak typing doesn't mean UB.

hedora 8y ago
https://en.m.wikipedia.org/wiki/Strong_and_weak_typing https://en.m.wikipedia.org/wiki/Strong_and_weak_typing Strong and weak typing are poorly defined terms. I’d argue that type errors (not including memory safety errors) should not occur at runtime in a strongly typed language, or at least that a “stronger typed” language would admit fewer classes of those errors in practice. I’d argue that de facto, modern C/C++ does not have a memory safety issue. Operating systems like OpenBSD and many other secure, hardened network daemons provide existence proofs that are not available for languages like python. In contrast, I’d argue that python has severe type safety issues. I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. I also don’t understand why you dislike the string examples, which explains the (strongly typed) semantics of the operators you mentioned in your comment. By “strongly typed” do you mean that all operators return the (single type) of their parameters? I don’t know of any languages that enforce such a thing. Perhaps you mean “strongly typed languages only include operators that are to my taste”? That’s surely not a useful definition.
- lvh 8y ago
  OK, Wikipedia it is. Wikipedia lists C’s typing discipline as “Static, weak, manifest, nominal“, and Python’s as “ Duck, dynamic, strong since version 3.5: Gradual[4]”. > I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. > I also don’t understand why you dislike the string examples, which explains the (strongly typed) semantics of the operators you mentioned in your comment. I have no idea what evidence you’re referring to, or what examples I supposedly dislike.
  - hedora 8y ago
    There are examples of string operators two comments up. Those are the examples I’m referring to. To any readers that made it this far, and are hoping for something precise, here is a minimally useful definition of “strongly typed”. I’ve never heard of a broader definition of “strongly typed”: The language’s type system must be embedable in a lattice, and at runtime, it is guaranteed that functions aren’t passing the top element around and then using it without an explicit downcast. C/C++ meet this definition, since you need to cast void* before dereferncing it, and void isn’t a valid type for a variable. Also, the only union types are defined at compile time. Python does not meet this definition because functions can have multiple return types due to control flow, which means you can create call sites that return things like lub(integer, string), and then compose them until you have something of type “top”, and there’s no way to statically guard against usages of such a type.
    - joshuamorton 8y ago
      This isn't a very good definition. C++ doesn't have runtime types other than void* (python does, on the other hand) (java is the same way). In C++, the only thing passed around at runtime is void* . The pointer is then used as a concrete type without any explicit downcast. Any conversation about strong typing should not involve the word "static". Nothing about strong typing is "static". It is entirely a runtime concept. Functions potentially having multiple return types is entirely an issue of static typing. Not strong typing. This is obvious because you can annootate python code with the type information. This makes it strongly typed, but not statically typed, even though it makes all unions compile time defined. In other words, if I take python with type annotations (which is statically typed), and remove the annotations, you claim this would make the language weakly typed, but this makes no sense. There would be no difference between strength and dynamicness. A better definition might be that a language is weakly typed of it allows transformation from type a to b, where a and b are unrelated (ie neither inherits from the other), without a call to a constructor. Python does not meet this definition, the only way to cast is via a constructor call. C and c++ do not, void* allows arbitrary transforms. Java will throw a classcastexception, but can only do so at runtime, bit will do so at the bad cast. C and c++ will keep chugging until the miscast object is misused. That's weak typing.

by lvh 8y ago

hedora 8y ago

https://en.m.wikipedia.org/wiki/Strong_and_weak_typing https://en.m.wikipedia.org/wiki/Strong_and_weak_typing Strong and weak typing are poorly defined terms. I’d argue that type errors (not including memory safety errors) should not occur at runtime in a strongly typed language, or at least that a “stronger typed” language would admit fewer classes of those errors in practice. I’d argue that de facto, modern C/C++ does not have a memory safety issue. Operating systems like OpenBSD and many other secure, hardened network daemons provide existence proofs that are not available for languages like python. In contrast, I’d argue that python has severe type safety issues. I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. I also don’t understand why you dislike the string examples, which explains the (strongly typed) semantics of the operators you mentioned in your comment. By “strongly typed” do you mean that all operators return the (single type) of their parameters? I don’t know of any languages that enforce such a thing. Perhaps you mean “strongly typed languages only include operators that are to my taste”? That’s surely not a useful definition.

lvh 8y ago
OK, Wikipedia it is. Wikipedia lists C’s typing discipline as “Static, weak, manifest, nominal“, and Python’s as “ Duck, dynamic, strong since version 3.5: Gradual[4]”. > I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. > I also don’t understand why you dislike the string examples, which explains the (strongly typed) semantics of the operators you mentioned in your comment. I have no idea what evidence you’re referring to, or what examples I supposedly dislike.
- hedora 8y ago
  There are examples of string operators two comments up. Those are the examples I’m referring to. To any readers that made it this far, and are hoping for something precise, here is a minimally useful definition of “strongly typed”. I’ve never heard of a broader definition of “strongly typed”: The language’s type system must be embedable in a lattice, and at runtime, it is guaranteed that functions aren’t passing the top element around and then using it without an explicit downcast. C/C++ meet this definition, since you need to cast void* before dereferncing it, and void isn’t a valid type for a variable. Also, the only union types are defined at compile time. Python does not meet this definition because functions can have multiple return types due to control flow, which means you can create call sites that return things like lub(integer, string), and then compose them until you have something of type “top”, and there’s no way to statically guard against usages of such a type.
  - joshuamorton 8y ago
    This isn't a very good definition. C++ doesn't have runtime types other than void* (python does, on the other hand) (java is the same way). In C++, the only thing passed around at runtime is void* . The pointer is then used as a concrete type without any explicit downcast. Any conversation about strong typing should not involve the word "static". Nothing about strong typing is "static". It is entirely a runtime concept. Functions potentially having multiple return types is entirely an issue of static typing. Not strong typing. This is obvious because you can annootate python code with the type information. This makes it strongly typed, but not statically typed, even though it makes all unions compile time defined. In other words, if I take python with type annotations (which is statically typed), and remove the annotations, you claim this would make the language weakly typed, but this makes no sense. There would be no difference between strength and dynamicness. A better definition might be that a language is weakly typed of it allows transformation from type a to b, where a and b are unrelated (ie neither inherits from the other), without a call to a constructor. Python does not meet this definition, the only way to cast is via a constructor call. C and c++ do not, void* allows arbitrary transforms. Java will throw a classcastexception, but can only do so at runtime, bit will do so at the bad cast. C and c++ will keep chugging until the miscast object is misused. That's weak typing.