Type Checking

The existence of types is useless without a process of verifying that those types make logical
sense in the program so that the program can be executed successfully. This is where type
checking comes in. Type checking is the process of verifying and enforcing the constraints of
types, and it can occur either at compile time (i.e. statically) or at runtime (i.e. dynamically).
Type checking is all about ensuring that the program is type-safe, meaning that the possibility of
type errors is kept to a minimum. A type error is an erroneous program behavior in which an
operation occurs (or trys to occur) on a particular data type that it’s not meant to occur on. This
could be a situation where an operation is performed on an integer with the intent that it is a
float, or even something such as adding a string and an integer together:

X= 1+ “2”

While in many languages both strings and integers can make use of the + operator, this would
often result in a type error because this expression is usually not meant to handle multiple data
types.

When a program is considered not type-safe, there is no single standard course of action that
happens upon reaching a type error. Many programming languages throw type errors which halt
the runtime or compilation of the program, while other languages have built-in safety features to
handle a type error and continue running (allowing developers to exhibit poor type safety).
Regardless of the aftermath, the process of type checking is a necessity.

Now that we have a basic understanding of what types are and how type checking works, we can
start getting into the two primary methods of type checking: static type checking and dynamic
type checking.

The key difference between the two is that with static type checking,
the type of variable is known at compile time (it checks the type of variable
before running) while with dynamic type checking, the type of variable is
known at runtime (it checks the type of variable while executing).

Static Type Checking

A language is statically-typed if the type of a variable is known at compile time instead of at

The big benefit of static type checking is that it allows many type errors to be caught early in the
development cycle. Static typing usually results in compiled code that executes more quickly
because when the compiler knows the exact data types that are in use, it can produce optimized
machine code (i.e. faster and/or using less memory). Static type checkers evaluate only the type
information that can be determined at compile time, but are able to verify that the checked
conditions hold for all possible executions of the program, which eliminates the need to repeat
type checks every time the program is executed.

A static type-checker will quickly detect type errors in rarely used code paths. Without static
type checking, even code coverage tests with 100% coverage may be unable to find such type
errors. However, a detriment to this is that static type-checkers make it nearly impossible to
manually raise a type error in your code because even if that code block hardly gets called – the
type-checker would almost always find a situation to raise that type error and thus would prevent
you from executing your program (because a type error was raised).

Dynamic Type Checking

Dynamic type checking is the process of verifying the type safety of a program at runtime.
Common dynamically-typed languages include Groovy, JavaScript, Lisp, Lua, Objective-C,
PHP, Prolog, Python, Ruby, Smalltalk and Tcl.

Most type-safe languages include some form of dynamic type checking, even if they also have a
static type checker. The reason for this is that many useful features or properties are difficult or
impossible to verify statically. For example, suppose that a program defines two types, A and B,
where B is a subtype of A. If the program tries to convert a value of type A to type B, which is
known as downcasting, then the operation is legal only if the value being converted is actually a
value of type B. Therefore, a dynamic check is needed to verify that the operation is safe. Other
language features that dynamic-typing enable include dynamic dispatch, late binding,
and reflection.

In contrast to static type checking, dynamic type checking may cause a program to fail at runtime
due to type errors. In some programming languages, it is possible to anticipate and recover from
these failures – either by error handling or poor type safety. In others, type checking errors are
considered fatal. Because type errors are more difficult to determine in dynamic type checking, it
is a common practice to supplement development in these languages with unit testing.

All in all, dynamic type checking typically results in less optimized code than does static type
checking; it also includes the possibility of runtime type errors and forces runtime checks to
occur for every execution of the program (instead of just at compile-time). However, it opens up
the doors for more powerful language features and makes certain other development
practices significantly easier. For example, metaprogramming – especially when
using eval functions – is not impossible in statically-typed languages, but it is much, much
easier to work with in dynamically-typed languages.