5 ms·

Everyone saying that there's no real definition of strong and weak typing always confuses me. In my view, strong typing prohibits implicit conversion between t

Everyone saying that there's no real definition of strong and weak typing always confuses me. In my view, strong typing prohibits implicit conversion between types, and weak typing allows it. This is, of course, a scale - for instance, Python, generally viewed as a strongly-typed language, allows you to say something like foo = 'lolsomestring' if foo: [code] where a string is implicitly converted to a boolean (as opposed to using bool()). However, an exception is thrown when attempting to add 5 and "5", where a language like PHP will happily provide an integer result.

Xk 16y ago
Java is strongly typed. As a counterexample, here's some valid java: String str = ""+5;
- xiongchiamiov 16y ago
  The point I was attempting to make is that Java (and all other languages that I know of) are both strongly and weakly typed.
- samstokes 16y ago
  I don't think that is a counterexample. "" + 5 is defined by translation to new StringBuilder("").append(5) which statically resolves to the method StringBuilder.append(int), whose implementation explicitly converts 5 to a string. Java does offer a counterexample to "strong typing means no implicit conversion", though: String s = "foo"; Object o = s; I just implicitly converted a String to an Object, which the GP's definition disallows. Of course you can fix up the definition for Java by adding the proviso "except upcasting a derived type to a superclass of that type", but the fact that you have to add a language-specific proviso indicates why there's no accepted common definition. But at least with that proviso our definition works for all object-oriented languages, right? Well, actually it still doesn't even work for Java, because since Java 1.5 you can say: int i = 2; Integer i2 = i; So Java needs an exception for upcasting, and for autoboxing, and we probably should worry about exactly what type we think 'null' has...
blasdel 16y ago
I understand what you're trying to say, that type coercion makes a system 'weak', but your example is terrible. Python's type system uses interfaces, so strings are effectively also of type sequence, which is also of type boolean. Any object can just define __nonzero__() and be a boolean. That's all the bool() builtin does — it just tries to call __nonzero__() or __len__() — http://docs.python.org/library/stdtypes.html#truth-value-testing http://docs.python.org/library/stdtypes.html#truth-value-tes...
jholman 16y ago
> In my view, strong typing [means such-and-such]. In your view, it means this. In someone else's view, it means something else. Unlike "static", "dynamic", "explicit", "implicit", "structural", even "duck", all of which people more-or-less agree about (well, sort of), there's this problem with the definition of the "strong" or "weak" typing. 1) If you use them in conversation without a definition, there's a very high chance that they mean something different to the listener. (Unless of course it's a listener with whom you've already had this conversation.) 2) If you stop to define them, the whole conversation gets derailed to argue about the definitions. That is why people say these words "have nearly no meaning at all". Does that help your confusion? So, if you want to communicate about type systems, your communication will contain less misunderstanding if you simply omit the words "strong" and "weak". And for myself (although this may be too snotty a move for you), if someone else uses them, I refuse to hear them, and ask them to use different words and define those words. My experience, in practice, is that when people say "strong" and "weak", I do indeed find that as cdsmith says, "strong" mostly corresponds to "it makes me comfortable".
- derefr 16y ago
  > My experience, in practice, is that when people say "strong" and "weak", I do indeed find that as cdsmith says, "strong" mostly corresponds to "it makes me comfortable". But even people who are very comfortable in C, do not say that C is strongly-typed. In my experience, people agree on which languages are strongly- or weakly-typed, and that can be used to reverse-engineer the definition, based on the properties those languages differ on. Assembly, C, and PHP are all weakly-typed, at the very least, and their proponents agree with this. They don't agree on why they are weakly-typed, simply that they are. The original definition I ever heard for weak-typing, back when C and Assembler were the only things that had it, was "a weakly-typed language allows you to take the raw, in-memory representation of data of type A, and perform operations on it as if it were data of type B that had an equal raw, in-memory representation." The most famous example of this is Quake's fast invsqrt(), where the bytes making up a float have int operations applied to them, as if they were bytes making up an int. Of course, PHP doesn't have this capability, but we still call it weakly-typed. So the definition must have moved on from its previous strict form. What does PHP allow you to do, that gets it called weakly-typed? This: echo "(" + 5 + ")"; # prints "5"! PHP, here, is taking the Strings "(" and ")" and interpreting them as numbers for the purposes of the addition operator. However, the strings "(" and ")" are not valid numbers—but PHP is fine with this, and uses the default numeric value of 0 to represent this invalidity. The similarity with the original definition, is that the data is transformed from one type to another, not implicitly, and not that the raw representation of the data is used, but rather without a guarantee that the datatypes have the same capacity for informational entropy. In other words, casting "(" to a number silently loses data, just as storing an int in a char variable in C silently loses data. This fact seems to be universal to all languages that get called "weakly-typed", and non-existent in any language that has never had that epithet applied to it. It has nothing to do, notice, with whether a language will implicitly cast values—as long as all implicit conversions happen upward to types that have "room" for all the information in the original representation (char -> int, int -> String, int -> float) the language is still strongly-typed. And notice that the datatype itself being lost in a typecast (String -> Object) cannot be a reason to call a language weakly-typed because, in an interface-like cast like this, all the data is still retained, and its original form can be reclaimed simply by casting it back (Object -> String).
