Erik Osheim has written an excellent article comparing dynamic and static typing. More precisely, he compares Python to Scala. What makes his article interesting, is that he focuses on the consequences of the type systems. The article you're currently reading is a (not so) short summary of Eriks article, plus a few thoughts of mine.
Consequences of dynamical typing on your coding style
According to Erik,
- Python programmers rarely have to wade through huge class hierarchies with poor documentation.
- APIs tend to be strongly-focused on what you want to do.
- You get much more mileage out of learning the default collections' APIs.
- Custom collections feel stronger pressure to conform to default APIs.
- Python programmers can assume most data has a useful string representation.
- Developers rarely have to worry about baked-in limitations of your types.
(Quoted from Erik's article).
Benefits and disadvantages of duck typing
He also says that abstracting over things like variance become much simpler. I guess that's one of the things that make Groovy such an attractive language: duck typing allows you to use a method with different parameter types. Methods don't mind if you pass them a String instead of an integer. You only have to make sure the method the parameter has all the attributes and methods needed by the method you call.
However, that's the primary reason why I don't like dynamic typing. When I programmed Visual Basic - which was a partially dynamically typed language at the time - errors had a creepy tendency to occur at the customers'. There was a compiler, but it didn't detect too many errors. I'm told professional programmers using a dynamically typed language are very eager to write unit tests to avoid such a mess.
The cost of learning the type system
Another interesting point Eric mentions is, that it's a lot of mental work to learn the type system. That's something the pros tend to forget. Once you've survived the painful days (or weeks, or months) of learning, you benefit from static typing. But according to Eric, it's hard to get started. He even claims that some developers never reach a deep understanding of the type system, especially in the case of complex languages like Scala.
Advantages of strong type system (a small selection)
Be that as it may, there are many advantages of strong type systems. At this point, I'll pick two advantages I've experienced in my own career:
- Static typing makes it much easier to optimize code during compilation. Modern compilers of Python or Javascript go into great length to optimize code, making it almost as fast as Java code. But there's always a lot of speculative optimization which can turn out to be wrong at any point of time. Then the runtime has to de-optimize the code, suffering from a performance penalty. On the other side of the spectrum are languages like C, which can be compiled and optimized before starting the application. The compiler has a lot of time to optimize the code. For instance, the Intel C compilers have different optimization levels. On the lower levels, compilation is fast. On the higher levels, the compilation takes painfully long - but the resulting code is a lot faster, often surprisingly so.
- You don't want to write a framework in a dynamically typed language. Base classes have to be rock-solid and fast. Both requirements are best met with a pedantic compiler checking the code meticulously before it's sent to the customer.
When to use which?
As a consequence, dynamically typed languages are extremely useful for small or short-lived programs. In this scenario, developers are much more productive than they are with strongly typed languages. However, the more the code base grows, the better you're off with a statically typed language. An interesting approach is to use a strongly and statically typed language such as Java or Scala for the base classes, and a dynamically typed language for the remaining code. That's the nice thing about the JVM: it supports both families of languages, and every JVM language plays nicely with Java. In theory, you can also choose another language for the framework, provided you verify in advance that the dynamic language can use the methods and classes of the language used for the base classes.
Now I'd like to point you to Erics article. There's a lot to discover: He mentions several interesting points I omitted for the sake of brevity, and there's an interesting discussion going on in the comments section of Erik's article.
Dig deeper
Erik Osheim on static vs. dynamic typing.