Link Details

A great example for this is strongly typed datasets.

This allows the IDE to give you code completion based on table/column names and is a huge time saver when writing database code.

Compared to the alternative of passing the column name as a string and having to go look at the database schema and make sure you have it right.

You're mixing up static typing and strong typing. Programmers in dynamic languages don't tend to use strings for everything.

You miss the point.
E.g. if you have dataset.x = 11 in statically typed language you'll get an error if field x is a string, but in dynamically typed language you'll get an error ONLY in runtime, so to check this you need to write some unit tests at least (which should be better written anyway :) )

But then again if the language supports boxing/unboxing then the dataset.x=11 might be perfectly valid.

With boxing (in Java/C#) you'll get Object which is not a String to get it working you need implicit casts

If x is a string, why are you writing x=11?

I totally agree!

I tend to agree with Julian on this point. Don't get me wrong, I love dynamic typing and all the benefits which come with it (like duck typing). Most people don't realize how liberating it is to just never worry about type issues. However, in a large scale application, where you need to actually *maintain* your code, static typing is extremely useful. I couldn't imagine writing an IDE in Ruby any more than I could imagine writing a quickie script in Java.

I assume that most programmers of dynamic languages build their projects from smaller parts, rather than making one big codebase. That's probably how they make their code maintainable.

Type inference can make a static typed languages feel very much like a dynamic one - get the best of both worlds! (e.g. F#)