Comments on: A small example of the hidden dangers of dynamically typed programming languages.

By: Jon Harrop

Jon Harrop — Thu, 21 Feb 2008 11:02:21 +0000

Yes! You are describing the incredibly-important difference between proof and testing. Static type checking proves the correctness of programs within specified limits whereas unit tests try a few values and check for specified errors.

However, I think it is more important to stress that dynamically typed languages require vastly more unit testing to achieve the same level of robustness. Specifically, the amount of code required to perform suitable unit testing in a project written in a dynamically-typed language is 50-200% the size of the code base itself whereas the code required for testing a statically-typed project is only 1-2%. In other words, although some production-quality dynamically typed languages can almost achieve the brevity of the best statically typed languages, they are still vastly more expensive because your programmers must spend at least half as much time again manually making up for the lack of static checking if you want your product to work reliably.

Objectively, note how dynamically typed languages have only obtained significant use in areas of industry where reliability is comparatively unimportant, e.g. web programming.

By: Jack

Jack — Tue, 19 Feb 2008 23:48:42 +0000

I think you should also be concerned about cars. It turns out that you can easily drive them off cliffs! Since cars are so clearly dangerous, you should never use them. I hope that you will use your blog to alert others of this hidden danger.

By: Ray Tayek

Ray Tayek — Tue, 19 Feb 2008 05:49:31 +0000

more food for thought: http://cdsmith.twu.net/types.html

By: James H.

James H. — Mon, 18 Feb 2008 22:12:47 +0000

This is (among the reasons) why I use haXe. It’s a language that combines inferred static types with dynamic typing. So I can benefit from dynamic typing’s flexibility, but don’t have to pull out that poor “unit test everything” excuse, because the cases where I really, really want to use dynamics are relatively slim. Not that unit tests are bad, but they’re more work. The compiler can offload some of that work. It saves me time and effort.

By: Groovy is clearly not a statically typed language.

Groovy is clearly not a statically typed language. — Mon, 18 Feb 2008 17:59:15 +0000

[…] Pain and Glory from the Trenches of the IT World « A small example of the hidden dangers of dynamically typed programming languages. […]

By: leppie

leppie — Mon, 18 Feb 2008 14:45:50 +0000

I dont use either Python or Ruby, but from the output it’s quite easy to see ARGV and argv returns different lengths.

By: Mark Murphy

Mark Murphy — Mon, 18 Feb 2008 11:33:04 +0000

Arguably, what you’re describing is not a problem with dynamic typing, but a problem of doing unit testing without a code coverage tool that can handle branch and loop coverage. In your example, the issue is that there was no unit test for ARGV.length>3 (to use the Ruby syntax), which a good coverage tool will point out. In other words, given a solid coverage analyzer, unit tests will try even these edge and corner cases…including those where even static typing would have gotten it wrong. After all, I’ve written enough code in statically-typed languages to know that typing doesn’t eliminate all bugs, that unit tests are needed in statically-typed languages, and that code coverage is important there too. In fact, I wrote a book on the subject.

My broader concern is an overall theme of these style of posts — where one compares Language X to Language Y (or, in your case, Language Feature A vs. Language Feature B). The “vibe”, whether implicit or explicit, is “I found an issue with Language X, therefore Language X is the spawn of Satan and those who use or promote Language X should be stoned…and not in a good way, m’kay?”. The issue is probably real, the problems the issues causes are probably real, but those problems need to be balanced against the problems with the alternative(s). Most important, how one weighs one set of problems vs. another set of problems is intrinsically personal, based on experience and situation, and so it is disingenuous for somebody to cast blanket aspersions on Language X or Language Feature A. Pointing out the issue is fine, saying that *you* won’t use Language X or Language Feature A is fine, but that’s as far as you can take it. In this post, you were fine; in your preceding post on this subject, you said “Clearly, static typing is the only sensible, and the most efficient, route to take.”, which is stepping outside the bounds of what anybody is qualified to state.

By: Mike

Mike — Mon, 18 Feb 2008 09:21:04 +0000

That was a long way of saying, “dynamically typed languages are dynamically typed”. That they don’t catch type errors until runtime is a given.

The whole point of unit tests is to make sure there is no rarely-executed code.

By: Cale Gibbard

Cale Gibbard — Mon, 18 Feb 2008 04:42:37 +0000

Just thought I’d point out that your blog has munched on the Haskell code a bit.