SOFTWARE ENGINEERING blog & .lessons_learned
manuel aldana
Manuel Aldana

January 9th, 2011 · 7 Comments

Static typed programming/languages won’t die!

In recent years dynamic typed languages like Ruby, Groovy, JavaScript or Python rightly gained more popularity. Some even said they will soon replace their static typed counterparts. Though I am a big fan of dynamic typed and intepreted languages (for smaller tools/tasks they make life so much easier) my current bet is that the language-future it is not a question of either/or but a gain of diversity of your toolset. Static typed languages just have this big diverse plus when it comes to maintainability of big codebases.

Overview of differences

Because there still is some confusion about dynamic vs. static typing here a short overview of my perception:

  1. Dynamic typed programming: The types or variables are bound during runtime. This happens if you use languages which have dynamic typing in their core design (PHP, Ruby, Python). Be aware that you can still do dynamic typing with languages focusing more on static typing (like C# or Java): Simply have a look at the reflection APIs… Further more type saftey is deferred to runtime, if a programmer introduces typing errors they will pop up during runtime (e.g. ClassCastException, MethodNotFoundException, TypeError).
  2. Static typed programming: The types are resolved/bound during compile time. For this check to be possible your code needs to have typing information (e.g. when defining a variable or method signature). If you have obvious type errors in your code the compilation result will catch it and inform you.

Pros dynamic typing

If designed correctly into the language, dynamic typing offers a lot of advantages:

  • Code is much more compact. Small tools and scripts are a charm to write and some nice syntactic sugar constructs are possible. Programmers need less time to understand and extend code. Further more the proportion of functionality vs. lines-of-code is greater, you need to produce less code to solve a problem. Smaller codebases are a plus for maintenance.
  • Sometimes dynamic typing is a necessity of solving a problem (e.g. the calculated return value is dependant on the parameter’s type, which can differ for every caller).
  • Development feedback cycle tends to be shorter. Most languages offering dynamic typing are intepreted and a simple ‘Save file’ will do. In most cases you instantly will see the effect. For bigger server applications less restarts of the server are necessary.

Pros static typing: Maintainability

Above I mentioned compactness of code as a maintenance plus for dynamic typing. Still, on the same topic static typing scores significantly.

Analyzation of codebases

Typing information bloats code but also serves documentation. In many cases explicit typing helps a lot in reasoning the code’s semantics. Also the IDE can help to easily jump throughout the codebase. It doesn’t have to reason or guess but can directly guide you to the target code. Explicit typing information also does help tools like Structure101 or JDepend to automatically show you relationships, which can point to design or layering flaws.

Feedback of errors

You get faster feedback when you did a typing related coding-error, e.g. wrongly related a function/method or did a typo. The compliation phase does this for granted. Some argue that you anyway should do cover anything by automated tests and therefore can instantly catch typing related programming errors. This theoretically is true but in practice doesn’t hold, I’ve never seen convincing test suites which execute every code-path instantly uncovering such errors. Often you get such errors later by accident, in testing phase or worse during production. Compile time type safety is nothing to be neglected…

Safe refactorings/tooling

It is the “nature” of dynamic typing that you can’t find out typing just looking at the structure of the code. The opposite is true for static typing, therefore you can create tools for safe and automated refactorings (e.g. Rename method/function, Add/Remove parameters, general restructuring of classes/modules). If many refactorings wouldn’t be automated I would lose a lot(!) of time. Being able to refactor codebases in an efficient sensible time is a must have for me. The greater the codebase the greater the cost for unsupported automated/unsafe refactorings. Some people again argue that 100% test-coverage safety-net would suffice, for my point of view see above ;)

I purposely discarded the old performance comparison. It states that compiled binary-code is faster as interpreted code. It may have been true in older times, but nowadays, also with all the JIT compiling features, I haven’t seen convincing benchmarks that static typed languages binaries are better in performance in general. This doesn’t imply that you won’t hit scaling problems which are indeed bound to a language (see also podcast about facebook getting problems with PHP at some point)!


Dynamic typed languages are great but for bigger codebases I still would go for languages like Java or C# (haven’t tried out yet, but Scala seems to be a new alternative here). For very specific modules solving highly generic/dynamic problems you still can code in the “right” language. Modern runtime environments (like JVM or CLR) give you possibility to deploy common-libraries/APIs, which are written in dynamic typed language.

If you have case studies or other resources investigating dynamic vs. static typing and overall productivity or providing different opinions please comment.

Tags: Software Engineering · Software Maintenance

