I'm not sure what the best place for this is; sorry.  The following are
my views:
	What we know as 'duck typing' is not really a programming paradigm,
but a set practices as Mr. Black says--merely the "yin" end of the
type-checking continuum.  I first learned about it, although of course
not by that name, from studying C++ templates, where also the
prevailing wisdom is that you shouldn't assume anything more about your
library's client's code than is absolutely necessary.  The 'duck
typing' moniker that marks it as a novelty is most useful against the
background of static languages, where type-checking helps prevent
runtime errors.  For Ruby, where *every* error is runtime, duck typing
is the raw form of its behavior, and should be recognized as quickly as
possible, because it isn't always good.  At its utmost, duck typing is
the total absence of validation.  You are saying that nothing about
your client's program is worth trying to predict, that 'if it works, it
works,' and if it doesn't, he'll know because it just blew up.
	Hmm.  I see where type-checking came from.  As far as Ruby best
practices go, I think 'duck typing' just means using respond_to?() more
than kind_of?() and include?().  If you really wanted to, dumping class
use entirely and turning Ruby into a prototype-based language wouldn't
be too hard: you'd use Object::new() only, define only singleton
methods, and extend objects with clone(); and if you wanted to
delegate, you'd keep an array of references of "parent" objects,
Perl-style.
	Personally, I feel that Ruby needs more, rather than less, type
safety, to balance its natural inclination otherwise and because no
amount of 'duck typing' disaffirms that erroneous behavior is best
caught as soon as possible.  But I don't think anyone would advocate a
return to rigid inheritance checking, which realization the deprecation
of type() notably indicates.