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? 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. 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 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 languages can be more productive, but only if you have good test suites and testing discipline.

Answer 2

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 3

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 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

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 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

The productivity gain isn't in dynamic typing, in and of itself. The productivity gain is all the other things that make a dynamic language dynamic. If you take C and somehow add dynamic typing, you probably won't be any more productive, and if you remove dynamic typing from python your productivity probably won't go down much either.

Where the productivity happens -- if it does -- is due to a cumulative effect. Dynamic languages typically come with hash tables built-in. They have REPLs (read-eval-print loops). They have considerably better string handling functions (when compared to C, anyway). You don't have to (nor get to) allocate memory manually (or free it up). They have nice abstractions over difficult technologies like threading and socket communication. And so on.

Generally speaking, a given problem can be solved in fewer lines of code with a modern dynamic language. And generally speaking, the fewer lines of code one has to write to implement a solution, the more productive they can (but not necessarily will) be.

Finally, I think because most dynamic languages insulate you from some of the mundane details of implementation that computers are good at figuring out, we are free to spend more time thinking about the problem rather than the low level implementation details.

Answer 8

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.