Strong/Weak vs Static/Dynamic typing

During the past week, while imbuing myself with Ruby knowledge, I came across a few discussions about the nature of Ruby vs that of other languages such as Java, Python, Perl, etc. Most of those discussions centered around the type systems in each language.

It seems quite common for people to mix the concepts of strong/weak and static/dynamic language typing. Let me clarify, these are two different categories, almost orthogonal to each other. A language can be strongly-typed and dynamically-typed at the same time.

Static vs Dynamic

Informally, a statically typed language enforces type consistency at compilation time, whereas a dynamically typed language defers this until runtime. In reality, there's a wide gamut of "typing dynamism" so it would be incorrect to say that every language falls into either category. At one end of the spectrum lie languages such as ML or Haskell; at the other end, languages like Lisp. Java and C++ lie close to the statically-typed end, whereas Ruby and Python lie close to the opposite end.

Here's an example of dynamic typing, in Ruby:

class Car
     attr :price
end

class Apple
     attr :price
end

def calculateTotalPrice(item, quantity)
     item.price * quantity
end

car = Car.new
car.price = 300
calculateTotalPrice(car, 2)

apple = Apple.new
apple.price = 2
calculateTotalPrice(apple, 12)

The type of the arguments to calculateTotalPrice are not bound or even checked at compile type. That determination is left till the moment the method is actually called.

With a statically typed language, on the other hand, the type of the actual parameters must match those of the formal parameters in a call. The example above could be rewritten in Java as:

class Item {
     float price;
}

class Car extends Item { }

class Apple extends Item { }

class Calculator {
     float calculateTotal(Item item, int quantity)
     {
         return item.price * quantity;
     }
}

The difference here is the introduction of the Item superclass and typed arguments for calculateTotalPrice. Trying to call that function with anything that is not an Item will fail at compile time. Disclaimer: this is not a good way to use inheritance, since it involves bringing two unrelated classes under the same hierarchy just for interface compliance. It's just an example to illustrate static typing without excesive boilerplate.

Here's a simpler example. In Ruby it we can do:

class Car; end
class Apple; end

obj = Car.new
obj = Apple.new

The type of obj is determined at runtime, based on what object it points to.

The Java equivalent would be:

class Car {}
class Apple {}
...

Car car = new Car()
Apple apple = new Apple()

car and apple are variables of type Car and Apple, respectively. Attempting to assign new Car to apple would fail at compile-time.

Of course one could replace the type of all variables with Object, effectively turning the language into a dynamically-typed one. That's one of the reasons why Java is not at the end of the spectrum, but close to it.

Strong vs Weak

It is a little harder to define what a strongly vs weakly typed language is, but it revolves around the notion of how much effort does the language put into checking type consistency (either at runtime or compile time). In this sense, Java and Ruby are both strongly typed, whereas Javascript is weakly typed.

In Ruby, it is possible to access only to methods and attributes that have been defined in a class or added to an object at runtime:

def ColoredObject
     attr :color
end

obj = ColoredObject.new
obj.color = "blue"

Attempting to access a method or attribute not defined explicitly for the class or object will cause a runtime error.

On the other hand, in weakly typed languages such errors will go unnoticed. For example, in JavaScript it is possible to access an attribute that doesn't exist in an object (it will be created on the fly):

var obj = new Object();
obj.color = "blue";

Some may say this is a feature. But it has its dangers (a simple typo can be very hard to detect and find).

Ruby seems to capture the best of both worlds. While being a strongly typed language, it has a mechanism for adding methods and attributes to objects at runtime (whether even compile time exists in Ruby is the topic of another discussion :) ):

class Car
end

car = Car.new
car.color = "blue" # fails with "NoMethodError: undefined method `color=' for #"

# let's add an attribute named "color"
def car.color= (value)
     @color = value
end

car.color = "blue" # succeeds