What does it really mean to say a programming language has "strong" or "weak" typing?

This survey started from a Stack Exchange question How are "strong" and "weak" typing defined?, asking what is meant by describing a programming language as "strongly-typed" or "weakly-typed". The question pointed at the Wikipedia article on the subject and to a blog post by Curtis Poe featuring this quote:

Probably the most common way type systems are classified is "strong" or "weak." This is unfortunate, since these words have nearly no meaning at all. It is, to a limited extent, possible to compare two languages with very similar type systems, and designate one as having the stronger of those two systems. Beyond that, the words mean nothing at all.

Therefore: I give the following general definitions for strong and weak typing, at least when used as absolutes:

• Strong typing: A type system that I like and feel comfortable with
• Weak typing: A type system that worries me, or makes me feel uncomfortable

This note collects my survey results looking at how these terms were actually used, and whether we could assign any valuable meaning to either of them.

The Wikipedia article, and the blog post, are correct that these terms are not well-defined and are not useful for communicating in general, and at best can be used in a relative way within a particular context. Sometimes they refer to accessing the bit representation of a value as another type, sometimes they are about implicit type coercions, sometimes they refer to polymorphism, sometimes they refer to the presence of static types at all, sometimes they are about expressivity or dependent properties like bounds checking, and sometimes they are just a subjective impression of quality ("A type system that I like and feel comfortable with", indeed).

You will see these terms used with quietly different meanings, and you'll see those meanings explicitly disputed, sometimes both by what you might consider experts. That doesn't mean that they aren't used or can't be useful within narrow contexts where the relativity and the elements under comparison are understood and help, but it does suggest that they're not useful as freestanding terms.

I'm going to look at some uses of these terms from academic literature over time, and then highlight some conflicts that arise within it, both explicitly and implicitly.

Firstly, let's try to look for an actual definition, and then see whether that tracks with usage.

The Oxford Dictionary of Computer Science defines "strong typing" as:

A feature of some programming languages that requires the type of each data item to be declared, precludes the application of operators to inappropriate data types, and prevents the interaction of incompatible types.

