6 ms·

Okay, so you're saying that: (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. (1) An

Okay, so you're saying that: (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions.

kbenson 10y ago
> (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. If it were true that everything is a string, then yes, you probably could say it's strongly typed. It's laughable, but it is. Some single celled organisms are animals, as well. Assembly is generally the strongest typed language you can get. But it's not true. Bash supports associative arrays. #!/bin/bash declare -A array_var array_var=( ["foo"]="11" ["bar"]="22" ); echo "$array_var"; # Empty line echo "${array_var[foo]}"; # 11 scalar_var="baz"; echo $scalar_var; # bar array_var="quux"; echo "$array_var"; # quux echo "${array_var[foo]}"; # 11 That said, I'm not sure if you can actually access the array container itself (I don't use bash for actual programming), so I'm not sure how it handles comparisons and operations between the types, if it's even possible. It may be Bash is strongly typed (I'm not sure), but we can't make that determination by assuming it has a single data type. Also, even if it was a single data type, there are interstitial types that exist for doing numeric operations, and I'm not sure how to consider those with respect to this concept. > (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. > > (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. You're making very strong assertions based on my comment when I made sure to to say "almost no language is clearly strong or weak based on the definitions generally used", and even provided examples where the same language could be considered both strongly and weakly typed, depending on what aspect you were referring to. "Strong" and "weak" are themselves relative terms, so make no sense unless comparing to something else. That may be a shared reference language, or the perceived common level of languages with respect to what is being discussed. I replied to the sibling of my original comment with some info about how I think about this. It's rarely useful to think of a language as entirely strongly or weakly typed, but certain aspects of it may or may not be (again, relative to some benchmark). > There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions. Well, treating the same datum as a number and a string in different places is exacerbated by implicit conversions, which allow that behavior to succeed. I wouldn't say it's independent, I would say one depends on the other. Really, whether they are well defined terms or not, I think it's still still useful to use them with some disambiguating context, as they express a concept otherwise hard to convey (if it was easy to convey, they wouldn't be so ambiguous in the first place).
- catnaroek 10y ago
  Nah, what's actually useful is to determine how much of your program specification can be enforced with a given type system. That's well defined, and even relatively easy to assess before you pick this or that language for a given project.
  - kbenson 10y ago
    I agree that is useful, but it's far from the only useful thing, and I don't think it's entirely distinct from the point at hand. When dealing with subtopics, covariance and contravariance can be seen as a weakening of the type system to make certain things easier. I think a case could be made that any subversion of requiring the exact type defined or requiring manual conversion is a weakening of the type system, for the definition of weakening that we are using. The important consideration is that neither stronger nor weaker are always necessarily better or worse.
    - catnaroek 10y ago
      > far from the only useful thing I didn't say it's the only useful thing, but it's perfectly reasonable to measure the expressive power of a type system (or any other language feature, really) by how much it buys you. > can be seen as a weakening Covariance and contravariance support by no means "weaken" a type system - they allow you to express more statically, not less.
      - kbenson 10y ago
        Well, is expression how we are measuring how "strong" a type system is? It's definitely one way to measure it, but I would rather describe those in terms of safety and versatility. If by "strong" in a type system we mean explicitly following what was spcifically defined, then allowing anything except the specified type can be viewed as a weakening of the type system, regardless of whether it's provably safe or allows more expressiveness. That is, I think strong and weak or orthogonal to to safety and expressiveness (even if usually stronger is safer. as with most things, anything taken to an extreme starts to lose it's useful attributes). I.e. stronger is not necessarily equivalent to better.
steveklabnik 10y ago
> Rust is even more weakly typed Both of your examples here happen in much more limited circumstances than you seem to imply.
- catnaroek 10y ago
  Sorry, don't get me wrong, my point was just to illustrate the silliness of kbenson's definition using reductio ad absurdum. Haskell and Rust aren't weakly typed in any conceivable universe.
  - steveklabnik 10y ago
    Ah! My bad. Poe's tough sometimes...

kbenson 10y ago

> (0) Bash is strongly typed. Everything is a string, so there can't possibly be any type conversions, implicit or explicit. If it were true that everything is a string, then yes, you probably could say it's strongly typed. It's laughable, but it is. Some single celled organisms are animals, as well. Assembly is generally the strongest typed language you can get. But it's not true. Bash supports associative arrays. #!/bin/bash declare -A array_var array_var=( ["foo"]="11" ["bar"]="22" ); echo "$array_var"; # Empty line echo "${array_var[foo]}"; # 11 scalar_var="baz"; echo $scalar_var; # bar array_var="quux"; echo "$array_var"; # quux echo "${array_var[foo]}"; # 11 That said, I'm not sure if you can actually access the array container itself (I don't use bash for actual programming), so I'm not sure how it handles comparisons and operations between the types, if it's even possible. It may be Bash is strongly typed (I'm not sure), but we can't make that determination by assuming it has a single data type. Also, even if it was a single data type, there are interstitial types that exist for doing numeric operations, and I'm not sure how to consider those with respect to this concept. > (1) Any language with subtypes is weakly typed. For example, Haskell with Rank2Types or above: every lens is a traversal in a canonical way, and indeed the type checker lets you supply a lens in a context where a traversal is expected. > > (2) Rust is even more weakly typed: boxes (as well as other user-defined pointer types) are implicitly converted to references, iterable objects are implicitly converted to iterators, etc. You're making very strong assertions based on my comment when I made sure to to say "almost no language is clearly strong or weak based on the definitions generally used", and even provided examples where the same language could be considered both strongly and weakly typed, depending on what aspect you were referring to. "Strong" and "weak" are themselves relative terms, so make no sense unless comparing to something else. That may be a shared reference language, or the perceived common level of languages with respect to what is being discussed. I replied to the sibling of my original comment with some info about how I think about this. It's rarely useful to think of a language as entirely strongly or weakly typed, but certain aspects of it may or may not be (again, relative to some benchmark). > There's no precise technical definition of "strongly typed", but AFAICT, the intuitive idea is that a "strongly typed" language prevents you, or at least makes it difficult to do things that aren't likely to make sense, like treating the same datum as a number and as a string in different places. This is independent of whether the language has implicit conversions. Well, treating the same datum as a number and a string in different places is exacerbated by implicit conversions, which allow that behavior to succeed. I wouldn't say it's independent, I would say one depends on the other. Really, whether they are well defined terms or not, I think it's still still useful to use them with some disambiguating context, as they express a concept otherwise hard to convey (if it was easy to convey, they wouldn't be so ambiguous in the first place).

catnaroek 10y ago
Nah, what's actually useful is to determine how much of your program specification can be enforced with a given type system. That's well defined, and even relatively easy to assess before you pick this or that language for a given project.
- kbenson 10y ago
  I agree that is useful, but it's far from the only useful thing, and I don't think it's entirely distinct from the point at hand. When dealing with subtopics, covariance and contravariance can be seen as a weakening of the type system to make certain things easier. I think a case could be made that any subversion of requiring the exact type defined or requiring manual conversion is a weakening of the type system, for the definition of weakening that we are using. The important consideration is that neither stronger nor weaker are always necessarily better or worse.
  - catnaroek 10y ago
    > far from the only useful thing I didn't say it's the only useful thing, but it's perfectly reasonable to measure the expressive power of a type system (or any other language feature, really) by how much it buys you. > can be seen as a weakening Covariance and contravariance support by no means "weaken" a type system - they allow you to express more statically, not less.
    - kbenson 10y ago
      Well, is expression how we are measuring how "strong" a type system is? It's definitely one way to measure it, but I would rather describe those in terms of safety and versatility. If by "strong" in a type system we mean explicitly following what was spcifically defined, then allowing anything except the specified type can be viewed as a weakening of the type system, regardless of whether it's provably safe or allows more expressiveness. That is, I think strong and weak or orthogonal to to safety and expressiveness (even if usually stronger is safer. as with most things, anything taken to an extreme starts to lose it's useful attributes). I.e. stronger is not necessarily equivalent to better.

steveklabnik 10y ago

> Rust is even more weakly typed Both of your examples here happen in much more limited circumstances than you seem to imply.

catnaroek 10y ago
Sorry, don't get me wrong, my point was just to illustrate the silliness of kbenson's definition using reductio ad absurdum. Haskell and Rust aren't weakly typed in any conceivable universe.
- steveklabnik 10y ago
  Ah! My bad. Poe's tough sometimes...