<p>What are the advantages and limitations of dynamic type languages compared to static type languages?</p>

<p><strong>See also</strong>: <a href="https://stackoverflow.com/questions/42934/whats-with-the-love-of-dynamic-languages">whats with the love of dynamic languages</a> (a far more argumentative thread...)</p>

The ability of the interpreter to deduce type and type conversions makes development time faster, but it also can provoke runtime failures which you just cannot get in a statically typed language where you catch them at compile time. But which one's better (or even if that's always true) is hotly discussed in the community these days (and since a long time).
A good take on the issue is from
Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages
by Erik Meijer and Peter Drayton at Microsoft:
Advocates of static typing argue that
  the advantages of static typing
  include earlier detection of
  programming mistakes (e.g. preventing
  adding an integer to a boolean),
  better documentation in the form of
  type signatures (e.g. incorporating
  number and types of arguments when
  resolving names), more opportunities
  for compiler optimizations (e.g.
  replacing virtual calls by direct
  calls when the exact type of the
  receiver is known statically),
  increased runtime efficiency (e.g. not
  all values need to carry a dynamic
  type), and a better design time
  developer experience (e.g. knowing the
  type of the receiver, the IDE can
  present a drop-down menu of all
  applicable members). Static typing
  fanatics try to make us believe that
  “well-typed programs cannot go wrong”.
  While this certainly sounds
  impressive, it is a rather vacuous
  statement. Static type checking is a
  compile-time abstraction of the
  runtime behavior of your program, and
  hence it is necessarily only partially
  sound and incomplete. This means that
  programs can still go wrong because of
  properties that are not tracked by the
  type-checker, and that there are
  programs that while they cannot go
  wrong cannot be type-checked. The
  impulse for making static typing less
  partial and more complete causes type
  systems to become overly complicated
  and exotic as witnessed by concepts
  such as “phantom types” [11] and
  “wobbly types” [10]. This is like
  trying to run a marathon with a ball
  and chain tied to your leg and
  triumphantly shouting that you nearly
  made it even though you bailed out
  after the first mile.
Advocates of dynamically typed
  languages argue that static typing is
  too rigid, and that the softness of
  dynamically languages makes them
  ideally suited for prototyping systems
  with changing or unknown requirements,
  or that interact with other systems
  that change unpredictably (data and
  application integration). Of course,
  dynamically typed languages are
  indispensable for dealing with truly
  dynamic program behavior such as
  method interception, dynamic loading,
  mobile code, runtime reflection, etc.
  In the mother of all papers on
  scripting [16], John Ousterhout argues
  that statically typed systems
  programming languages make code less
  reusable, more verbose, not more safe,
  and less expressive than dynamically
  typed scripting languages. This
  argument is parroted literally by many
  proponents of dynamically typed
  scripting languages. We argue that
  this is a fallacy and falls into the
  same category as arguing that the
  essence of declarative programming is
  eliminating assignment. Or as John
  Hughes says [8], it is a logical
  impossibility to make a language more
  powerful by omitting features.
  Defending the fact that delaying all
  type-checking to runtime is a good
  thing, is playing ostrich tactics with
  the fact that errors should be caught
  as early in the development process as
  possible.