It does not have a definition for "weak typing". This is probably the closest thing to an "authoritative definition" (at least, it's trying to be), but you might find points to question in there already, and many times the term is used will not be entirely consistent with it; it also depends on the meanings of several other terms, like "type".

Strongly-, weakly-, and even statically- and dynamically-typed just are not as firmly-defined as people tend to think while they're using them. To highlight this I sometimes put forward the case that "C is strongly-typed^, Perl is statically-typed^": both of these claims are obviously definitionally false, and yet... they seem to be true, from a certain point of view, under conventional descriptions of what those terms mean, and many definitions inadvertently include them.

A historical wart here is also that "strong typing" and "static typing" have at times been used as essentially exact synonyms; for example, see this Bertrand Meyer abstract from OOPSLA 1992, Ensuring strong typing in an object-oriented language:

Static typing, also known as strong typing, has a long and rich history in programming languages.

On the other hand, we can look to Strong typing of object-oriented languages revisited from OOPSLA/ECOOP 1990:

We regard this as a continuum where weakly typed means that the type of an expression carries little or no information. Smalltalk is an example of such a language where the type of instance variables convey very little information on what messages are legal to send to the denoted object. A perfectly strongly typed language would exclusively have expressions where its type carries all information about the denoted object. ... Languages with a hierarchical type system and qualified references serve as a compromise since some, but not necessarily all, operations on an object can be inferred from the qualification of the reference.

So, here, typical object-oriented polymorphism is contrary to strong typing. Among users of functional languages, this is a common concept of strong typing.

Further back, Type equivalence in strongly typed languages: one more look from 1979 says:

In a strongly typed language, each value has a unique type. The key impact of this is that, starting with the knowledge of the type of each identifier and constant appearing in the program, it is possible to determine the type of every expression in the program.

This is more or less just a description of sound static typing. It may rule out polymorphism again, although the languages being discussed simply didn't have it and that probably wasn't in mind.

A direct, if handwaved, definition is given in this paper:

Type systems may be static (compile time), dynamic (run time), strong (strict), or weak (loose). The type system of C/C++ is static and weak, meaning that it is up to the programmer to prevent type errors from occurring at runtime

followed by

The C/C++ type system is intentionally weak, i.e., allowing for arbitrary pointer casting

thus definining "weak typing" as memory reinterpretation. This is also a fairly conventional meaning for strong & weak typing.

We can see discussion of the very conflict you bring up as well, such as in Assessing the ripple effect of CS1 language choice in 2000:

Some say that C++ is strongly typed but this statement should be taken only with respect to the default static typing done on calls made through base class pointers. Otherwise, C++ is weakly typed like C, full of implicit casts, the interpretation of any type as a boolean, and the treatment of all primitives as integers -- language constructs that fail to reinforce the notion of a type to a novice.

We can see that there are some pretty divergent uses of "strong" and "weak" already. If these uses are sufficiently disjoint, maybe that would be ok.

There are direct conflicts in the uses of the terms. Let's zoom in on just one language and see how it's been described. We can see identification of Python as strongly-typed:

In contrast, using strongly typed text languages (even dynamically like Python) requires the understanding of data types and the respect of languages grammar and syntax

And we can see identification of Python as not strongly-typed:

This is rather difficult to detect in Python due to the lack of strong typing, and as such, there are additional uses that are not included in the results

TensorFlow used Python’s weak typing system to construct graphs from Python functions

We can see a set of languages classified as strongly- or weakly-typed in A Large Scale Study of Programming Languages and Code Quality in GitHub, FSE 2014:

Once more, Python is identified as strongly-typed. We can also find many other real-world uses that classify it in both directions, give conflicting definitions, and argue quite intensely.

You might agree or disagree with some others of those listed languages as well — and you'll see that reflected in the literature too, including directly in On the Impact of Programming Languages on Code Quality: A Reproduction Study in TOPLAS from Emery D. Berger, Celeste Hollenbeck, Petr Maj, Olga Vitek, Jan Vitek in 2019:

The Type category is the most counter-intuitive for programming language experts as it expresses whether a language allows value of one type to be interpreted as another, e.g., due to automatic conversion. The CACM paper attempted to clarify this definition with the example of the ID type. In Objective-C, an ID variable can hold any value. If this is what the authors intend, then Python, Ruby, Clojure, and Erlang would be weak as they have similar generic types.

The CACM paper referred to changes the name of that category to "Implicit type conversion", so clarifying that as the meaning they intended by "strong/weak typing" the first time (and likely reflecting pushback in between on this very controversy over the terms!). This is one meaning of "weak typing", but as we have seen above it's not the only one.

JavaScript given there is one of the categorical examples of weak typing, used all over the place, because of its many implicit coercions. On the other hand, another conventional perspective is that weak typing is about reinterpreting a value's memory representation as another type — this is where C falls — and you definitely can't do that in JavaScript — is it strongly typed? On yet another hand, C does define some types that can't be reinterpreted that way (function pointers) so is it strongly-typed too? We are stretching the terms beyond meaning at this point, but it highlights where these handwaves don't hold up when pushed.

Even this perspective that it's the implicit coercions that make JavaScript weakly-typed isn't as particular as it seems on the surface.

• Is every language with implicit widening conversion from float to double then weakly-typed also? Java does that, but is typically seen as strongly-typed.
• Is it the sheer number of type coercions? Java and C# actually have more, because they have multiple numeric types.
• Is it accessing methods or fields from different types through the same variable? This is just dynamic typing or polymorphism, so what's the role of "weak" here?
• Is it automatically invoking a stringifying operation during string concatenation? Many of the supposedly strongly-typed languages given above do that too.
• Is it that typical JavaScript code tends to invoke these coercions often? That doesn't have much to do with typing and is an empirical claim about usage, rather than the design of the language.
• Is it converting from strings back to numbers? Now we're getting somewhere specific, but we've come a long way from "is weakly-typed" and could more usefully say that directly!

On the other hand, in Perl there is no need for such a string⇒number conversion, because numbers and strings are the same type all along: is it then strongly-typed? Or perhaps all those other languages are weakly-typed too — but clearly that perspective is not universal, so we'd need to be explaining what we meant, and one wonders why we want to use these specific words for that.

Even other answers to the very question that led to this investigation pick out JavaScript as obviously without question one or the other. They give entirely contradictory rationales that let us distinguish the meanings in use, but clearly the terms then don't tell us anything themselves. We need to explain what properties we are concerned with, and then the explanation can stand on its own instead.

We can also look to Eric Lippert, a designer of C#, to comment on that language:

Well if I'm an authority then: I agree with Curtis. Is C# strongly typed? It has many features that people describe as "strong" and many features that people describe as "weak". If you mean "allows casting", say "allows casting", not "weak". If you mean "objects can describe their types" then say "objects can describe their types", not "strong".

This is highlighting where these terms are not useful on their own: it would be better to say what you actually mean about the type system, rather than bundling it up into "strong" or "weak", if you want to communicate something. Someone else will have a different meaning and a different understanding. The Python examples above highlight that it simply isn't useful to say "strong typing": you need to say what you're actually talking about, or you'll be talking past one another.

I wanted to sum up with a general high-level description of things that were suggestive of each category, but I'm not sure I can even do that. We might try to say that:

• A strongly-typed language is one where a value can only be used as its one true type — which could still be multiple types, or perhaps it can't, and what exactly is a type in this language, anyway?, and of course I want my language be strongly-typed and perhaps I don't want yours to be (witness the arguments about Python), and—
• A weakly-typed language is one where the bits of a value can be reinterpreted as another type — or one where they can't, but there are "too many" coercions available, or the coercions that exist are too error-prone, or the operations that give me a value of one type given a value of another type aren't the right shape, or the types that exist aren't the sorts of types I want to think of as types, or—

We can see a pattern there that "weak typing" is mostly negative framing, and I think that brings us back around to the quote from the original question:

• Strong typing: A type system that I like and feel comfortable with
• Weak typing: A type system that worries me, or makes me feel uncomfortable

Yes, that seems about right for how people use those terms. In context, it can make sense to contrast different approaches in that way, with a particular value system as a frame of reference, but in the abstract "strong typing" and "weak typing" don't communicate much more.