From: dblack@...
Date: 2006-07-26T03:16:20+09:00
Subject: Re: I'll have the duck!

On Wed, 26 Jul 2006, ara.t.howard@noaa.gov wrote:

> 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.

Let's not get too global about this.  Disagreeing about a Ruby module
name does not mean thinking that language, in general, is static, etc.
etc.  I can prove my post-structuralist credentials to you any time
you feel you need evidence that I'm aware of the rudiments of
post-Saussurian lingustics :-)  Meanwhile, let's get back to the topic
at hand.

> 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:

That's not exactly what I've been saying; rather, my point has been
that I think that the concept of "duck typing" is in a category that
isn't a category of things that can be written in code.  If it *is*
something that can be written in code, then we need a new term for the
thing we used to call "duck typing", which is a programming practice
that does not depend on or have any special relationship to any
particular modules or methods.  (But let's drop it; I've obviously
failed to put across that point.)

>  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 think one of the interesting things about Ruby is that it's "ducks
all the way down".  respond_to? is just a method, etc.  (This should
appeal to your Derridian side :-)  As with language in general, one
just goes ahead and uses it, based on pragmatic considerations and
experience.  Language itself is, as you've pointed out, unfixed -- but
that doesn't mean that we just stare helplessly at each other, nor
that you look at your own first paragraph and despair of what the
words mean.  Similarly, the mise-en-abyme of Ruby messages doesn't
mean that one can't do anything.

>  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.

I've always felt that the Achilles' heel of the duck typing metaphor
was the "then it *is a* duck" -- which implies that there's a Duck
thing out there which something else can "be".  I don't think it's
supposed to be an airtight analytical tool for Ruby's design, though,
just (as Dave says) a way of thinking about programming in Ruby.


David

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

-- 
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black     => RUBY FOR RAILS (reviewed on
                                     Slashdot, 7/12/2006!)
http://dablog.rubypal.com        => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net              => me