Continuing the attempt to demystify type systems in different languages Nikos Vaggalis looks at what distinguishes  weakly typed languages from strongly typed ones.

In Part 1 of this series we explored and compared the static and dynamic systems. Now we are going to focus on weak and strong typing and discover once more that the boundaries (which languages are considered strong and which weak) are not clearly defined.

Weak versus strong

The main difference, roughly speaking, between a strongly typed language and a weakly typed one is that a weakly typed one makes conversions between unrelated types implicitly, while a strongly typed one typically disallows implicit conversions between unrelated types.

Furthermore a strongly typed language requires an explicit conversion (by using the cast operator) between related types, when there is possibility of data loss, while a weakly typed one would carry out the conversion regardless.

In the above discussion 'related' and 'unrelated' are meant with regard to 'family'. That is, an integer and a short belong to the same family while a string and an integer belong to unrelated families

In the rest of this article we will explore examples of weak typing and return to look at strong typing in a further part.

Weak Typing in Perl

Perl is an example of a weakly typed language and it has no problem mixing unrelated types in the same expression and the following example shows.

Example 1

$a=10;
$b="a";
$c=$a.$b;
print $c; #10a

Variable $a started life as containing a number but during the expression evaluation $c=$a.$b that number was implicitly converted to string "10" for the operation to succeed. Note that which operand of the two is chosen for converting is decided by the operator; the dot “.” operator works on strings thus number 10 was chosen to be converted into string "10".

Example 2

$a=10;
$b="a";
$c=$a+$b;
print $c; #10

Here the '+' operator works on numbers, thus string "a" (not a single character but a string) is chosen to be converted to a number; but string "a" contains no numerics and at this point the interpreter has to make a choice: ‘Do I proceed with the operation or do I throw a runtime exception? ‘ In cases like that, the Perl interpreter would always choose to convert the string to number ‘0’ for the expression evaluation to succeed.

In a later example we will take a look at how VB.Net would respond in a similar case.

Example 3

$a=10;
$b="20a";
$c=$a+$b;
print $c; #30

In this Perl snippet string "20a" can be converted to a number by disposing the "a" part of the string, thus 10+20 = 30

Example 4

$a=10;
$b="a20";
$c=$a+$b;
print $c; #prints 10

In this final Perl case, string "a20" cannot be converted to a valid number so it was implicitly converted to number 0.

It all came down to the operator of the expression which directed the implicit conversion of the operand(s); the '+’ operator works on numbers and the dot operator '.' works on strings, as simple as that.

C# weak typing

The following C# example would blatantly fail at compile time with an error:

Example 5

using System;
namespace ConsoleApplication2
{
 class Program
 {
  static void Main(string[] args)
  {
   double a = 7.3;
   string x = "hi";
   a = a - x;
   System.Console.Write(x);
  }
 }
}

Error 1      Operator '-' cannot be applied to operands of type 'double' and 'string'

Note: I specifically used the minus '-' operator for the C# example and not the plus '+' operator (a = a + x;)  for reasons that will become shortly apparent

C# does type checking at compile time and notifies us that the types in question are not compatible; a string and a number cannot be subtracted; C# enforced strong typing. It checked the type of the arguments at compile time and considered an operation involving both of them erroneous.

Since C# does the type checking at compile time we get no surprises at runtime; no exception is fired and performance is not degraded.

Note that Perl also does type checking but rather than doing it at compile time it does so at runtime, thus if something is going to fail it would do so at runtime

However, what is considered an error or not comes down to the language design itself; Perl did not find operating on a string and an integer in the same expression erroneous, but C# did. 

<ASIN:0321658701>
<ASIN:1451531168>

<ASIN:0123745144>

<ASIN:0470532874>

<ASIN:0735627045>