7 responses

  • 1 Static typed programming/languages won’t die! // Jan 9, 2011 at 9:06 pm

    [...] static typed counterparts. Though I am a big fan of dynamic typed and intepreted languages (for… [full post] manuel aldana Manuel Aldana software engineeringsoftware maintenancelanguagesmaintenance [...]

  • 2 ted stockwell // Jan 10, 2011 at 5:37 pm

    My bet is that more languages will become ‘tiered’. That is, the core language will be dynamic but will allow its language elements to be annotated with information used for static analysis. For instance, functions can be annotated with a signature that denoted the number and types of arguments that the function will accept. Pre-conditions, post-conditions, invariants, and concurrent properties could be denoted via annotations. Compilers will turn into ‘analysis engines’ that can perform static analysis using information in annotations.

  • 3 Rogerio // Jan 11, 2011 at 2:55 pm

    I disagree with the stated “pros” of dynamic typing:
    1) “Code is much more compact”: not true, as can be seen by comparing code written in a statically typed language with good type inference, such as C# or Scala.
    2) “Sometimes dynamic typing is a necessity”: I am sure all such cases can also be handled with a statically typed language, by using the appropriate mechanisms (java.lang.Object, generics, type information available at runtime, and so on).
    3) “Development feedback cycle tends to be shorter”: not necessarily true; static compilation time is hardly noticeable with modern IDEs; certain tools provide quick and transparent recompilations (JRebel, GWT in development mode, etc.)

  • 4 Paul W. Homer // Jan 12, 2011 at 4:57 pm

    Long ago I was working in a dynamic typing language which was really helping in keeping the code small and readable. Still, I hit one small part of the system that really needed static typing. For that one piece, I ended up implementing static-typing on top (a hash for each variable, that had a value and a type). It sounds ugly, but it really made the code much simpler and way easier to read (which results in way less bugs and way less development time).

    Lately I’ve been working in a mostly statically type language, but having experienced the joy of dynamic typing, for the core of the system I implemented some classes that allow me to work with the variables dynamically.

    Some problems are better handled dynamically, some statically. Most languages allow some way of implementing one within the other, but some day it would be nice for a new language to include both (equally balanced).

    One property of static typing that you didn’t mention is that it makes it way easier to use brute force thus allowing more people to write code (but also exponentially increasing the technical debt. and overall likelihood of failure).


  • 5 Guguscat // Jan 13, 2011 at 2:51 pm

    “For this check to be possible your code needs to have typing information (e.g. when defining a variable or method signature).”
    That’s not true, in ML you don’t need to declare variables.

    “Small tools and scripts are a charm to write and some nice syntactic sugar constructs are possible.”
    It maybe has a little to do with dynamic typing but I don’t see why this couldn’t exist in a static typed language.

    “Sometimes dynamic typing is a necessity of solving a problem (e.g. the calculated return value is dependant on the parameter’s type, which can differ for every caller).”
    That’s not true, in C++ for example you can override functions or methods.

    “I haven’t seen convincing benchmarks that static typed languages binaries are better in performance in general.”
    Well one thing you do at compile time you don’t have to do it at runtime so static must be much faster. But that is not the only part of the language design which has side effect on performances so benchmarks don’t make sense in this context I guess.

    I’m surprised that you don’t talk about polymorphism, templates, interfaces…

    Otherwise you just answered a question I was thinking of for a week, thank you.

    And nice article.

  • 6 Jonathan Nieto // Jan 19, 2011 at 6:56 pm


    Dynamic languages are a charm to write because they don’t have all the extra static typing stuff like declare variables. It is about getting the job done very good and fast. And that´s the reason why the iterations with dynamic languages are shorter than with static languages.

    Interesting article!


  • 7 manuel aldana // Jan 19, 2011 at 8:10 pm

    thanks for all your input!

    1) You’re right that type inference and language features can save code, but still you have to code “more” (e.g. parameters). Thinking of same programming skills of a developer I would say, that you need to write less code with Groovy as with C# for the same functionality.
    2) You can use reflection to be more flexible, but from the code samples I have seen so far it looks “less” straightforward (e.g. casting around).
    3) Thanks for the JRebel hint. You’re right, maybe it is not related to “dynamic”, but dynamic typed languages often cover the area of more feedback driven scripting languages (e.g. PHP file simple safe, refresh page, instant feedback)

    My statement “Being dynamic is a necessity to solve a problem” was not accurate. I more meant to say that dynamic languages are just a better tool for some kinds of problems. I didn’t get into details about the OO features, because I wanted to focus more on the maintenance point of view of dynamic vs. static language. Regarding similar argument of ‘Rogerio’ see my answer 3) from above.

You must log in to post a comment.