Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations The Unreasonable Effectiveness of Dynamic Typing for Practical Programs

The Unreasonable Effectiveness of Dynamic Typing for Practical Programs



Robert Smallshire explores the disconnect between the dire outcomes predicted by advocates of static typing versus the near absence of type errors in real world systems built with dynamic languages.


Robert Smallshire is a founding director of Sixty North, a software product and consulting business in Norway . He has worked in architecture and technical management roles for several companies providing tools in the energy sector for dealing with the masses of information flowing from today’s digital oil fields. Robert is a regular speaker at conferences, meetups and corporate software events.

About the conference

“BUILD STUFF” Conference is a Software Development Conference created for developers, team leaders, software architects and technical project managers. Our goal is to bring world class speakers to share innovations, latest developments, new trends and directions in software development world to the Baltics.

Recorded at:

Apr 26, 2014

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Are there advanced type systems?

    by Arturo Hernandez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think it is clear that there is a cost associated with writing statically typed programs. And in many cases the cost is too high to justify. I believe academics are aware of this situation. Can there be a type system that is cheap enough and also caches more bugs, so it is not so hard to justify? There are better type systems out there, in both senses, than your regular Java or C++. I think it is unlikely than a new language developed to extract developer experience from the equation, will have the kind of type system available on some of today's languages.

    The second problem is that the productivity when first writing a program, does not necessarily represent the full cost of a system. When the original programmers of a dynamically typed system have left then the cost equation may change.

  • Static vs dynamic typing

    by Serge Slepov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    First of all, I want to kill the cameraman for trying to keep the lecturer in focus while he was sipping water and blowing his nose and not showing any of the slides.

    As to the point of the lecture, I didn't see it. We were promised to be shown scientific/exprimental proof of dynamic languages making programmers happier and more productive. What the experiments have shown though, is that there is some percentage (1-2%) of type errors amongst all the issues logged for dynamic language projects. That's the errors that could have been avoided by using a statically typed language.

    I spent 50 minutes waiting to hear what the tradeoffs were of static typing and at the end of the video an argument was presented where Robert was pointing at a slide with some C++ code and saying it took him days to write it. I didn't see the slide (fire that cameraman!) but I am guessing it was showing a case of having to specify an iterator type explicitly. C# or F# don't have this problem while being statically typed (with support for dynamic typing too, if you prefer).

    Still not convinced.

  • What about Type Inference?

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Languages such Haskell, ML family (including F#), etc. have strong type inference.

    Have been coding F# for over 3 years. It definitely has the feel of a dynamically typed language but gives you all the support of a statically type one.

  • Hmm I use Python and CoffeeScript

    by aoeu256 .,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There some type errors that don't show up as AttributeError, TypeError, or NameError like if you do this.
    class MyLongClass: # Actually happened to me : (
    def lol(a):
    return 1
    # 500 lines later
    def lol(a):
    return 5

    or this: = 5
    myclass.lal = 3 # mistyped lol

    or this:
    lol = 3
    oll = 24 # i meant to redefine lol

    if you use strings for "enums" instead of class namespaces you can also mis-spell it, but if you use classes:
    enemyType = EnemyType.Witch

    These are all "Write Errors", rather than "Read Errors". If you assume they are equally as likely as "Read Errors" then it bumps it up to 5%-10%. Still not good enough for Static Typing : ).

    Fixes for write errors:
    <-- Maybe use ":" for defining things, and "=" for redefining things, and disallow class and def to redefining things.
    lol: 3
    lal = 5

    Why don't Dynamic languages have "interactive coercion & typing, and spelling check" where when you write 5 + "5" it asks you whether to fix it(modifying the file, and changing the function) or to error out. You can also automatically fix most errors by saying if you are adding an int and string it will ask you if you want to make both a str or int. If you get a NameError, KeyError, or AttributeError it retries the line of code by spelling checking it over the local variables/Attributes. If you get a AttributeError(Duck Typing error), TypeError because of wrong argument order, all you have to automatically fix the error is to retry calling with a different argument order and see if the error goes away (and you can do this all the way to the top of the stack).
    I heard LISP has Edit & Continue, but does Clojure and other languages also have it? I wrote a Python Edit & Continue decorator for individual functions.

  • A waste of time

    by tim frian,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think both dynamic and static languages can have their place. Unfortunately most of the popular static languages are "weak" (in the colloquial sense): verbose, restrictive, etc.
    The speaker cloaks his disdain and lack of understanding of static type systems and theory behind some pseudo-scientific experiments and lame analogies.

    Don’t waste your time watching this. Instead, I recommend presentations by Daniel Spiewak or Martin Odersky on the subject.

  • An Unreasonable Failure of Domain Modeling

    by Jared Hester,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The speaker did not define his types properly in the F# example ~30:00
    His types should have been :

    [<Measure>] type kg
    [<Measure>] type m
    [<Measure>] type s
    [<Measure>] type N = kg m/s^2
    [<Measure>] type J = N * m
    [<Measure>] type Radian
    [<Measure>] type Torque = J / Radian

    Had he done this the compiler would have rejected his attempts to add torque to energy.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p