Although it is possible to have a heavy-typed dynamic language, in practice these tend not to be popular. The main reason is that the primary benefit of heavy typing is machine verification of code, AKA "compiler checking". With a dynamic language, such verification will be either difficult or less informative. In order to supply enough info to the checking system, one would have to avoid dynamic techniques, and if you are going to do that, you might as well use a compiler along with a static style. (I've stated this before, but cannot find it.) --top
I am familiar with StrongTyping, WeakTyping, ManifestTyping, ImplicitTyping, TypeInference, SoftTyping, StaticTyping, DynamicTyping, DuckTyping, and so on. Which of these, or what combination of these, is "heavy typing"?
Well, it's a continuous concept and one that I doubt there can ever be a Boolean test for. But in general it is a language and/or base libraries that are designed to rely heavily on type information. Thus, if one wanted to do "light" typing, they'd have to work hard to work around the typing system. For example, operations that don't support implied typing such that one has to explicitly cast/convert parameters in order to use the language base libraries or operations.
Thank you for fuzzifying the mudification. I think I somewhat almost not quite nearly don't entirely understand what you seem to mean.
There's a neat little 'FindPage' link at the bottom of each page, TopMind. You could probably find a better home for this comment... especially a home where people have already contested your claims so it doesn't look like you're starting a new page just to have a fresh, uncontested start at repeating a claim until it becomes true.
In any case, I remain skeptical on two counts. (1) I believe that dynamic properties for a language can be achieved in combination with primarily static typing (possibly some dynamism around pickling) assuming that the language is designed from the ground up to support both properties. As examples, you can look to Haskell and OCaml, each of which support both interpreters and implicit typing. (2) I believe that strongly typed dynamic languages with in-your-face types are already popular, with examples including Ruby, Python, Scala.
I would agree with a weaker claim: achieving benefits associated with heavy typing and dynamic properties in a single language takes greater care than achieving either property alone. There is a stronger claim one could make in the same vein: achieving multiple KeyLanguageFeatures in a single language while still keeping the language implementable takes much greater care and design effort than achieving a strict subset of such features. Further, dynamic language properties (as supported by RealMacros, configurable modularity, higher order typed pickling, ability to upgrade a module during runtime, naked objects, meta-object protocol, etc.) and various benefits associated with "heavy typing" (static type safety, performance guarantees, contracts, various performance optimizations that don't make guarantees, security guarantees, etc.) each broadly cover a fairly wide set of KeyLanguageFeatures.
Achieving both will require much effort... effort that is ongoing in the ComputerScience community at such places as LambdaTheUltimate, ACM, IEEE, Microsoft, and IBM. Myself and hundreds of others are designing, building (often via modification), and testing languages and language extensions to achieve them. But it will be a while before others see these efforts; overcoming momentum of existing languages is extremely difficult, though Scala and Clojure (which has strong immutability and transactions) have both made waves in the business community. As a practitioner, you'll more often see the advances slip into new versions of existing languages languages like C++09 and Perl6.0 and Stackless Python and Iron Ruby.
Are we trying to say that StaticTyping conflicts with DynamicTyping?
Or maybe a more meaningful claim, like that StaticTyping conflicts with InterpretedLanguage implementations?
Assuming the latter... No it doesn't.