archives

Static Typing and Expressivity

I recently discovered an essay, "What To Know Before Debating Type Systems." It is an excellent essay, and I highly recommend reading all of it. However, there was one particular section that really caught my attention: "Fallacy: Static types imply longer code." The author suggests that a static type system can actually allow a programmer to write more concise solutions to some problems.

There is one Haskell example given to support this: if you compare the return value of Data.Map.lookup to "Nothing" or "Just object", then the function's return value will be of type "Maybe object". If you don't do this check, then the function will throw an exception if the search value isn't found. Unfortunately, I'm new to Haskell and having trouble understanding how this capability can make code more concise. If I'm not mistaken, the "lookup" function is polymorphic on the return type. The person that wrote "lookup" created several versions with different return types, and Haskell can infer the correct one to use based on the way that the return value is used. But if I were using an untyped language, wouldn't it be possible for me to write the same functions with slightly different names for different return types? Perhaps "lookupEx" could throw an exception while "lookupNull" could return some sort of Null value. I admit that this solution seems somewhat less elegant and reliable, but I think the code would be about the same length.

I would really appreciate it if anyone could offer some insight into this issue. Also, if you happen to know of any other articles or papers describing examples of improved expressivity through static typing, I'd love to read them.

To clarify, I certainly agree that a static type system can catch errors at compile time that wouldn't be caught until runtime in a dynamically typed language (even including some infinite loop bugs!). However, right now I'm mainly curious about expressiveness. Unfortunately, many people refer to a static type system that can express a lot of information about the variables and thus catch more bugs as an "expressive" type system. This ambiguity has made it difficult to find answers with Google.

Thanks