anamax 16y ago
foo = 'lolsomestring' if foo: [code] > where a string is implicitly converted to a boolean (as opposed to using bool()). Umm, no. You're assuming that the condition of "if" is necessarily a boolean. It's not clear that it is. It looks more like "is the value not an element of [None, 0, 0.0, False, {objects of 0 length}]" and a couple of others. (There's a strange exception for certain objects.) The fact that False and True are Python constants of a "boolean type" does not imply that booleans are privileged wrt conditionals.
- xiongchiamiov 16y ago
  You're assuming that the condition of "if" is necessarily a boolean. Indeed. Conditional branching generally needs a boolean value - do we go down this path or not? It's not clear that it is. It looks more like "is the value not an element of [None, 0, 0.0, False, {objects of 0 length}]" and a couple of others. Right, and any of those things, when converted to a boolean are... False. The things that don't convert to True. I don't know how the language itself is constructed, but it would surprise me if the code for bool() and if-statements were logically separated. Can you imagine the havoc that would ensue from, say, bool(None) returning False, but if None: causing the branch to execute?
wlievens 16y ago
To me, strongly typed means something entirely different: a strongly typed language does not allow you to do unsafe conversions. In C for instance, you can cast any integer value to a pointer, creating references to things that may not even exist. That would be weak typing. There's a dozen more definitions, though.
jpr 16y ago
There's no implicit conversion, truthiness in Python is just defined to make sense: http://docs.python.org/library/stdtypes.html#truth-value-testing http://docs.python.org/library/stdtypes.html#truth-value-tes... Contrast this to something like Java where all code is littered with shit like foo != null and foo.length != 0.

Xk 16y ago

Java is strongly typed. As a counterexample, here's some valid java: String str = ""+5;

xiongchiamiov 16y ago
The point I was attempting to make is that Java (and all other languages that I know of) are both strongly and weakly typed.
samstokes 16y ago
I don't think that is a counterexample. "" + 5 is defined by translation to new StringBuilder("").append(5) which statically resolves to the method StringBuilder.append(int), whose implementation explicitly converts 5 to a string. Java does offer a counterexample to "strong typing means no implicit conversion", though: String s = "foo"; Object o = s; I just implicitly converted a String to an Object, which the GP's definition disallows. Of course you can fix up the definition for Java by adding the proviso "except upcasting a derived type to a superclass of that type", but the fact that you have to add a language-specific proviso indicates why there's no accepted common definition. But at least with that proviso our definition works for all object-oriented languages, right? Well, actually it still doesn't even work for Java, because since Java 1.5 you can say: int i = 2; Integer i2 = i; So Java needs an exception for upcasting, and for autoboxing, and we probably should worry about exactly what type we think 'null' has...

blasdel 16y ago

I understand what you're trying to say, that type coercion makes a system 'weak', but your example is terrible. Python's type system uses interfaces, so strings are effectively also of type sequence, which is also of type boolean. Any object can just define __nonzero__() and be a boolean. That's all the bool() builtin does — it just tries to call __nonzero__() or __len__() — http://docs.python.org/library/stdtypes.html#truth-value-testing http://docs.python.org/library/stdtypes.html#truth-value-tes...

jholman 16y ago

> In my view, strong typing [means such-and-such]. In your view, it means this. In someone else's view, it means something else. Unlike "static", "dynamic", "explicit", "implicit", "structural", even "duck", all of which people more-or-less agree about (well, sort of), there's this problem with the definition of the "strong" or "weak" typing. 1) If you use them in conversation without a definition, there's a very high chance that they mean something different to the listener. (Unless of course it's a listener with whom you've already had this conversation.) 2) If you stop to define them, the whole conversation gets derailed to argue about the definitions. That is why people say these words "have nearly no meaning at all". Does that help your confusion? So, if you want to communicate about type systems, your communication will contain less misunderstanding if you simply omit the words "strong" and "weak". And for myself (although this may be too snotty a move for you), if someone else uses them, I refuse to hear them, and ask them to use different words and define those words. My experience, in practice, is that when people say "strong" and "weak", I do indeed find that as cdsmith says, "strong" mostly corresponds to "it makes me comfortable".

