Statically typed vs dynamically typed languages

Since the advent of dynamic programming languages, there has been ongoing debate about which language paradigm; statically-typed or dynamically-typed is better in terms of developer productivity. If you asked developers to share their opinions on the subject, you would probably get a wide range of conflicting answers; each of which would typically be biased in one direction or another depending on the developer’s area of expertise (and a lack of understanding of the alternative). Having gone back and forth between statically-typed and dynamically-typed languages several times in my career, I hope that I’m qualified to make this list of pros and cons: Advantages of statically-typed languages: Better code completion. Better performance (type constraints offer more opportunities for compiler optimizations). You can get hints and documentation inside your IDE while you code. This reduces the likelihood of making incorrect assumptions about the behavior of specific functions/methods. It’s easier to find things. For any variable or function, you can easily jump to its class definition without leaving the IDE and without having to know anything about the directory structure of the project. Conversely, for any class or function definition, you can easily and unambiguouslysee where that class or function is used in your code and jump to it without leaving the IDE. (Statically typed languages make it easier for IDEs to do this). Static typing makes it easier to work with relational databases and other systems which also rely on static types — It helps you catch type mismatches sooner at compile-time. It can help reduce the likelihood of some kinds of errors. For example, in dynamically typed languages, if you’re not careful with sanitising user input, you can end up doing weird stuff like (for example) trying to add a number with the string “8” and you would get the string “108” as a result instead of the number that you were expecting. 10 18 Advantages of dynamically-typed languages: More succinct/less verbose. The absence of a separate compilation step (which is much more common) means that you don’t have to wait for the compiler to finish before you can test changes that you’ve made to your code. This makes the debug cycle much shorter and less cumbersome. The delay introduced by the compile step can be distracting and break your train of thought. Even a 10-second compile step tends to add up over time. Pretty much every statically-typed language will claim to have “instant”, “partial” or “incremental” compilation, but in practice on any decent-sized project, it’s rare to see compilation take less than 10 seconds on an average machine. You spend less time debugging syntax and semantic errors — Instead, almost all of your debugging time is spent purely on logic errors (which are more interesting). A semantic error could be as simple as having a variable of type and trying to assign to it an instance of (type mismatch; even if they have the exact same interface)— These kinds of errors are often easy to resolve but cumulatively, they still take up a fair amount of developer time. Semantic errors are the obvious, silly kinds of errors that make you blame yourself for not adhering to the compiler’s stringent needs. For example in a dynamically-typed language something like is usually OK, but the compiler of some statically typed languages will throw an error because 1 is not a Boolean. myVariable ClassA ClassB if (1) { ... } More tolerant to change; code refactors tend to be more localized (they have a smaller area of effect). For example, with statically-typed languages, if you rename a class, you have to rename references in more different places in your code (though many IDEs can automate this to some extent)… A better example is if you have two or more different classes and you decide that they should share a single interface and refer to them by that interface, it takes more time to update them. Also with statically typed languages, because each object has more rigid relationships with other objects, the system can become a complex, inflexible puzzle; if a new piece doesn’t fit exactly into the existing structure, you may have to redesign the entire puzzle sooner rather than later. Based on this list, it’s easy to see why developers are so divided on the subject. Ultimately, it comes down to personal preference and the kinds of tools that you like to use. Personally, I have a preference for dynamically typed languages because I hate to wait for the compiler when I’m debugging. Maybe this is related to my particular debugging style; either way, it’s the point that has the biggest impact on my productivity. I do miss not being able to jump around different parts of my code by clicking on stuff but I compensate for it by organising my code into logical directories and by naming my classes/objects/variables appropriately — Then I can find them using text-search. That said, I don’t think the difference in productivity between the two paradigms is too significant and it probably varies from developer to developer. You’ll always be more productive when coding in a language that you enjoy.