From: ara.t.howard@...
Date: 2006-07-26T02:10:06+09:00
Subject: Re: I'll have the duck!

On Wed, 26 Jul 2006, Phil Tomson wrote:

> Actually, David is doing something very important: he's making sure that we
> name things correctly and that we not change our terminology.  You've used
> the term 'duck-typing' in a way that differs from it's traditional use in
> tthe Ruby community.  David is calling you on that and basically saying that
> either you need to come up with a different terminology to describe what
> you're doing or we'll have to come up with a different name for what
> currently has been considered 'duck-typing'.
>
> It's been said that naming is one of the most important acts of programming.
> What we call things, objects and even concepts is important.  If you take a
> name (duck typing) and apply it to a concept that's different than what is
> the accepted association in the community, then in some way your 'theft'
> diminishes our ability to communicate within our discourse community.   Some
> would even say it diminishes the whole concept of 'duck typing'.  Look up
> Wittgenstein on wikipedia.

hi phil-

on the one hand, i agree with you.  on the other hand though, it's important
to realize that no language/terminology is static.  one of my pet peeves are
people who cling too tightly to rules or accepted meanings since, if we were
all like that, no new words or meanings would every spring into existence.
remember that someone - a single person - must alway utter a word or imply a
meaning for the very first time.  considering that the concept of 'duck
typing' is quite new and very, very far from having an exact meaning (except
perhaps to a small group of rubyists), and considering that authorship of code
bestows a certain latitude with respect to naming things (it's my opinion that
writing code is by far the most important activity of any rubyist and doing so
give certain rights and privledges over those that do not release code
publicly and tom releases tons of code), i'm willing to at least consider that
our notion of duck typing may be able to be improved upon.  in partucular, i
feel that inclusion of the word 'typing' in 'duck typing' is totally broken
with respect to the way the purists, like david, are using it:  their argument
basically goes that you cannot code 'duck typing' because one cannot know
apriori, using any current methodology available in ruby, whether or not a
method call or set of method calls with work out how you require them to.
this is flawed in at least two ways:

   1) the same can be said for any language - you cannot know, in c for
   example, if a method call on a pointer will core dump or not with absolute
   certainty.  this is largely moot since, in the real world, we can do all
   sorts of things to know, with a finite certainty, that a certain method call
   will success.  'respond_to?' comes to mind.

   2) the term 'duck typing' as it's currently used, with no dis-respect to
   dave thomas, is flawed because the current usage does not, in fact, suggest
   any sort of 'type' or 'equivalence class'!  what i mean by that is, unless
   you concede that some sort of apriori checking can be used to determine
   'duckness' you cannot also use the work 'typing'.  why?  because the current
   thinking is circular:  people will say that this is not 'duck typing'

     obj.message if obj.respond_to? 'message'

   because, only sending 'message' to 'obj' can really make that determination.
   well, if that is true, then it's also true that we can never say that

     same_duck_type = [a,b].each{|obj| obj.send 'msg' rescue break false}

   since that contains a race condition: we could conceivably send 'a' a 'msg',
   then send 'b' a 'msg', only to come back to 'a' and find it no longer
   responds to 'msg'.  what i'm saying is that if one accepts that the only way
   to employ/think-of/use 'duck typing' then one also accepts that it is NOT a
   'typing' system since each and every object belongs to it's own equivalence
   class and that's the same as no typing system.  now, that may well be the
   case, but if it is then it's the current terminology that needs fixed and
   not toms since present reasoning about 'duck typing' does indeed imply an
   infinite number of one member sets and it, therefore, not very useful.

   i understand the notion of just writing code and 'seeing if objects can act
   in that role' as being a philisophical contruct - nevertheless i also think
   that it's certainly understood and implied in the term 'type' that certain
   keys fit in certain locks and that unless a test can be made to atomicaly
   test for this condition the phrase 'type' is in error.

kind regards.

-a
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama