comparing statically typed code with dynamically typed code - costs and benefits

Question

Whatever its merits, Adobe's Actionscript 3 presents what may be a unique opportunity to explore the consequences of typed versus untyped languages, because it is pretty much a strict superset of javascript, with all the syntactic benefits/overhead of strict type declarations, declarative casting, etc.

What this makes possible is comparing the same code written both ways, while factoring out essential language syntax.

This causes me to wonder if there is any quantitative evidence about the real benefit of strong typing in particular for error checking during compilation, with respect to error rates, programming productivity, and code volume; or are our perspectives entirely based on speculation and conjecture? Are there any other languages that can be used both ways (not counting old-fashioned VB - not being a highly respected language either way.)

I've spent significant time with both languages, but haven't conclusively decided which way I prefer, and I'd rather not add to the anecdotal evidence - I'm looking for objective information.

Answer 1

In my opinion, strongly typed languages like C# can identify during compile time many overlooked errors that would not be caught in a loose typed language and would, therefore, cause a runtime error later. I don't thinks this is just an speculation, since strict compilation can anticipate issues that would later cause errors during runtime. This can potentially eliminate most of the kind of coding erros that you overlook during the implementation, but that can be easily found and fixed by the compiler.

Answer 2

This is one of the great religious wars in programming, exceeded only perhaps by the conflict between the one True Editor EMACS, and the evil spawn of Satan vi.

Basically, if a program written in a dynamic language is correct, then it can be converted to a statically-typed language and still be correct, and vice versa. The advantage of a truly statically-typed langfuage is that bugs which would show up at run time in a dynamic language can be identified at compile time in a statically-typed language.

What often gets neglected in these situations, though, is that statically typed languages generally have escape hatches (like typecasts), and apparently dynamic languages can use type inference to infer, and treat as statically typed, the types of apparently dynamic expression.

What's really important, under the covers, is the programmer. If the programmer thinks the program right, then it'll be right in either a static or a dynamic language. I'm not aware of any good experimental evidence that either one is more productive or more prone to errors in practice.

Answer 3

The value of static typing seems pretty limited to me if you believe, as I do, that you can't say something is true about a piece of software unless you have a test demonstrating it to be the case. If you accept and practice that, then it's largely irrelevant as to whether bugs are identified at compile time or at test time.

At this point, I'd rather have the more succinct of the two types of languages, which in my experience has been dynamic languages.

The flip side, is that static typing only really helps you if you aren't writing tests. If that's the case, static typing probably isn't enough to ensure the proper functioning of your software.

Answer 4

The OP and felipecsl are confused about the terminology used when talking about typing disciplines.

Static Typing means types are checked during compile-time (whatever compile time means in the language). Dynamic Typing means types are checked as expressions/statements are being executed. Strong Typing means that you cannot subvert (cast) a pointer into an integer, for instance. Weak Typing is the opposite of Strong Typing.

There is no "strict typing", as far as I know.

Now for someone else to answer the actual question ;-)