Nikos Vaggalis explores the difference between static and dynamic type systems in the first of a three-part series and explains why it is an important issue that a programmer must master.

As traditional static languages such as C# tend to become more dynamic, and dynamic languages tend to become more static, as Perl 6 will do, a deep understanding of the concepts attached to static and dynamic type systems becomes ever more important. Integrated platforms like .NET embrace many and diverse programming languages which allow a programmer or a team, to use more than a language depending on the situation and requirements of the project involved; i.e. use both VB.net and C# or even a static language (C#) and a dynamic one (JavaScript). In this scenario one potential pitfall is that in C# the Object acts differently than an Object in JavaScript , or could act differently than in VB.NET.

Another more fundamental issue with type systems and constant/subtle source of mix ups, is the terminology used. For example the terms static and strong are used interchangeably as if they mean/are the same thing; the same holds true for dynamic and weak.

For these reasons, it is essential to have a firm grasp on not only each system's shortcomings and particularities but also on their essential characteristics, so to enjoy maximum performance and potential by at the same time avoiding potential pitfalls presented by the type system.

This article is intended to help to someone who has a dynamic language background and wants to jump into the .NET platform, someone with VB.NET experience that wants to know how things work in C#, the C# programmer interested in dynamic programming, and any programmer who wants to know how type systems work.

Static typing

Static typing does not go hand in hand with strong typing, although that is the traditional way encountered in a multitude of programming languages like C++.

In simple words static typing means tying a variable with a type at compile time:

 class Class1
 {
   public void MyMethod(int x)
   {

   }
 }

 Class1 myobj = new Class1();

Now variable myobj is tied to the Class1 type; furthermore the type pertains to the variable and the variable cannot change type at runtime.

Static typing enforces type safety by allowing the compiler to check for erroneous operations on the type so that some runtime errors will not occur e.g. invoking a method on an object that does not support it.  And since you have compile time information you are able to use advanced IDE features like looking up the type's members with Intellisense.

In my opinion the most important aspect of static typing is that the operation on a value is dictated by the variable's type and not by the actual runtime type of the object. Let's say Class1 implements IMyinterface interface.

Example 1

 interface IMyinterface
    {
      void MyInterfaceMethod();
    }

 class Class1:IMyinterface {

 }

 Class1 myobj = new Class1();

By using variable myobj I can call any method supported by Class1, including the implemented methods of interface IMyinterface but by using a variable of the interface type:

 IMyinterface myobj1 = 
          (IMyinterface) myobj

or implicitly

  IMyinterface myobj1 = myobj;

I can call the methods supported by IMyinterface only plus all the methods implemented by the base Object type.

That is, I can call

 myobj1.MyInterfaceMethod();

but not

 myobj1.MyMethod();

<ASIN:0735626375>

<ASIN:059652028X>

<ASIN:0735625662>