Type systems

From Arnout Engelen

Type systems are an area of interest of mine.

Even though the position seems to be rather unpopular these days, I like static type systems. In a sufficiently rich type system, if you cannot express your assumptions in types, your design is too complicated: you probably can't wrap your head around it probably, either. This way, using a typed language forces you to write simpler, and thus more maintainable code.

The lack of a static type system makes catching errors due to code changes an almost impossible task. No, unit testing is not sufficient here.

On the other hand, I entirely acknowledge the type systems of popular statically typed languages are generally much too rigid, and this is hampering productivity. I'm not ready to throw the baby out with the bathwater, however.

[edit] Structural types instead of nominal types

Most popular statically typed languages use 'nominal typing': an object is of type 'Foo' if and only if it has something like 'extends Foo' written in its class definition.

This is way too rigid, because it requires that the component providing the object and the component consuming the object need to have a common dependency.

Structural typing is much more flexible: an object is of type 'Foo' if it implements all of the structure of 'Foo'. Using this right gives you much of the advantages of the 'Duck Typing' found in dynamic languages, but in a way that can be statically checked.

See also: http://www.c2.com/cgi/wiki?NominativeAndStructuralTyping

[edit] See Also

interesting article: http://wiki.jvmlangsummit.com/PythonGradualTyping