Owen,
This really quite splendid. And timely. Just as I would was thinking that the two kinds of conversations that have dominated FRIAM over the last few weeks were going to permanently bifurcate, you bring them together with Abducktion and duck-typing. Your exposition was pretty user-friendly, but still I am not completely sure I understand. Is duck-type roughly equivalent to announcing for all future generations of a program that anything anyone calls a duck is going to have duckwalk, duckquack, ducktastesgoodincassoulet as properties. Or is it more than that. Is there any working that backward in a program. Let's say some programmer in the future, working with your program creates a variable, goose, that also waddles, quacks (sort of) and tastesgoodincassoulets. Is there any way for the program to output to the programmer, "don't you mean 'duck?". Nick Nick From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Owen Densmore Sent: Monday, April 22, 2013 12:37 PM To: The Friday Morning Applied Complexity Coffee Group Cc: mikeby...@earthlink.net Subject: Re: [FRIAM] Abducktion On Mon, Apr 22, 2013 at 11:18 AM, Nicholas Thompson <nickthomp...@earthlink.net> 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 <http://en.wikipedia.org/wiki/Computer_programming> computer programming with <http://en.wikipedia.org/wiki/Object-oriented_programming> object-oriented <http://en.wikipedia.org/wiki/Programming_language> programming languages, duck typing is a style of <http://en.wikipedia.org/wiki/Type_system#Dynamic_typing> dynamic typing in which an object's <http://en.wikipedia.org/wiki/Method_(computer_programming)> methods and propertiesdetermine the valid semantics, rather than its <http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)> inheritance from a particular class or implementation of a specific interface. The name of the concept refers to the <http://en.wikipedia.org/wiki/Duck_test> duck test, attributed to <http://en.wikipedia.org/wiki/James_Whitcomb_Riley> James Whitcomb Riley (see <http://en.wikipedia.org/wiki/Duck_typing#History> 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. <http://en.wikipedia.org/wiki/Duck_typing#cite_note-1> [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
