What is the supposed productivity gain of dynamic typing?

Question

I often heard the claim that dynamically typed languages are more productive than statically typed languages. What are the reasons for this claim? Isn't it just tooling with modern concepts like convention over configuration, the use of functional programming, advanced programming models and use of consistent abstractions - all of which could be used in statically typed languages as well? Admittedly there is less clutter because the (for instance in Java) often redundant type declarations are not needed, but you can also omit most type declarations in statically typed languages that use type inference, without losing the other advantages of static typing. And all of this is available for modern statically typed languages like Scala as well.

So: what is there to say for productivity with dynamic typing that really is an advantage of the type model itself?

Clarification: I'm more interested in big / medium sized projects than in quick hacks. :-)

Answer 1

I actually think it's a pretty close call. Both dynamic typing and static typing have their advantages.

Reasons for dynamic typing being more productive:

• It's more concise - A lot of extraneous boilerplate code can be removed if everything is dynamically typed - type declarations, typecasting logic etc. All other things being equal, shorter code is marginally quicker to write, but more importantly it can be quicker to read and maintain (since you don't need to wade through many pages of code to get a grip on what is happening)
• Easier to "hack" techniques such as duck typing and monkey patching can get you results very quickly (although might confuse you later on...)
• More interactive - dynamic typing is arguably more suitable for interactive, REPL-like programming for rapid prototyping, real-time debugging of running program instances or even live coding.
• Test cases can catch the runtime errors - assuming you are using TDD or at the very least have a good test suite, this should pick up any typing issues in your code.
• Better polymorphism - dynamic languages are potentially more likely to encourage the creation of polymorphic functions and abstractions, which can boost productivity and code re-use. Clojure for example makes great use of dynamic polymorphism in its many abstractions.
• Prototypes - prototype based data / object models are in my view more powerful and flexible than statically typed inheritance heirarchies. Dynamic languages are more likely to allow or encourage a prototype-based approach, Javascript being a great example.

Reasons for static typing being more productive:

• Better design - being forced to think about the types of values in your software up front can push you towards cleaner, more logical solutions. (I say can - it's still possible to design really bad code...)
• Better compile time checking - static typing can enable more errors to be caught at compile time. This is a huge advantage, and is arguably the best thing about statically typed languages overall.
• Auto-completion - static typing can also give more information to the IDE so that auto-completion of code or documentation lookup is more effective.
• Discourages hacks - you have to keep type discipline in your code, which is likely to be an advantage for long term maintainability.
• Type inference - in some languages (e.g. Scala) this can get you many of the conciseness benefits of dynamic languages will still maintaining type discipline.

On average my conclusion (after many years of experience on both sides of the fence) is that dynamic typing can be more productive in the short term, but it ultimately becomes difficult to maintain unless you have very good test suites and testing discipline.

On the other hand, I actually prefer statically typed approaches overall, because I think the correctness benefits and tool support give you better productivity in the long term.

Answer 2

With dynamic languages you can write crappy code faster than when using a typed language.

Once you have quickly created your huge pile of dynamic stuff, you can safely move to another project without having to care about long term maintenance.

This is productivity gain :)

I'm joking, but after having being involved in a project using 'dynamic language', I have been frightened by the amount of unnecessary tests, documentations and conventions you have to deal with if you want to have a working product.
And with the joy of lots of runtime errors that could have been caught at compilation.
Oh, I also forgot to rant about all those hacks and voodoos that meta-programming let you introduce in your code !

So the productivity gain might be a myth for medium/big project over its lifetime.

Answer 3

There is a theoretical view to this problem too: A static type system is essentially a specialized theorem prover which only accepts the program when it can prove the type-correctness of it. All static type systems reject some valid programs because no decidable static type system is powerful enough to prove all possible type-correct programs.

One could argue that those programs that are not provable by a static typechecker are hacks and/or bad style, but if you already got a valid program and the typechecker doesn't accept it, it certainly is impairing your productivity in the short run.

Some cases where you might notice the type-checker getting in the way is with generic containers and co-/contravariance in arguments and return types.

Answer 4

One advantage I've found with most dynamic languages is that they make it easier to write more generic code. It's much easier to write at a higher level of abstraction when you don't have to fight the type system to do so.

You don't have to think about it as much--writing code that does something nontrivial with any object in Java is difficult and probably requires reflection which is basically dynamically typed; with something like JavaScript, writing a function that does something interesting to all objects is second nature. A perfect example would be a function I recently wrote that takes an object and replaces all of its methods with ones that do the same thing but also fire off an event. I have no idea how to approach something like this in Java. However, I'm not sure how much of this is due to the type systems and how much is due to other language differences.

