Strong vs Weak Typing: Differences and Tradeoffs

Types are very important and permeate most work we do when programming, and also how we reason about our programs and systems. I've tried to list a few trade-offs and comparisons between them to help us choose which one suits our needs the best.

I'm thinking of these definitions as follows:

Strong Typing:

• Every variable has just one type

• Methods have strict type signatures

• Usually requires code compilation

Weak Typing:

• Objects and variables may have types but generally there is no way to define a variable's type

• Usually found in interepreted languages, hence no compilation to verify whether types match

Timing

Strong Typing: More work at the beginning (hardly any programs work compile the first time you code them), but compile type errors mean system behaviour will be more predictable at runtime.

Weak Typing: Easier to get a system working from the get-go (no compile-time errors or type errors), harder to keep complexity at bay and avoid runtime errors as the system grows.

Testing

Strong Typing: Type and compile-time errors are easily caught but that doesn't prevent you from having to test funcionalities, i.e. not how well the implementation fits the requirements, but how well the system fits actual user expectations.

Weak Typing: Requires much more testing than strong typing.

The reason is clear: much fewer potential errors are caught at compile time.

Behaviour at runtime

Have you ever wondered why you don't ever have runtime errors on SQL queries?

Strong Typing: Tends to be more reliable and stable.

If you run your program once and it works, it's likely that it is correct, for all cases.

Weak Typing: Tends to be less reliable and prone to errors.

You may have a system that runs well for weeks and breaks when some new unforeseen condition is met.

An object whose attributes have not been correctly set (for example, due to faulty user-interaction) will cause a runtime error;