derefr 16y ago
> My experience, in practice, is that when people say "strong" and "weak", I do indeed find that as cdsmith says, "strong" mostly corresponds to "it makes me comfortable". But even people who are very comfortable in C, do not say that C is strongly-typed. In my experience, people agree on which languages are strongly- or weakly-typed, and that can be used to reverse-engineer the definition, based on the properties those languages differ on. Assembly, C, and PHP are all weakly-typed, at the very least, and their proponents agree with this. They don't agree on why they are weakly-typed, simply that they are. The original definition I ever heard for weak-typing, back when C and Assembler were the only things that had it, was "a weakly-typed language allows you to take the raw, in-memory representation of data of type A, and perform operations on it as if it were data of type B that had an equal raw, in-memory representation." The most famous example of this is Quake's fast invsqrt(), where the bytes making up a float have int operations applied to them, as if they were bytes making up an int. Of course, PHP doesn't have this capability, but we still call it weakly-typed. So the definition must have moved on from its previous strict form. What does PHP allow you to do, that gets it called weakly-typed? This: echo "(" + 5 + ")"; # prints "5"! PHP, here, is taking the Strings "(" and ")" and interpreting them as numbers for the purposes of the addition operator. However, the strings "(" and ")" are not valid numbers—but PHP is fine with this, and uses the default numeric value of 0 to represent this invalidity. The similarity with the original definition, is that the data is transformed from one type to another, not implicitly, and not that the raw representation of the data is used, but rather without a guarantee that the datatypes have the same capacity for informational entropy. In other words, casting "(" to a number silently loses data, just as storing an int in a char variable in C silently loses data. This fact seems to be universal to all languages that get called "weakly-typed", and non-existent in any language that has never had that epithet applied to it. It has nothing to do, notice, with whether a language will implicitly cast values—as long as all implicit conversions happen upward to types that have "room" for all the information in the original representation (char -> int, int -> String, int -> float) the language is still strongly-typed. And notice that the datatype itself being lost in a typecast (String -> Object) cannot be a reason to call a language weakly-typed because, in an interface-like cast like this, all the data is still retained, and its original form can be reclaimed simply by casting it back (Object -> String).

anamax 16y ago

foo = 'lolsomestring' if foo: [code] > where a string is implicitly converted to a boolean (as opposed to using bool()). Umm, no. You're assuming that the condition of "if" is necessarily a boolean. It's not clear that it is. It looks more like "is the value not an element of [None, 0, 0.0, False, {objects of 0 length}]" and a couple of others. (There's a strange exception for certain objects.) The fact that False and True are Python constants of a "boolean type" does not imply that booleans are privileged wrt conditionals.

xiongchiamiov 16y ago
You're assuming that the condition of "if" is necessarily a boolean. Indeed. Conditional branching generally needs a boolean value - do we go down this path or not? It's not clear that it is. It looks more like "is the value not an element of [None, 0, 0.0, False, {objects of 0 length}]" and a couple of others. Right, and any of those things, when converted to a boolean are... False. The things that don't convert to True. I don't know how the language itself is constructed, but it would surprise me if the code for bool() and if-statements were logically separated. Can you imagine the havoc that would ensue from, say, bool(None) returning False, but if None: causing the branch to execute?

wlievens 16y ago

To me, strongly typed means something entirely different: a strongly typed language does not allow you to do unsafe conversions. In C for instance, you can cast any integer value to a pointer, creating references to things that may not even exist. That would be weak typing. There's a dozen more definitions, though.

jpr 16y ago

There's no implicit conversion, truthiness in Python is just defined to make sense: http://docs.python.org/library/stdtypes.html#truth-value-testing http://docs.python.org/library/stdtypes.html#truth-value-tes... Contrast this to something like Java where all code is littered with shit like foo != null and foo.length != 0.