Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

4 Examples of a Dynamic Language Kicking a Static Language’s Ass!

dynamic languages rock

There has been a lot of discussions about the superiority of statically typed programming languages in recent years. Many great minds have contributed arguments for both sides of the discussion/argument. I’m not a programming language designer myself, so I won’t go over the finer points and benefits of a powerful type system. Be sure to check out the links above though as they are a really interesting read.

I also won’t try to convince you that a type system catches more bugs than some tests. Nor that tests are inevitable anyway, making a type system is kinda obsolete. Almost all developers share strong opinions on these topics, so let your steam out in the comments or throw 140 chars to @shelajev.


It is believed that a static type system will help you more than it will get in your way. While my favourite JVM language is Clojure, I feel to be at my most productive in Java. Mostly because of the experience I have in writing it. I really want to show you some of the situations where a dynamic language is preferable over a static one and try to make you actually think about the choice more carefully, the next time you encounter a problem that requires whipping up some code quickly.

Here’s a lemma to start us off: a compiler is an entity that has an opinion on your code’s correctness. It can reject your efforts by specifying whether a program is valid or not. A runtime is also an entity that might have an opinion on the topic. The major difference is when the type checking happens.

dynamic languages godfather

In type theory, types are logical propositions. The programs that work with those types are proofs of those propositions. That’s the main takeaway I learnt from a type theory course. Without going into detail about what that actually means, I just want to look at a certain aspect of this fact. Programs are equivalent to theorem proofs. Proving things tends to be difficult and time consuming. There’s a simpler way of having no type information and not having to prove to a computer that your program works.

So here are 4 situations where you prefer a dynamic language or runtime.

0. You’re writing glue code.

This one is straightforward, right? When you create a library, or some component of the system that will be consumed on a higher level, you want a strong static type system, you want all the help the compiler can offer you and your consumer to make things right. If you’re not investing time into proving how things are transformed with the type system, you’re going to document it in much more detail or handhold every consumer until they understand what they are dealing with and how to use your creation well.

Now, imagine a typical web application. The main parts are specified a long time ago: clients will connect, pass HTTP parameters, there’ll be a URL, behind everything will be a database with the data that your code has to crunch and render. Everything is taken care of by the libraries, you just need to specify the business logic.

Here’s the minimal example of a Spring Boot application with Groovy. It is trivial, but so are the more complex web systems too: they just pass the data through.

If your code is passing the data to and from components and is not consumed itself through the language level API by anyone else then it doesn’t have to have the extensive type information. There’s no one to benefit from this meta data. Dynamic languages rock for such code. You don’t work with, against or around the compiler, the runtime understands you perfectly.

1. You like REPL

Imagine you have a REPL in a running application, sounds wonderful, doesn’t it? You can create snippets of code and execute them on the fly inside a running system, you debug like the old gods and have the the most fun you’re allowed to with a computer.

The thing is, your code is in the runtime already, the structures are loaded into memory and whatever you do you do at runtime. So the runtime gives you more detail about whatever it infers about the code: does it return anything, does the universe blow up if it is run.

Here’s an example from an article about Java 9 Shell:

Since the runtime knows the val is a double, do we really want to specify the type for that variable at the time of punching the text in? It’s a minor inconvenience, and it might save us if the Math.sqrt call returns something else instead of a double. But we’re at runtime and the type system that checks at runtime is dynamic. There’s no point in paying anything for the compile time type checks when you’re patching your code on the fly.

2. You want to be productive

This one might be a stretch, as you can be a productive developer in any language without any thoughts to type systems. However, you do want to make sure you have the easiest time iterating on the code level.

Here’s a blogpost on Google Developers medium that emphasises this issue. If your code stack allows quicker iteration of: “think about a change to make–implement the change–verify that it is useful” cycle you’d be able to change the code quicker and in the long run be more productive than in other technologies.

Try JRebel

Naturally, at ZeroTurnaround we’ve been saying the same thing for ages. You want to apply the code changes to a running process without any delays, instantly — that’s how you become productive.

If you want to do that on the JVM, here you go: JRebel – a javaagent that reloads your code changes instantly in the running JVM process. You don’t need to restart anything and the latest version of the code magically gets loaded into the correct place, ready to be executed.

In order to do so, JRebel enhances the way the JVM loads classes, calls methods and refers to the fields in the objects. It adds a level of indirection to increase the flexibility.

Do you want another example? Look at sbt compilation times. It doesn’t come from the fact that Scala is dynamically typed, on the contrary, Scala’s type system is comprehensive and complex, and to verify all the claims in the typed code the compiler has to work harder. Next time you wait for your project to compile think how cool it would be not to waste that time.  

compiling xkcd comics

Well, if you also happen to work in Java, check out JRebel, I cannot imagine you being disappointed with that.

3. You want to be semi-dynamic.

To conclude this unusual, for me, blogpost, I want to say that both static and dynamic typing are great tools if you know the use-cases for each. The modern, now gradual typing, might even be more to your taste, giving you the ability to use static type checks on demand and avoid them when you don’t feel like doing it. Both areas of research in programming languages are paramount: without the efficient runtimes for dynamic languages we’d never have JavaScript… kidding, we’d never have the luxury of gradual typing systems or languages like Python and Ruby, and Groovy, and Clojure. Without strong type systems we’d never learned to design the libraries for the mass consumption rather that a few elite hackers. But the backend that crunches it must allow for the dynamicity, it has to be dynamic first, making use of the additional hints of the types, if the code provides them.


Surely I realise that whatever is written in the internets, you won’t be persuaded to change your opinion on such a fundamental topic. And it certainly won’t convince you to change your habits, but it might make you aware that there’s always the right tool for the job.

So, if you’re on the dynamic typing side of the things: here are some arguments for your next discussion. If you’re not – then remember that sometimes you do want to have a dynamic system even if you’re less comfortable with it in the beginning of your journey.

Tell me your experience is the comments below or find and chat with us on Twitter: @ZeroTurnaround.


Read next:

  • Rt

    I like this implication that you can’t have a REPL in a static language. Makes it easy to know we should ignore the rest of what you say on language design.

  • Pavel Grigorenko

    How did you imply that? Even the example is taken from the post on Java 9..

  • Would you mind using a darker font. It’s difficult to read a rather light grey (is it grey?) on a rather dark ivory (or whatever the background is).

    Thanks.

  • Oleg Šelajev

    Noted! We have a slight blog redesign in mind already. This is a fairly frequent sentiment, let’s see what can we do with it. Thanks for reaching out!

  • Jon Gilbert

    On my computer the font looks amazing. But then again I’m reading on a MacBook Pro with retina display.

  • Jon Gilbert

    Great article. The main advantage of static typing from a productivity standpoint to me has been not how it gives the compiler a heads up about potential issue, but that it gives *the IDE* a heads up. For example XCode tells me when I made a mistake as soon as I typed the line of code. In this way, modern IDEs’ constantly improving bug-checking algorithms are almost like a sort of runtime; this line is getting very blurry.

    As computers gain more and more in power, these IDEs will basically be able to constantly recompile in the background. The bug-checker, analyzer, and compiler will become the same thing.

    However I think with a dynamic language using proper code documentation you can have your cake and eat it too. For example on my last big PHP project, using PHPDoc with PHPStorm, the IDE would use PHPDoc’s declared parameter types to warn me when I was doing something that was not type-safe. Yet I got the code cleanliness and human readability of a dynamic language.

    Perhaps someday this “metadata,” as you call it, will be able to be actively inferred and assigned likelihoods dynamically… in a quantum computer, where your code can crash and keep running at the same time :D

  • Nico

    In Elixir there is something similar. Elixir is a dynamically typed language, but if you want you write typespecs and run Dializer for static code analysis.

  • David Leppik

    I’d have to disagree with just about the entire post. I do most of my coding in Scala and TypeScript, with legacy code in Java and JavaScript. Scala is statically typed, while TypeScript an optionally statically typed superset of JavaScript.

    Scala is a good example of a statically typed language which looks just like a dynamically typed language. As mentioned in the article, it’s compiler is incredibly slow, and thus its build language (sbt) is also dog slow. But that isn’t because it’s statically typed; it’s because it has a lot of high-level features (implicit conversions for example) which add work to the compiler.

    JavaScript is dynamically typed, but with fast optimizing compilers, and the first thing those compilers do is type inference. Dynamic typing doesn’t speed up compiling, it adds another step!

    There is one place where static typing gets in your way really fast: when you’re writing something similar to a collections library. In that case you run into all sorts of cases where you have two things that must have compatible types and you need to do runtime type checking. In JVM-based languages at least, generics don’t help, since the type information goes away at runtime. But you still need to convince the compiler that you know what you’re doing. I’ve torn hair out doing this in Java and Scala. Whereas in TypeScript, it’s really easy to turn off type checking. (My particular use case is an OLAP database; the Scala version is closed-source, but the TypeScript version is at https://github.com/dleppik/ozone/ )

  • Tony BenBrahim

    You forgot the part of having to write 3 times the amount of unit tests for dynamic languages. And the lack of good code completion…