Strongly Typed Weakly Understood

David Buck
January 25, 2004

I keep hearing different definitions of the term "Strongly Typed" from different places. I'm now starting to wonder if there's an "official" definition in any sense of the word "official" and what that might be.

My own interpretation of "strongly typed" lines up roughly with the one in HyperDictionary:

Strict enforcement of type rules with no exceptions. All types are known at compile time, i.e. are statically bound. With variables that can store values of more than one type, incorrect type usage can be detected at run time.

From this definition, Smalltalk can be considered strongly typed. All variables are implicitly defined as a reference to an object. There's no need for manifest typing i.e., explicit type declarations for each declaration. All variables can store values of more than one type and incorrect type usage can be detected at run time (normally by a 'message not understood' exception).

I find it distressing, then, when I hear "strongly typed" being used instead of "staticly typed" or "manifest typed".

One particularly quirky definition comes from It states:

A strongly-typed programming language is one in which each type of data (such as integer, character, hexadecimal, packed decimal, and so forth) is predefined as part of the programming language and all constants or variables defined for a given program must be described with one of the data types. Certain operations may be allowable only with certain data types. The language compiler enforces the data typing and use compliance. An advantage of strong data typing is that it imposes a rigorous set of rules on a programmer and thus guarantees a certain consistency of results. A disadvantage is that it prevents the programmer from inventing a data type not anticipated by the developers of the programming language and it limits how "creative" one can be in using a given data type.

Another bizarre usage is seen in articles like this where they state:

"So what, exactly, is a strongly-typed .NET collection", you ask? It's an alternative to System.Collections.ArrayList, which deals only in typeless "objects". ArrayList works great, but its typical usage requires quite a bit of casting to appease the compiler. Such wanton downcasting is a very error-prone coding style... the use of a strongly-typed collection class eliminates the need for casting, thus allowing the compiler to catch many common coding errors at compile-time, rather than run-time.

They seem to be saying that code that does casting is not strongly typed. As I see it, so long as a type error is detected at runtime when an invalid cast is made, the language is still strongly typed. In fact, in this quote, they are attributing the term "strong typing" to the specific coding technique rather than the language.

Frustrating? Yes. I know that terms tend to get confused. This is one, though, that is very widely confused. It makes the term virtually useless.


Another angle

[Harry Fuecks] January 26, 2004 17:20:32 EDT

"A type system is considered strong if you can't lie, and weak if you can lie." From a considered essay on the subject:

Re: Strongly typed, weakly understood

[Vassili Bykov] January 26, 2004 18:50:47 EDT

Comment on Strongly typed, weakly understood by Vassili Bykov

Hear, hear! The main cause of this confusion is that the various "X typing" terms are used to qualify orthogonal language properties, while those who use those terms often do not have enough exposure to language semantics to realize the need for all of those qualifications and the difference between them. Here are the terms as I use them:

Static vs dynamic typing describes at what point type analysis (determining whether a programmer's request to perform a particular operation is permissible) happens: at compile time for a statically typed language, or at run time for a dynamically typed one. Manifest typing in this view is close in the meaning, if not necessarily an exact synonym, of static typing. Statically typed languages often require type declarations in programs, however some statically typed languages such as ML can in some cases infer types from the operations performed, making manifest type declarations unnecessary. It is important to note that dynamic typing does not imply absence of type checking, in spite of the absence of variable and function type declarations--so calling dynamically typed languages such as Smalltalk "untyped" would be grossly incorrect.

Strong vs weak typing characterizes whether type checking, static or dynamic, can be meaningfully circumvented. "Meaningfully" is important here, implying that the type overrides should be predictable in their effect and at least reasonably portable between implementations. In a weakly typed language such overrides are possible. For example, in C , one can take a pointer to an Employee, cast it to char* and pass to a function that expects an argument of that type. In contrast to that, in Smalltalk it is not possible to take an instance of Employee and use with it an operation not defined for instances of Employee.

In my opinion, part of the reason static and strong typing are often confused is because (don't laugh) the words "strong" and "static" are too similar. Two Mac OS X technologies, Carbon and Cocoa, are also often confused because of the similarity of their names. Some even invented a mnemonic rule to help remember which is which, along the lines of "Carbon is the portability framework for old applications, so old that they became carbonized".

Re: Strongly typed, weakly understood

[David Buck] January 27, 2004 04:07:49 EDT

Both of the above comments confirms my understanding of strong typing. If you can't break the type rules and misinterpret bits, you have a strongly typed language. (Incidently, the article Harry referred to is an interesting exposition on the subject).

The only thing I disagree with in Vassili's post is that Manifest Typing is almost an exact synomym for Static Typing. Manifest Typing requires you to explicitly declare a type for all variables and return values. Static Typing allows you to infer some of the types. That seems a significant enough difference.

Re: Strongly typed, weakly understood

[Vassili Bykov] January 27, 2004 12:15:08 EDT

Comment on Strongly typed, weakly understood by Vassili Bykov

But I didn't say that. I said manifest typing was close in the meaning to static one in the view of when type check is performed. It's hard to imagine a language with manifest typing that wouldn't be statically typed. Perhaps I should have elaborated in the first place and say that while dynamic vs static distinction defines when a type check is performed, the manifest vs inferred types distinction--how a static type check is performed.

Manifest typing

[David Buck] January 27, 2004 14:10:22 EDT

Sorry Vassili. I missed the "in this view" part. It makes more sense now.

manifest typing

[Andrei N.Sobchuck] January 28, 2004 01:27:47 EDT

"It's hard to imagine a language with manifest typing that wouldn't be statically typed" - What about languages in rdbms. For example, in pl/pgsql (PostgreSQL) all variables are declared with type (, but it isn't staticaly typed (type analysis happen in run-time).

Re: Strongly typed, weakly understood

[David Buck] January 28, 2004 04:49:53 EDT

Comment on Strongly typed, weakly understood by David Buck

Manifest typing is normally considered a specialisation of Static typing, so if it's manifest typed, it ust be (by definition) also statically typed.