However, I've recently started using Haskell. Haskell lets me write abstract, generic code as easily as any dynamically typed language I've used. My Java/JavaScript example above makes no sense in Haskell because it doesn't have objects, methods, events or even much mutation, but other sorts of generic code are really easy to write.

In fact, Haskell can write some generic code that dynamically typed languages can't; a perfect example is the read function which is basically the opposite of toString. You can get an Int or a Double or whatever type you want (as long as it's in a certain type class). You can even have polymorphic constants, so maxBound can be the maximum Int, Double, Char...etc., all depending on what type it's supposed to be.

My theory now is that the productivity gain from using a dynamic language is always in comparison to languages like Java with less capable, more verbose and less flexible type systems.

However even Haskell's type system has some annoying issues that you would not have in a dynamically typed language. The biggest one I've been annoyed about is the way numbers are handled; for example, you have to mess around with the type system to use length (of a list) as a double, something you would have no issues with without a type system. Another annoying thing I've run into is working with Word8 (an unsigned int type) and functions which expect Int.

So, ultimately, having no type system makes it easier to write generic code without thinking too much and also avoids annoying pitfalls of type systems. You never have to fight the type system in a dynamic language, but you can't rely on it either.

Answer 5

Q: I often heard the claim that dynamically typed languages are more productive than statically typed languages. What are the reasons for this claim?"

This has historical reasons. If you go back a few decades, dynamic languages were indisputably vastly more productive than static languages (while also significantly slower). Perl is clearly much more productive than C if you know both and the task at hand allows either. But over time languages have borrowed a lot from each other, and newer languages are narrowing the gap (both in productivity and performance).

Here are some points to consider:

Garbage collection: Garbage collection is a huge productivity boost. I believe Java was the first mainstream static language with GC. Before this, static basically meant manual memory management. (Note: Here and in the following I'm only considering mainstream languages. Lots of experimental and niche languages exists which will provide counterexamples to any point I make.)

Memory safety: It is a productivity improvement that you don't have to worry about shooting yourself in the foot. Before "managed" static languages like Java, static typically meant direct memory access. Debugging is also a part of productivity, and unsafe memory access can lead to really obscure bugs.

Cumbersome type systems. Before the introduction of parameterized types (like templates or generics) in static languages, the limitations of the static types systems were often a burden. For example in Java you had to explicitly downcast every time you picked an item from a collection. So you got the syntactic overhead of a cast and no type safety. Considering how ubiquitous collections are in programming, this was a major drawback.
Having to declare the type of everything is a lot of redundant typing, but with modern type inference, this can be reduced significantly.

Big standard library. Python was famously advertised as "batteries included" because of the large standard library. This in comparison with C which have a very minimalist standard library. But with platforms like Java and .net, a vast standard library is becoming standard, and newer languages like Scala and F# are inheriting this "for free".

First class data structures. Dynamic languages like Perl and Python have built-in first-class data structures like lists and maps with convenient syntactic shortcuts for common operations. Compared to this, C have no built-in collections except fixed-size arrays.

Closures and lambda syntax - dynamic languages typically have had this from the beginning, but static languages have adopted this, most recently Java.

REPL the ability to quickly test code snippets interactively is a huge boon. But though IDE tools, like the "immediate" window in Visual Studio, static languages can emulated this to some extent.

Advanced tooling - in addition to the above points where static languages are getting closer to the convenience of dynamic languages, modern editors are taking advantage of static analysis in a way that dynamic languages have a hard time matching. For example editors can provide safe automatic refactorings, something that is strictly speaking impossible in a dynamic language.

Bottom line: Historically it was true, but today the answer is less clear cut.

---

Q: So: what is there to say for productivity with dynamic typing that really is an advantage of the type model itself?

It is somewhat hard to separate the dynamic typing model from dynamic languages, but as an example C# have adopted more an more dynamic features over time, even though it as its core is a static language. This is really a proof of benefit of the dynamic type model. Examples:

Reflection Reflection is fundamentally a dynamic typing feature. You inspect object types at runtime rater than compile time. When it was introduced it was kind of frowned upon, but in C# the use of reflection gets more and more ubiquitous, for example ASP.Net MVC uses reflection heavily.

Attributes Attributes are an example of dynamic typing. You can add arbitrary attributes to a class at compile time, and then you inspect at runtime (through reflection) and manipulate objects based on it. Something like MEP is basically an extension framework based on a dynamic type model.

Linq to SQL, EF mv. The various Linq transformers inspect queries as runtime objects and generate sql on the fly. It doesn't get more dynamic than inspecting code at runtime. CodeDom is the other side of the coin, where code can be generated at runtime

Roslyn Roslyn basically implements eval, which was once considered the defining feature of a truly dynamic language.

Dynamic The dynamic-type is the most explicitly dynamic feature in C#, and is advertised at making interaction with external objects and languages simpler and more productive. But it is also used in Asp.net MVC for convenience.

The benefit of all the above features shows that the dynamic model have definite advantages even in a static language with parameterized types, structural types and type inference.

Answer 6

The whole of all modern language features is so big, that static vs. dynamic typing alone doesn't carry much weight.

The rule is, the better your language features, the shorter your code. That's quite simple. Java shows how static typing can go awfully wrong, which gives its opponents much to feed on. Poorly designed language features generally come with a cost, and static typing in Java is firstly a mandatory feature (otherwise most people probably wouldn't even use it) and secondly poorly executed.
This is why in comparison most dynamic languages shine, even though I would argue that PHP doesn't really make your life better in the grand total (at least until recently), because of many other quirks unrelated to type systems.

