5 ms·

Somewhere on the Internet - I think on the c2.com wiki - there is a discussion on type systems that organizes them on two axes, static vs dynamic and strong vs

by krylon 10y ago

Somewhere on the Internet - I think on the c2.com wiki - there is a discussion on type systems that organizes them on two axes, static vs dynamic and strong vs weak. Static vs dynamic refers to how much the compiler/interpreter knows about the types being used before execution. Strong vs weak refers to how easy or difficult it is to subvert the type system, e.g. by casting pointers or using unions. That discussion was an eye-opener for me regarding type systems; to this day, I cringe when somebody calls, e.g. Python or Javascript a "typeless" languange.

paddyoloughlin 10y ago
Strong vs weak is essentially meaningless. There is no generally agreed upon definition of what the distinction means.
- kbenson 10y ago
  Just because there is some controversy over it doesn't mean it's meaningless. In this case it just means that it's not as descriptive as we would hope, and it's better used to describe as aspect of a language, as they are often strongly typed in some aspects and weakly typed in others.
  - jstimpfle 10y ago
    Bravo! So much hair-splitting and (deliberate?) misinterpretation of context on the internet. We need more counters done your way to keep discussions focused: Factual and to the point.
  - paddyoloughlin 10y ago
    First, my post said 'essentially meaningless', which is to say 'possibly not completely, but for the most part, meaningless'. Second, the context here is whether or not the type system of a language is strong or it is weak. I stand by my assertion that describing type systems as strong or weak typing is essentially meaningless. It's so far from descriptive that all 'strongly typed' ever really means is 'I like this feature' and 'weakly typed' means 'I do not like this feature'. There are alternative, accurate ways of talking about what people think they are trying to get at when they use the terms strong and weak in relation to languages. They should be used instead.
kbenson 10y ago
This is a well known distinction, talked about in many places[1]. Python would be dynamic and strongly typed, Perl would be dynamic and weakly typed, at least WRT numerical and string types, which is why it uses different operators to distinguish between those types of operations (compared to Python's use of + for for numerical addition and string concatenation. Perl could also be said to be strongly typed WRT scalars and arrays, so it depends on your point of view. There is some controversy over the strong/weak terminology, IMO mostly because almost no language is clearly strong or weak based on the definitions generally used[2]. I find it useful to think about whether things are done implicity, or whether you need to specifically convert types. Perl will happily add "1" and "1" to get 2, because the + operator forces it to be interpreted as a numeric type. Python will not, and expects you to convert to a numeric type first. Of course, exceptions to the rule abound. 1: http://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak http://stackoverflow.com/questions/2351190/static-dynamic-vs... 2: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
- catnaroek 10y ago
  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).

by krylon 10y ago

paddyoloughlin 10y ago

Strong vs weak is essentially meaningless. There is no generally agreed upon definition of what the distinction means.

kbenson 10y ago
Just because there is some controversy over it doesn't mean it's meaningless. In this case it just means that it's not as descriptive as we would hope, and it's better used to describe as aspect of a language, as they are often strongly typed in some aspects and weakly typed in others.
- jstimpfle 10y ago
  Bravo! So much hair-splitting and (deliberate?) misinterpretation of context on the internet. We need more counters done your way to keep discussions focused: Factual and to the point.
- paddyoloughlin 10y ago
  First, my post said 'essentially meaningless', which is to say 'possibly not completely, but for the most part, meaningless'. Second, the context here is whether or not the type system of a language is strong or it is weak. I stand by my assertion that describing type systems as strong or weak typing is essentially meaningless. It's so far from descriptive that all 'strongly typed' ever really means is 'I like this feature' and 'weakly typed' means 'I do not like this feature'. There are alternative, accurate ways of talking about what people think they are trying to get at when they use the terms strong and weak in relation to languages. They should be used instead.

kbenson 10y ago

This is a well known distinction, talked about in many places[1]. Python would be dynamic and strongly typed, Perl would be dynamic and weakly typed, at least WRT numerical and string types, which is why it uses different operators to distinguish between those types of operations (compared to Python's use of + for for numerical addition and string concatenation. Perl could also be said to be strongly typed WRT scalars and arrays, so it depends on your point of view. There is some controversy over the strong/weak terminology, IMO mostly because almost no language is clearly strong or weak based on the definitions generally used[2]. I find it useful to think about whether things are done implicity, or whether you need to specifically convert types. Perl will happily add "1" and "1" to get 2, because the + operator forces it to be interpreted as a numeric type. Python will not, and expects you to convert to a numeric type first. Of course, exceptions to the rule abound. 1: http://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak http://stackoverflow.com/questions/2351190/static-dynamic-vs... 2: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing

catnaroek 10y ago
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).