Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Language Type Systems

07.29.2009
| 3659 views |
  • submit to reddit

All programming languages have a type system. Typically, we classify these type systems as either static or dynamic. A shift that’s taking place is to include type inference engines within a programming language that allows the developer to realize the safety benefits of static typing and the flexibility and expressiveness benefits of dynamic typing. I talked briefly about these ideas in The New Era of Programming Languages.

For many though, the whole type system issue comes down to compilation. Statically typed languages require type information because the compiler needs to verify that the type is not used incorrectly throughout the program. Dynamically typed languages typically don’t have a compiler, so the type verification is left to run-time.

So in general, we typically say that statically typed languages are safer because the compiler catches certain types of errors at run-time, but dynamically typed languages are more flexible and expressive because we don’t need a bunch of language constructs to get us past the compilation step. A good example of this is an interface in Java. A class needs to implement an interface simply to get past the compiler. At runtime, that interface provides no value. Dynamic languages typically rely on duck typing instead of inheritance. Other interesting aspects of a language’s type system include covariance and contravariance, which are related to how types are ordered within a class hierarchy, and impact how the language deals with return types and method parameters.

But there is another dimension to a language’s type system that often goes unnoticed. A language is either strongly or weakly typed. For years, we’ve recognized Java as a statically typed language, while Ruby’s type system is dynamic. Because Java is statically typed, it’s natural to assume that is also has a strong type system, and since Ruby is dynamically typed, it’s easy to assume it has a weak type system. Not quite so true, however. Time for an example.

Let’s take the same simple program, written in both Java and Ruby. The code in Figure 1 is Java code that attempts to add a String and an int.

public class TypeSystemTest {
public static void main(String args[]) {
System.out.println("4" + 2);
}
}
Figure 1

Interestingly, Java performs an implicit type conversion, the program runs successfully, and the resulting output is seen in Figure 2.

> 42
Figure 2

An identical Ruby program can be seen in Figure 3.

puts "4" + 2
Figure 3

Ruby, however, does not perform an implicit type conversion, and results in a TypeError. This output can be seen in Figure 4.

> TypeSystemTest.rb:1:in `+': can't convert Fixnum into String (TypeError) from TypeSystemTest.rb:1
Figure 4

In some cases, Ruby is actually more strongly typed than Java, but the dynamic type system of Ruby delays discovery of the problem until runtime. Java, on the other hand, is a statically typed language that uses implicit type conversion in special situations. This implicit type conversion results in a weak type system, meaning the program can suffer from undesirable side affects if the implicit conversion is not the desired conversion, yet no runtime error results.

The point here is that while Java is statically typed and Ruby is dynamically typed, we cannot categorically say that Java is safer and Ruby is less safe. The runtime type system has the final say in making that decision.

From http://techdistrict.kirkk.com

Published at DZone with permission of its author, Kirk Knoernschild.
Tags:

Comments

Mast Ermnd replied on Wed, 2009/07/29 - 5:13am

Very good article thank you.

I think there is a small mistake in the 2nd line of the third paragraph. You probably mean compile time, not runtime.

Johannes U. J. replied on Wed, 2009/07/29 - 7:51am

This article makes no sense. Implicit type conversion is not the same as desugaring, which is what java is using in the general case of string concatenation.

In the example given the Sun java compiler will produce:

javap -c TypeSystemTest
Compiled from "TypeSystemTest.java"
public class TypeSystemTest extends java.lang.Object{
public TypeSystemTest();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return

public static void main(java.lang.String[]);
Code:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3; //String 42
5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return

}

In this case it has performed constant folding making it equivalent to:

public class TypeSystemTest {
public static void main(String args[]) {
System.out.println("42");
}
}

Im not quite sure why this is type conversion.. ?
However, in the general case, when it cannot perform such an optimisation, it will produce:

javap -c TypeSystemTest
Compiled from "TypeSystemTest.java"
public class TypeSystemTest extends java.lang.Object{
public TypeSystemTest();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return

public static void main(java.lang.String[]);
Code:
0: iconst_2
1: istore_1
2: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
5: new #3; //class java/lang/StringBuilder
8: dup
9: invokespecial #4; //Method java/lang/StringBuilder."<init>":()V
12: ldc #5; //String 4
14: invokevirtual #6; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
17: iload_1
18: invokevirtual #7; //Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
21: invokevirtual #8; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
24: invokevirtual #9; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
27: return

}

 and as you can see it will just desugar it a method invocation of the append method which takes (tada) an int. So no type conversion has ever happend.. and this will never fail on runtime.

Alex(JAlexoid) ... replied on Fri, 2009/08/07 - 8:43am in response to: Johannes U. J.

This article makes no sense. Implicit type conversion is not the same as desugaring, which is what java is using in the general case of string concatenation.

 It does make sence, because this is an article about the language not the underlying VM. And "desugaring" is a part of the language, how it gets interpreted(transformed) is irrelevant.

 Otherwise, you could say that Ruby is as statically typed as Java, since it will definitely have a type associated with each and every allocated variable.

Oh, and BTW, you forgot to add a bit more clutter in the form of the constant pool.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.