On the other hand you have a lot of languages with expressive type systems that don't get in your way and that even aren't mandatory. And some of them even allow embedding untyped code, whenever you need to escape the type system.

Personally, I use haXe, which is a language with type inference, both nominal and structural subtyping, optional untyped code, first class function types, algebraic datatypes and (not quite mature but extremely powerful) lexical macros, all the while avoiding arcane syntax. After using haXe for about 3 years now, I have come to a simple conclusion:

Programming becomes far easier, when your language doesn't lock you into religious choices about paradigms but tries to just be a good tool. There's a number of static and dynamic languages and mixed languages, that succeed at that. Some of them are easy to learn, most hard to master.
Their power comes from the way their individual features can be composed to easily create simple solutions to complex problems. This precludes a certain orthogonality that can only be achieved through a delicate balance of inclusion or omission of all language features explored so far. If you tried to add static typing to Ruby, you would cripple it, if you tried to take it away from Haskell, you would crush it. In contrast to that: if you took it away from C, people would hardly notice and if you took it away from Java, some might thank you.

From my personal experience, I can tell you this: I like Ruby. It broadened my horizons and the way I design systems. IMHO it should be used to teach people programming in the first place. It is unobtrusive, powerful, concise, fun. I understand why somebody coming from an orthodox language will enjoy it.
On the long run however, static typing permits to defer work to the static analyzer and with type inference this comes basically at no cost. The result is code that is easier to maintain and often runs faster.

But again, static typing alone can't do a thing. It's a matter of combination. I think somewhere between F#, Scala, Nemerle, OCaml or haXe you can find your very own optimum. But that ultimately depends on you, because the language should allow you to embed your thoughts without effort, instead of forcing you to bend them around it. And after all, nothing yields more productivity gain, than if programming is fun.

Answer 7

Personally, the only reason dynamic typing would help is if you are a really slow typist or you build giant functions/methods/whatevers that are hard to navigate. You also have to get into the whole unit testing issue. Dynamic types require (unless you like writing broken code) vigorous unit tests (To ensure that your dynamic types don't blow up unexpectedly (ie variable is duck mostly, but dcuk accidentally sometimes)). Statics will try much harder to prevent this (And yes, you can make the argument for vigorous unit tests)

Answer 8

I think first of all you need to define "productivity". What does "productivity" mean and include?

If by "more productive" you mean writing less lines of code to implement the same feature, then yes, dynamic-typing programming languages are more "productive" than static-typing languages.

However, if you also consider the time spent on debugging and bug fixing, then dynamic-typing languages may not be that productive, because dynamic-typing languages tend to push the error checking to run-time while, in contrast, static-typing languages can perform some error checking in compile time. As it is commonly accepted that, usually, the later a bug is found, the more expensive to fix that bug. Therefore, dynamic-typing code may result in the generally equal or perhaps even less than the productivity than static-typing code.

Answer 9

The big advantage of dynamic typing is productivity.

Python, Ruby etc. have lots of other productivity boosters besides dynamic typing (default parameters, dictionaries as built in types etc.etc.) the cumulative effect on programmer productivity is impressive.

The penalties in terms of speed (or lack of!) and resource consumption are not as bad as you would expect and in most cases are more than compensated for by development speed and flexibility.

There is a (very old!) paper on the subject here. It is one the the few properly conducted studies on programmer productivity and many of the conclusions are still valid.

What would (probably) be different were the study to be conducted today:-

1. Java JVMs have improved beyond recognition.
2. Modern IDEs would have improved the C++, and Java coders productivity, but, made very little difference to the scripting languages.
3. C# would be included and probably be in the same ball park as Java but slightly better.

So the message is unless performance is a really serious issue dynamic languages will boost your productivity.