[ANN] Ducktator - A Duck Type Validator

[Austin Ziegler]

I don't want to continue this discussion in this venue, since the
discussion isn't really about what I meant with the project and such.
Duck typing also seems to be a very loaded (might I say religious) word
for people in the Ruby-community.

What a shameful blog post, Ola. Since you're not interested in
dialogue, I'll join your monologue with a blog post, myself. You're
welcome not to read it or to read it, but you should be ashamed of
your blog post here.

http://www.halostatue.ca/2006/09/20/duck-typing-getting-it-name-calling-and-ola-bini/

-austin

 

[Leslie Viljoen]

What a shameful blog post, Ola. Since you're not interested in
dialogue, I'll join your monologue with a blog post, myself. You're
welcome not to read it or to read it, but you should be ashamed of
your blog post here.

http://www.halostatue.ca/2006/09/20/duck-typing-getting-it-name-calling-and-ola-bini/

Hmm, and just a few hours back I was saying in my journal how friendly
the Ruby community is (http://lesliev.livejournal.com). But then I
didn't think everyone was going to let Ola post-and-run like that, no
siree!

 

[Hal Fulton]

I beg to differ, and according to the pick-axe, this interpretation is
correct. Duck-typing isn't to *trust* your callers. Duck typing is to
check if something quacks like a duck and walks like a duck. Well, me
calling respond_to? checks if the object quacks and walks. What you are
describing isn't a technique, it is the absence of a technique.

Austin is right. If you're checking types, that isn't duck typing.

Hal

 

[Yukihiro Matsumoto]

Hi,

In message "Re: [ANN] Ducktator - A Duck Type Validator"

|Austin is right. If you're checking types, that isn't duck typing.

Although I am not Dave Thomas, I consider it is a _variation_ of duck
typing, if the type describes behavior, not structure nor type name.
Signature validation is approximation of type-by-behavior. As Austin
stated, some doesn't consider it duck typing, I agree. But Keeping
strict definition of duck typing is not that important to justify
strong words in the list (and blogs).

For signature validation, we should note that respond_to? does not
work well for objects with method_missing.

matz.

 

[Devin Mullins]

Austin is right. If you're checking types, that isn't duck typing.
Boy, we really love to argue about semantics, don't we?

What does it matter whether Ducktator "implements duck typing" or
"validates duck types" or "enforces duckly contracts" or "ducktates
method signatures" or "imposes a reducktionist philosophy" or "is just
ducky" or is none of those things?

Is the term "duck typing" overloaded? Yes (see Eric's ruby-talk:215359).
Is it getting more overloaded? Yes. Do newbs come in here with opinions
of the meaning of "duck typing" that differ from yours? Yes. Is that
going to happen more frequently? Probably. Is that going to prevent you
from explaining what you mean by example? No. Do we need separate terms
to describe the different meanings Eric enumerated (and potentially
others)? Well, no, but it'd be helpful. I'll start.

For backwards compatibility with the great majority, "duck typing" will
mean "just calling methods on an object, without doing any validation on
the behavior of that object."* Using respond_to? as a guard -- let's
call that "duck but verify." Using is_a? (and friends) as a guard --
well, "crap" comes to mind, but let's just go with "Class testing."

(On a related note... we didn't ever decide on a replacement for the
term "singleton class," did we? I liked "shadow class," myself. )

And "static" means "not at run-time," no?

Devin
(In short: "What matz said.")

* Though, for me, "duck typing" meant just that: If it looks like a duck
and walks like a duck... Which allows for pretty much anything except
Class testing (sticking a q-tip in the duck's mouth and waiting 2 weeks
for the lab tests to come back). Really, "just calling methods" is more
equivalent to catching something, stripping it, cooking it, taking a
bite, and going "yup, tastes like duck." But hey, peer pressure.

 

[Devin Mullins]

Do we need separate terms
to describe the different meanings Eric enumerated (and potentially
others)? Well, no, but it'd be helpful. I'll start.

Oh, and lastly:

Can we expect everybody in the world to conform to a standard set of
vocabulary, should we come to agree on one? HELL NO!

That is all.

Devin

 

[Eero Saynatkari]

Oh, and lastly:

Can we expect everybody in the world to conform to a standard set of
vocabulary, should we come to agree on one?

You know, it would really help

 

[MonkeeSage]

For backwards compatibility with the great majority, "duck typing" will
mean "just calling methods on an object, without doing any validation on
the behavior of that object."*

The great majority of whom? If you mean rubyists, perhaps you're right
(though I don't know). If you mean programmers, language designers and
computer scientists in general, I think you're wrong.

"Duck typing" is not something that you _do_, and is not even _how you
do something_; it is a method of relating objects -- a sort of "type
system" ("type" in the generic sense not the C-type sense; i.e., "A
type indicates a set of values that have the same sort of generic
meaning or intended purpose (although some types, such as abstract
types and function types, might not get represented as values in the
running computer program)." [1]).

In the terms of category theory: "Instead of focusing merely on the
individual objects (groups) possessing a given structure [...] category
theory emphasizes the morphisms - the structure-preserving processes
- between these objects. [...] A category is itself a type of
mathematical structure, so we can look for 'processes' which preserve
this structure in some sense. Such a process is called a functor. It
associates to every object of one category an object of another
category; and to every morphism in the first category a morphism in the
second." [2]

So "In computer science, duck typing is a term for dynamic typing
typical of some programming languages, such as Smalltalk or Visual
FoxPro, where a variable's value itself determines what the variable
can do. Thus an object having all the methods described in an interface
can be made to implement that interface dynamically at runtime, even if
the object's class does not include the interface in its implements
clause. It also implies that an object is interchangeable with any
other object that implements the same interface, regardless of whether
the objects have a related inheritance hierarchy." [3]

The python glossary defines the expression similarly: "Pythonic
programming style that determines an object's type by inspection of its
method or attribute signature rather than by explicit relationship to
some type object ("If it looks like a duck and quacks like a duck, it
must be a duck.") By emphasizing interfaces rather than specific types,
well-designed code improves its flexibility by allowing polymorphic
substitution. Duck-typing avoids tests using type() or isinstance().
Instead, it typically employs hasattr() tests or [Easier to ask for
forgiveness than permission] programming" [4] Note also that python
calls the method of programming which you call "duck typing" -- "just
calling methods on an object, without doing any validation on the
behavior of that object" -- "Easier to ask for forgiveness than
permission"

Structural type systems, as found in dialects of ML and other
languages, are very similar to duck typing. "In structural typing, two
objects or terms are considered to have compatible types if the types
have identical structure." [5] This "structure" is often referred to as
the "shape" or "signature" of the object / type.

Now I don't know if Dave Thomas used the expression "duck typing"
differently than others generally do, leading to it having a different
nuance in the ruby community; or if perhaps the community didn't
understand Mr. Thomas; or some combination of the two (or, as a third
alternative, the community doesn't generally have that notion of "duck
typing"). But generally speaking "duck typing" does not require or even
imply any specific programming approach (including the approach where
one simply expects / trusts that one object will act like / has the
same (or pragmatically similar) signature as another). If it did, then
(in many cases) when you write begin...rescue, you'd be violating "duck
typing", because you're no longer trusting the object, but are imposing
a condition on it -- you're just doing it "after the fact", so to
speak: try it -> failed -> do something else. This is no different in
concept from ask about it -> failed -> do something else, it's just a
different implementation.

So, in colloquial terms, I see no reason why "ask if it walks like a
duck before you believe its a duck" should be a violation of "duck
typing" any more than "expect it to walk like a duck but don't believe
its a duck if it doesn't".

Ps. I also agree with Matz. I see no reason for zealotry. If I'm wrong,
that's OK; I've been wrong plenty of times before and will be wrong
again. No need to get upset over it.

[1] http://en.wikipedia.org/wiki/Type_system
[2] http://en.wikipedia.org/wiki/Category_theory
[3] http://en.wikipedia.org/wiki/Duck_typing
[4] http://docs.python.org/tut/node18.html#l2h-46
[5] http://en.wikipedia.org/wiki/Structural_type_system

Regards,
Jordan

 

[Hal Fulton]

[snippage]

Overall I don't disagree with you.

Now I don't know if Dave Thomas used the expression "duck typing"
differently than others generally do, leading to it having a different
nuance in the ruby community; or if perhaps the community didn't
understand Mr. Thomas; or some combination of the two (or, as a third
alternative, the community doesn't generally have that notion of "duck
typing").

One thing I'm wondering is: Is there any evidence that this term
originated *other than* with Dave Thomas?

Certainly it's known outside the Ruby community now, but didn't the
term originate *within* the community?

Not that it matters really. AFAIK Dave himself doesn't claim to have
coined the term. And I take it for granted that the concept is older
than the term.

So, in colloquial terms, I see no reason why "ask if it walks like a
duck before you believe its a duck" should be a violation of "duck
typing" any more than "expect it to walk like a duck but don't believe
its a duck if it doesn't".

I *think* that most people (me, anyway) perceive that checking type
is antithetical to the spirit of duck typing.

I'm not adamant about it. And I do perform this kind of checking
sometimes (gasp!).


Cheers,
Hal

 

[Devin Mullins]

I trust everything that Wikipedia says.

(Well, I paraphrased that a bit...)

You, there's a way of thinking about the phrase "duck typing" that'll
help explain that it's really a description of a programming strategy.*
Intepret "duck" as a verb. When you use "duck typing," as a programmer,
you "duck" the programming language's definition of "typing." (Class, in
Ruby's case) Wait, that sounds familiar... did I read that somewhere?

Just a thought.

Devin
(I was kidding, Jordan. Just messing wit j00. I lack knowledge of
category theory.)

* Scanning over chapter 23 of the PickAxe seems to confirm that that was
the intention -- pages 370-1 use the phrases "duck typing philosophy"
and "this style of laissez-faire programming," though, granted, the book
isn't consistent. Hey, the phrase is out there. It doesn't seem to have
a canonical definition. It's an ad hoc term. Treat it as such, I say.

 

[MonkeeSage]

One thing I'm wondering is: Is there any evidence that this term
originated *other than* with Dave Thomas?

Certainly it's known outside the Ruby community now, but didn't the
term originate *within* the community?

Not that it matters really. AFAIK Dave himself doesn't claim to have
coined the term. And I take it for granted that the concept is older
than the term.

From everything I can gather Mr. Thomas at least popularized the term

if not coined it. I just meant that I didn't know if he used the term
differently from the way it has now become generalized and applied to
other languages or theories of language design. I just found this,
however, which is rather interesting [1].

I'm not adamant about it. And I do perform this kind of checking
sometimes (gasp!).

What!? You actually do that? Are you some kind of communist or
something? Stop oppressing your objects and just leave them be free to
be who they want to be!! Heh. ;P

[1] http://wiki.rubygarden.org/Ruby/page/show/DuckTyping

========

(Well, I paraphrased that a bit...)

LOL! Well I did quote WP alot, didn't I. It was just easier that trying
to 'splain all that stuff myself (and I have a tendency to be
ambiguous, if you haven't noticed already, heh).

(I was kidding, Jordan. Just messing wit j00. I lack knowledge of
category theory.)

No worries, I caught that you were just kidding. We's c00, mang.

* Scanning over chapter 23 of the PickAxe seems to confirm that that was
the intention -- pages 370-1 use the phrases "duck typing philosophy"
and "this style of laissez-faire programming," though, granted, the book
isn't consistent. Hey, the phrase is out there. It doesn't seem to have
a canonical definition. It's an ad hoc term. Treat it as such, I say.

Interesting. So, judging by the link I posted above in reply to Hal,
and this reference, it seems that sometimes Mr. Thomas uses the word in
different ways (or as a qualifier that nuances it differently).

Tim Bates touched on the topic in a mailing list post from 2004: "How
to duck type? - the psychology of static typing in Ruby" [2] He
considers the object signature validation approach (which he labels as
(3)) to be compatible with duck typing, but not the "Zen" of it (which
he labels as (4)), which is just to use the object.

David Black also has some interesting comments in this RCR [3].

[2] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511
[3] http://www.rcrchive.net/rcr/show/318

I personally don't really care how one uses the term, but I just think
that one valid use is the way myself and Ola were using it. Of course,
I'm not biased toward the definition I use -- this is a purely
objective observation!

Cheers to you and Hal,
Jordan

 

[Robert Klemme]

Oh, and lastly:

Can we expect everybody in the world to conform to a standard set of
vocabulary, should we come to agree on one? HELL NO!

Devin, I don't want to stress this but you may be underestimating the
value of clear terms a bit. IMHO we should at least /try/ to get a
common understanding of some core concepts so we talk past each other as
little as possible. So, yes I think these discussions are necessary
from time to time. Sometimes the line between persistence and zealotry
is blurred. And unfortunately sometimes these discussions then take
such an unfriendly turn as this thread did.

Kind regards

robert

 

[Simen Edvardsen]

And "static" means "not at run-time," no?

Haskell is a statically typed programming language. Hugs is a Haskell
interpreter. Is the language Hugs interprets not statically typed,
because the type checking is performed at runtime?

Static typing, I think, is about having type checking as a separate
(conceptually, not necessarily implementation-wise) phase from the
phase that actually performs the program's function, but lets not
start a fight over that, too.

 

[Gene Tani]

You know, it would really help

remember the eigenclass / metaclass / singleton / virtual / adhoc /
whatever class discussion?

 

[MonkeeSage]

For posterity, I just want to say that I love all you guys (i.e., all
my fellow rubyists). I think of us like a big family. Even though we
may have some scuffles from time to time, at the end of the day, blood
is thicker than water. The ruby community is one of the best I've ever
come across, and I don't want newbies to get the impression that we're
all fractured and at each other's throats all day long. I don't think
that is true at all. So I just wanted to say explicitly that all of you
are awsome (whether we agree or not)! In the words of Bob Marley, "one
love"!

</endSappyTransmission>

Regards,
Jordan

 

[Ola Bini]

Inspired by Jordan's sappiness, I would like to offer a public apology
for those who felt themselves slighted in anyway by what I have said in
this discussion, or in my blog post.

The blog entry was not an attack at the people who disagreed with me,
and if someone interpreted it in that way, I am sorry.

The point I was aiming at, is that this discussion about duck typing
seem to exhibit various interpretations of the concept, and everyone was
ready to defend their own versions of it, but there isn't an easy way to
say who was wrong or who right, since the concept is a philosophy more
than a practice or a technique.

I am truly sorry I even used the word duck typing for my project, no
matter if it has anything to do with duck typing or not.

The Ruby community is wonderful, and I didn't write with the intent of
trolling or driving a wedge in it.

--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.

 

[Austin Ziegler]

Inspired by Jordan's sappiness, I would like to offer a public apology
for those who felt themselves slighted in anyway by what I have said
in this discussion, or in my blog post.

Apology accepted. I have been a little harsh in my response to your
post, so I apologize for the harshness involved. I'd actually like to
chat with you off-list, if you're amenable to that.

-austin

 

[Ola Bini]

Apology accepted. I have been a little harsh in my response to your
post, so I apologize for the harshness involved. I'd actually like to
chat with you off-list, if you're amenable to that.

-austin

Good, *shake hands*

Sure thing, as long as it isn't about duck typing. =)

--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.

 

[Robert Klemme]

First of all: great that you all found a way back together - this does
not happen often in forum / newsgroup discussions - which exactly
supports what Jordan said about our community!

Inspired by Jordan's sappiness, I would like to offer a public apology
for those who felt themselves slighted in anyway by what I have said in
this discussion, or in my blog post.

I didn't feel hurt in any way but accept your apology anyway (just in
case...)

The point I was aiming at, is that this discussion about duck typing
seem to exhibit various interpretations of the concept, and everyone was
ready to defend their own versions of it, but there isn't an easy way to
say who was wrong or who right, since the concept is a philosophy more
than a practice or a technique.

I had a different perception of the discussion: actually I think there
were at least several individuals who agreed on an interpretation.
Maybe you could say that there were distinct groups that shared a common
understanding each.

And, yes, of course /I/ was right. It's that easy to say... ;-)))

Kind regards

robert


PS: Ducktator is a great name nevertheless. I like puns.

 

[Gregory Seidman]

} >>The problem with "just use it", is that you will have no control over
} >>error handling in this case.
} >
} >This is demonstrably untrue. Duck typing is not about validation. It's
} >about trusting your callers to do the right thing -- and then doing
} >the right thing when they don't.
}
} To extend Austin's point a little: In ruby, it really has to be this
} way. What if an object responds to a message by way of method_missing?
} There's no easy way to validate that.

Actually, it is the developer's responsibility to override respond_to? when
overriding method_missing. To do one and not the other is just sloppy.

} vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
--Greg