Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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. :-)

share|improve this question
6  
Would you expect the "static duo" to be faster or more productive than the "dynamic duo"? –  Steve314 Nov 29 '11 at 11:17
    
What do you mean with duo? Anyway: I can think of a couple of reasons that static typing is more productive than dynamic typing: more compiler checks for errors, code completion, more information on the intent of the programmer in the code. That's why I am asking about the converse. –  hstoerr Nov 29 '11 at 13:26
3  
It was a joke with a point. The "dynamic duo" is Batman and Robin. They wouldn't strike nearly as much fear into the Gotham City criminal underworld if they were called the "static duo". Since developers are people, superficial things can make a difference irrespective of what the terms mean. –  Steve314 Nov 29 '11 at 13:43
    
My first question is whether I know what I'm doing or not. If I do, then I can design things ahead of time and static typing makes sense. If I don't, then I'm going to have to change a lot of things on the fly and dynamic typing will be easier. Common Lisp is the best language I've found when I don't know what I'm doing. (Caveat: I've only scratched Haskell, and hence have no good feel for inferred static typing.) –  David Thornley Nov 29 '11 at 14:32
1  
I totally agree with John Skeet msmvps.com/blogs/jon_skeet/archive/2009/11/17/… –  user Feb 22 '12 at 22:10
show 1 more comment

8 Answers

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.

share|improve this answer
6  
+1, very detailed answer. The value of the point "Better compile time checking" can't be stressed enough. –  Emmad Kareem Nov 29 '11 at 8:57
6  
Along with Type Inference, there's also Haskell-style overloading, C++ templates, generics and maybe some other language features which provide some of the advantages of Duck-typing within a static-typing framework - as long as the object provides the needed interface (it "quacks like a duck") you can use it, almost irrespective of that objects nominal type. The "almost" is because some approaches require some kind of "this type quacks like the relevant kind of duck" declaration - e.g. the "class" declaration in Haskell. –  Steve314 Nov 29 '11 at 11:25
13  
I have to disagree strongly with your assertion that "shorter code... is quicker to read and maintain." There's an intermediate step, understanding the code. I've had to maintain other people's code in both Delphi and JavaScript, and the Delphi code is far easier to understand because it is more verbose. And most especially because the Delphi code has type declarations and the JavaScript does not. When dealing with anything more complex than primitives, type declarations make it trivial to see what your variables are and what they can do, which is essential knowledge for maintenance work. –  Mason Wheeler Nov 29 '11 at 17:24
3  
Why is dynamic typed languages better for REPL? I have used static languages like SML and Scala in REPL and it have always worked good. –  Jonas Nov 30 '11 at 15:33
3  
I beg to disagree with most of the reasons given here. Take Haskell, which has probably there strictest type system out there. It has a REPL (actually at least two), it features very powerful polymorphism by doing pattern-matching on constructors and it is as concise as one can hope for - much more than Javascript or Python. So I guess some of the reason you mention are accidental rather than inherent to loosely typed languages. –  Andrea Feb 17 '12 at 11:09
show 10 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
Yes, my experience is the same. A 100 lines perl script is ok, and without such great tools we'd been lost. But a 100k line perl project will most probably be a nightmare. –  Ingo Feb 17 '12 at 11:41
add comment

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)

share|improve this answer
add comment

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.

share|improve this answer
1  
Being insulated from implementation details is great, right up to the point when you need to fix a low-level bug that's the root cause of a high-level problem, or find a way to optimize slow-performing code, or any number of expert-level tasks that require access to the implementation details. Anytime a language sets a baseline abstraction that you cannot get underneath, it's limiting your ability to create truly good software. –  Mason Wheeler Nov 29 '11 at 17:29
3  
-1, automatic memory management isn't just a dynamic language feature. Ask any Java, C#, Lisp, Clojure (etc., etc., ad nauseam) developer. LoC also depends on framework/language features. Convention over Configuration that many dynamic language frameworks (e.g. RoR) provide are also in the box in the .NET framework. –  Mike Brown Nov 29 '11 at 18:23
    
@Mason: I agree with you. However, IMO dynamic languages aren't typically used in places where those concerns are a factor. Dynamic languages are definitely not the best solution for all problems, and you won't always be the most productive using one. I think as a rule of thumb, however, being insulated from such implementation details for the types of problems dynamic languages are typically used for is a productivity enhancement. –  Bryan Oakley Nov 29 '11 at 18:44
2  
@bryan he's disagreeing because many if not all of the things you've listed are also available in modern static languages. They are irrelevant. You might as well compare dynam –  MarkJ Nov 29 '11 at 19:07
2  
@BryanOakley my downvote was because a lot of the reasons for productivity gains you cited are already present in many statically typed languages. There are definitely benefits to using dynamic languages just as there are some benefits that static typing provide over dynamic. What you cited, unfortunately are not unique to dynamic typing (other than REPL). –  Mike Brown Nov 30 '11 at 14:29
show 3 more comments

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.

share|improve this answer
1  
My unclarity is what exactly it is that dynamic typing does to boost your productivity. The paper is interesting, however it is about a very small program, and I'm not sure how this carries over to the many thousands lines of code in most programs. –  hstoerr Nov 29 '11 at 17:06
3  
That study only uses C, C++ and Java as examples of static languages, and then attempts to apply the conclusions found to traditional programming languages in general. All three languages share the same basic syntax, with the same inherent, prductivity-decreasing flaws, making the comparison invalid. It's not that static languages are unproductive, it's that the C family is unproductive. Had they included a Pascal dialect in their tests, they'd most likely have reached some different conclusions. –  Mason Wheeler Nov 29 '11 at 18:16
    
@mason -- there are very few actual objective studies in this field. This is one of the few real studies with actual numbers etc. The "sample" program is not trivial! It combines elements of dictionary handling, complex algorithms and large data volumes. The high percentage of failed and crashing attempts confirm the non-trivial nature of the task. –  James Anderson Nov 30 '11 at 1:32
    
@Hstoerr. If you look at the numbers productivity is inversely related to the number of lines of code, dynamic languages use less code for a given task its as simple as that. The number of bugs is directly related to the number of lines of code so smaller programs require less debugging. However note the caveat in my posting: static languages benefit greatly from IDEs whereas dynamic languages don't benefit much at all. –  James Anderson Nov 30 '11 at 1:36
    
@James Anderson: Code length isn't the only measure of difficulty of writing or debugging. Try a short Intercal program, or maybe even APL. Besides, dynamic programs will require a bit more testing (not much if done right), and that may make up for the shorter program. (C++ has had default parameters for a long time, and as of the latest standard has std::unordered_map<>, so those features are hardly unique to dynamic languages.) –  David Thornley Nov 30 '11 at 15:15
show 3 more comments

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.

share|improve this answer
10  
Conversely if you have erroneously entered an incorrect program the compiler tells you immediately and highlights the bad line. this improves your productivity, when compared to noticing a failed test run and debugging to find the error. –  MarkJ Nov 29 '11 at 19:04
1  
generic containers and explicit co-/contravariance are meant to "get in your way" if you do it wrong. what's the benefit of compiling code which will fail at runtime? –  M.Stramm Aug 31 '12 at 7:49
    
Usually job is considered 0 % done until it runs all the tests successfully. Only then your progress can be considered more than nothing. With that in mind, I don't think it's worth measuring your productivity on something that hasn't been finished yet. –  Pius Mar 26 '13 at 15:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.