I guess the next question is, how much real work have you done in a dynamically-typed lanugage?
Mostly cleanup of other people's work. Most of my work is in systems or embedded level, and as you pointed out below, that's not something you can generally throw 10x the hardware at. I'm most fluent in the C-syntax languages (C, C++, Java, PHP which is... well, PHP), although I've hit a good chunk of the procedural languages over the years (Python, ruby, lisp being the big names).
Is sendmail.cf considered turing complete? :)
it's a serious PITA to hunt down every caller and see what types they can possibly call the broken method with.
Why would you want to? This is why I ask what work you've done -- I can't recall ever, in all the Ruby or Javascript work I've done, seeing a method called with the wrong type, or wondering what type a method should be (or is being) called with.
And I was doing crazier things than you seem to be suggesting -- in JavaScript, I can quite literally pull a method out of one object and insert it into another object, on the fly. Yet somehow, proper design meant I never had type issues.
It's probably because most of my work on dynamically typed languages are when someone DIDN'T properly design, and I get to fix it. Or more commonly, someone did design it properly, but they went on to bigger and better things, and someone else made some changes that seemed to work, until another piece somewhere else came online and.... The normal bitrot you see on projects.
Runtime typechecking is more accurately "crashtime type checking",
Or, if you've done your job right, test-time checking. Static type checking could be seen as a subset of unit testing.
"testing" gets pre-empted by "deadlines". You don't get called in to panic-bugfix a system when they implemented "testing" properly.
I see more usage of dynamic typing in webwork than anywhere else.
I think that has to do with two things -- the need to get to market first, and the choice of hardware platform. If you wrote a new video game in Ruby, and your competitors used C++, your framerate would suck relative to theirs, and you can't exactly tell your users to buy ten times the hardware to make up for it. But if you wrote a new webapp in Ruby, and your competitors used C++, you'll hit the market before they have a working prototype, and you can buy ten times the hardware if you need to.
That honestly depends on a lot of things, I wouldn't write a 3d rendering engine in ruby, but it might be the right call for the slower-paced scripting of game events. Right tool for the job and all that. Back to dynamic typing - what's a specific thing that you can do (in a well-designed system) with a dynamic type that you can't do with polymorphism or templating? I've always found that testing was simpler when you could outright reject so many bad usages of methods at compile-time.