The Three Doors of Type Systems

by Ville Laurikari on Wednesday, November 11, 2009

Post image for The Three Doors of Type Systems

Every so often, I get drawn into a discussion about the merits of static typing (Java, C, C#, ML) versus dynamic typing (JavaScript, Python, Ruby, Scheme). Many programmers seem to be firmly in one camp or the other. But somewhere in between, there’s a third door. Let me explain…

I hate dynamic typing.

Dynamic typing leaves too much room to leave mistakes in your code. Stupid ones, too, the kind where you try to subtract apples from golf clubs. And the kinds where you sort of forgot to implement the “else” part.

These are typical mistakes which could be proved, by the compiler, to never possibly work. Only it’s not even trying, and it’s leaving it all up to me, a dodgy forgetful emotional interrupted tired inferior human, to stare at it long enough to assure myself that it will work correctly in all possible situations. It won’t, of course.

I hate static typing.

Static typing makes you think about types when you want to think about your program. Before you can run anything, the compiler insists that everything is perfect, but you’re only just starting to build the shape of your code. You probably don’t know what it’s going to look like when it’s finished. Perfect is for later.

I hate lack of type inference.

Spelling out the types for each variable and parameter and return type and field makes your programs ugly. Most of that type information is implicitly clear to you, so it makes no sense that you have to always explicitly mention every type in the actual code. The compiler and IDE should do some of that for you.

I hate type inference.

Full-blown type inference makes type errors insanely difficult to locate. The compiler figures out that the types in your code aren’t adding up, but it has no idea where the error actually is. The problem is that often you have no idea, either.

The point I want to make is that the choice between dynamic and static typing is a false dichotomy. You don’t need to choose between showering and brushing your teeth. You do both. In the same way, you shouldn’t have to choose between static typing or dynamic typing. You should be able to use the appropriate tools in the appropriate places at the appropriate time. The right kind of static typing is discretionary static typing.

Luckily, programming languages are already moving in this direction. Yesterday, Google published a new programming language called Go:

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language

That sounds like just what the doctor ordered. C# from Microsoft is also steadily gaining some type inference and dynamic typing features. Both C# and Go are actively trying to fix some of the biggest pain points in the working programmers’ lives.

I for one will be taking a good look of what’s behind the third door. Will you?

Related posts:

  1. Copy-On-Write 101 – Part 3: The Sum of Its Parts
  2. The Essence of Lambda
  3. Programming Problems in Disguise

If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.

Comments on this entry are closed.


Michal Mocny December 9, 2009 at 19:26

Completely agree :)

C++0x will have the ‘auto’ keyword and decltype, so, I guess it will soon fit into that boat as well.

Ville Laurikari December 9, 2009 at 21:01

I haven’t kept up with the development of C++, so I wasn’t aware that the next version of C++ will have type inference. Thanks for the tip. Looks like we’ll still have to wait a couple of years for that, though.

Daniel February 15, 2010 at 12:11

Why wait? The D Programming Language has had type inference for over four years. Actually, D (1.0 and moreso the upcoming 2.0) has many of the features that C++0x has been promising, sometimes years in advance.

My personal favourite was implementing C++0x style futures entirely in library code. :P

Previous post:

Next post: