The Case Against Dynamic Typing

The Case Against Dynamic Typing


AN ARGUMENT FOR DYNAMIC TYPING is that by not enforcing the types of a function’s parameters, the function becomes more generalized, and thus more flexible and reusable. I argue that this flexibility versus automatically-verifiable correctness of the system is not a trade-off we need to make.

This post is in part inspired by Why Dynamic Typing Is Useful by Gary Bernhardt. I’ll concede that his post is published 10 years prior, so I’ve had plenty of time to build a counter-argument.

Why Is Dynamic Typing Useful?

To maintain sanity, programmers enforce rigid constraints over the parameters their functions can consume. If my process_many function takes some things, then dagnabbit; things better be an array! How else will I know that I can send array-flavored messages to it?

A core language feature of Ruby is duck typing, where essentially the exact type of an object is disregarded in favour of the more pertinent question: “Object, do you understand the message I’m sending you?”. It’s neat way of doing polymorphism.

It’s easy to take for granted how well this maps to a normal person’s perception of the world. When you learn how to drive a car, your skills aren’t exclusively applicable to a car. Your physical output is just as effective when directed towards a truck or a golf cart.

The Case Against Dynamic Typing. Awesome post by @jezenthomas #ruby #coding #haskell #scala Click To Tweet

A code library author shouldn’t need to anticipate every type of parameter that might be thrown at a function, and a programmer who comes to consume the function will likely be creative enough to use the function in ways the author hadn’t expected. Dynamic typing allows for all of this.

Why Are Dynamic Types Painful?

The correctness of a dynamically-typed system is at the whim of the developer’s discipline and vigilance. And therein lies the rub. If test-cases aren’t accounted for, it’s the programmer’s fault. Same deal if an interface goes out of sync.

Even people who advocate most strongly for dynamic typing program defensively. If dynamic typing filled you with confidence, would you be littering your code with responds_to? or nil??

The code library author relies on writing isolated tests with various kinds of inputs to ensure the robustness of the function. The function’s consumer relies on some sort of JavaDoc-style documentation comment which is likely to go out of sync with the function’s actual signature. Both rely on the rigor of humans.

If your code relies on JavaDoc-style comments, the machine isn’t being used as well as it should. Ideally, a function’s signature should be verifiable at compile time.

What Is The Solution?

A smarter type system.

The argument for dynamic typing doesn’t account for languages that provide type classes. Granted, there aren’t many languages that support type classes — Haskell does, Scala does, and apparently Rust does too. In Haskell for example, you might have a type class named ‘Traversable’, and any data type that can be traversed over would be an instance of the ‘Traversable’ type class.

Code Review Done Right This Is How We Do It

This means that instead of saying “this function takes a list”, and then having to account for the possibility that the consumer might want to pass in a dictionary instead, you would say “this function takes anything that can be traversed over”. That way, you have the flexibility of dynamic types and the sanity of compile-time verifiable function signatures.

If Dynamic Types Are No Good, Why Are They So Popular?

  • JavaScript only provides one type of number (64-bit floating point), though people still do monetary calculations with it. Popularity is seldom a good indicator that something is of good quality.
  • It’s evident that those using dynamic languages in anger are shying away from dynamics despite the supposed flexibility it provides. A few examples which come to mind:
  • Ruby 3 looks to be implementing some type of static/gradual typing system.
    Haskell is increasingly being adopted by the world’s most front-running tech companies.
    TypeScript and Facebook’s Flow type-checker are gaining traction.

This is a repost of this article with the permission of the blogger: Jezen Thomas, a freelance software developer spending most of his time writing software with Ruby and JavaScript.


The makers of DebugMe hope that you like this post and would love it if you follow us on Twitter. We are tweeting about web design, UI/UX  and development related topics multiple times a day. DebugMe is an issue tracking, project management and screenshot tool for every website project. Get visual feedback right away and solve front-end problems faster. Try it now for free.

SHARE ON:Share on LinkedInTweet about this on TwitterShare on Facebook

4 thoughts on “The Case Against Dynamic Typing

  1. Not really about the post but rather, the blog in general: there is no margin on the body text, so for me right now the text is sitting against the edge of my screen, which is quite detrimental to the reading experience.

  2. One area that is a crucial to me about dynamic typing, and, in particular, duck typing, is the inability to renamed an interface member easily. I am constantly futzing with interface method names in Java, which is easy (in a good IDE, at least) because you can change a method name and the IDEA automatically replaces it in other places in the project.
    But with duck typing, you are stuck finding all instances and attempting to do the rename. That makes it just enough of a pain that people tend to not do it, even when they only have two implementations.

  3. Ruby 3’s gradual typing will look more to you like Duck Typing than it does like static typing. Matz had a keynote on it at RubyConf. But it’s a toe dipped into the water of *some* static typing, not a wholesale switch-over. It’s basically a static analysis tool which can be run with some runtime profiling/usage data to detect obvious usage errors. There are already static analysis tools for Ruby (e.g. Rubocop) but it’s still basically a dynamic language.

Leave a Reply

Your email address will not be published. Required fields are marked *