How about a virtual machine facility that outputs what the types of variables are at runtime, combined with tools that can collate data from many runs and apply consistent types back to the original source code?
That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis, and if you double check everything with static analysis, you might as well only do the static analysis in the first place. (Static analysis won't always give you an answer, but it won't ever give you a wrong answer.) I am reminded of the folks who optimized .kkrieger, which is a 95 kB first-person shooter. Se…
You are right from a theoretical standpoint, but I'm not so sure this fits with how web applications are known to run and the patterns development usually follows.
Developers who shove an object of one type in an instance or temporary variable one time, and a different one another time are usually doing something bad, even in dynamic environments -- unless there is a specific interface involved. Just because "duck typing" is fast, doesn't mean that it has to be loose.
The point, actually, is to discover where types are being misused as much as to discover what the types are.
> The lesson is: don't let tools change code semantics based only on black-box testing.
I'm also advocating this. However, it seems like you're mainly familiar with dealing with types in statically typed environments. In dynamic environments, the developers still need to know the types. Often, there are hard and fast rules only enforced by convention. This is indeed a source of errors, but by and large, programmers are very good at managing this. In other words, very often, the programmers will know. I see environments like Dart as a way to eliminate such conventions, but still enable very fast prototyping in the beginning. (Ultimately, static types are better for maintenance.)