[cscheid]

As pointed out in a comment on the original, this is a well-known source of holy wars.

The interesting bit is that this argument is one of the sides of an equivalence. Dig up the old archives of LtU,

http://lambda-the-ultimate.org/classic/lambda-archive.html

and search for the big threads. This direction of the argument (dynamic languages are static languages) was made most forcefully, in my recollection, by Frank Atanassow.

However, the other direction _also_ applies: static languages are dynamic languages. This was first pointed out in LtU, to the best of my memory, by Kevin Millikin, here:

http://lambda-the-ultimate.org/node/100#comment-1197

Someone ought to write up the old days of LtU holy wars somewhere. They taught me more about programming languages than everything I ever read anywhere else.

(edit: minor wording)

[bad_user]

And as in most holly wars, most arguments thrown around are dumb and without consequence to us, the developers that have to work.

Fact: I know of a single statically typed language that could be used for real-world usage and that gets operator-overloading right, and that is Haskell, a language who's authors list contains many PhDs.

Another fact: it is perfectly within reach of a talented sophomore student to implement a dynamically typed language with support for multimethods, which would get operator-overloading right, in the course of a single semester.

And yet another fact: dynamic versus static really is runtime versus compile-time and many languages to which we refer as being "static" or "dynamic" are in fact somewhere in between.

That's because -- real language designers ship.

And it would be perfect if the compiler would tell you all kind of things about your algorithm at compile-time, but you have to draw the line somewhere and start making compromises. And did I mention the halting problem? Yes, that's a problem for compile-time too.