Re: Abducktion

Posted by Owen Densmore on Apr 22, 2013; 6:37pm
URL: http://friam.383.s1.nabble.com/Re-Abducktion-tp7582900p7582909.html

On Mon, Apr 22, 2013 at 11:18 AM, Nicholas Thompson <[hidden email]> wrote:

This also is very interesting.  Peirce typing, as you put it, equals “abduction”.  Is “Duck Typing” a term of art, somewhere?  Or is that your neologism.  I like it. 

 

Actually, from Peirce’s point of view, I perhaps made a mistake with

 

“It's a duck!”  (Some might say I was guilty of a canard.  Heh. Heh.)

 

I should have written, “It’s more probably a duck.”   The point is, channeling my mentor again, that “abducktion (=duck-typing, as you put it) is a probabilistic enterprise.  As we accumulate concordant properties between the white feathered thing in front of us and what we know about ducks, the creature seems more probably to be a duck.  No poke is ever the last poke.  Each poke leads to future pokes.  After “Poke-squawk” works, we might try to see if the creature goes well in a cassoulet, and if the result of that experiment is also, “yes”, then the creature is even more probably a duck. 

 

But I really need to learn more about “duck-typing”. 

 

Nick

In strongly typed languages, you declare what something is at compile time so the compilar can both optimize the translation into machine language, and to catch errors during compilation.  Typically, in Object Oriented parlance, if you declare a variable to be a Duck, and Duck has walk, swim, quack methods (procedures), then declaring a variable duck to be a Duck lets you call duck.quack() for example.

In Duck Typing, your playing a trust game.  I have an undeclared variable, named duck, that happens to have the three Duck methods.  It also has a explode method, but I don't ever call that, so I rely on run time testing suites to determine that, for me it is a duck.

There are endless (and pointless) arguments made as to how "strongly typed" a language is but basically its compile vs run time discovery of errors.

From the font of all knowledge, wikipedia: http://en.wikipedia.org/wiki/Duck_typing

In computer programming with object-oriented programming languages, duck typing is a style of dynamic typing in which an object's methods and propertiesdetermine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface. The name of the concept refers to theduck test, attributed to James Whitcomb Riley (see history below), which may be phrased as follows:

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.^[1]

In duck typing, one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. For example, in a non-duck-typed language, one can create a function that takes an object of type Duck and calls that object's walk and quack methods. In a duck-typed language, the equivalent function would take an object of any type and call that object's walk and quack methods. If the object does not have the methods that are called then the function signals a run-time error. If the object does have the methods, then they are executed no matter the type of the object, evoking the quotation and hence the name of this form of typing.

Duck typing is aided by habitually not testing for the type of arguments in method and function bodies, relying on documentation, clear code and testing to ensure correct use. 

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com