Using the Duck-Typing method in scientific context [closed]

Question

Some programming languages use Duck Typing to determine types of Objects, based on their methods and properties and not their declared type.

Simplified, it goes down to the premise

"If it walks like a duck and it quacks like a duck, then it must be a duck"

However it remains unknown to me, whether this Method can or can not be validly used in a scientific context.

If not, what are the concerns against using it, considering a well-defined set of properties to define a Duck.

Answer 1

Duck typing in philosophy is variously called structuralism or functionalism, depending on the context. The idea that duck typing is the best way to articulate our commitment to scientifically-postulated entities, in particular, is most closely related to what philosophers call structural realism: the thesis that we should "epistemically commit ourselves only to the mathematical or structural content of our theories" (from the SEP entry linked above).

Answer 2

You always run the risk of it being a goose!

runs

I would actually argue that nearly all of science uses this mentality. Most famously, it shows up in wave/particle duality. We assume light is a wave, because it looks like a wave and behaves like a wave. Or we assume light is a particle, because it looks like a particle and behaves like a particle. And, for the most part, this distinction serves us well. We treat light as a particle or wave, based on its behaviors. At least, this works until quantum mechanical bits cause us to start questioning the nature of light because it's starting to look funny and act a bit odd. When we consider duality, we have to recognize that light isn't a wave and isn't a particle. It's light. And sometimes it acts like a wave, sometimes it acts like a particle, and sometimes it just acts really honking weird.

Then we look at it and say... well... it looks like a superposable wave function, and it acts like a superposable wave function...

Answer 3

tl;dr– Science is weakly typed rather than either duck-typed or strongly typed.

Points:

1. Duck-typing isn't about type-determination, but rather ignoring types entirely.

2. You probably meant to ask about "weak typing", where things can be considered ducks if we're able to frame them as such.

3. Yes, science is weakly typed.

---

1: Duck-typing isn't about type-determination, but rather ignoring types entirely.

Duck typing isn't about determining an object's type, but rather about not caring. As far as duck-typing is concerned, all objects are of the same, implicit type; any variance in behavior is up to the object itself.

For example, in C#:

class DuckObject
{
    private Dictionary<string, Action<object>> MethodDictionary { get; set; }

    public void Call(
                string methodName
            ,   object methodArgument
        )
    {
        this.MethodDictionary[methodName](methodArgument);
    }
}

Then instead of writing x.Quack();, we'd write

x.Call(
            "Quack"           //  Name of the called method
        ,   new object[] { }  //  Arguments object, which contains no subordinate arguments in this case.
    );

.

In other words, x is duck enough for the purpose of .Quack()'ing like a duck if it can .Quack().

---

2: You probably meant to ask about "weak typing", where things can be considered ducks if we're able to frame them as such.

In weakly typed languages, x is a duck if we can frame it as one.

For example, in C#:

((Duck)x).Quack();

Weak-typing is stronger than duck-typing because it's not enough for something to .Quack() like a duck to be a duck; instead, we must be able to coerce something into being a duck.

Weak-typing is weaker than strong-typing because it doesn't require something to be a duck so long as it can be regarded as a duck.

---

3: Yes, science is weakly typed.

Scientific models work when we can make them work. For example, cows can be spherical when such a description is adequate.

Which is to say that, yes, a duck is a duck when such a description is adequate. Even if it's actually an advanced robot pretending to be a duck, it's still a duck if it's close enough, but it isn't if it isn't.

In practice, scientists, engineers, etc., tend to work with models that they know to be imperfect.

• This isn't a duck-typing logic because it's not enough for something to merely have some shared quality with its abstract representation.

• This is a weak-typing logic in that requires something to be framable as its abstract representation.

• This isn't a strong-typing logic in that there's no need for something to be its abstract representation.

Answer 4

Duck typing is useful when you have a messy set of things which have various properties which make it hard to organise them into clear nonoverlapping categories, just like real life.

I'm sure there are lots of examples of duck typing in the physical sciences, but one that came to my mind is the particle/wave nature of light. Duck typing says that we don't have to put light into only one box, but can treat it as a particle when that suits us, and treat it as a wave when that suits us. It also doesn't preclude us from finding a third category that can better handle both sets of behaviours in a unified explanation.

Answer 5

Well, the short answer is that duck typing is a programming concept, so it doesn't make sense to ask whether or not duck typing is usable outside of programming. It's a lot like how sautéing is a cooking concept, and so it doesn't make sense to ask whether or not sautéing is usable outside of cooking.

That said, the idea behind duck typing is:

Do not attempt to determine in advance whether or not an object is usable. Instead, simply attempt to use it.

(In particular, idea behind duck typing is not "if it walks like a duck and it quacks like a duck, then it must be a duck.")

This idea is certainly very common outside of programming. For example, when I get into my car in the morning, how do I determine whether or not my car is drivable? I don't; instead, simply attempt to drive it. When I want to turn on the light in a room, how do I determine whether or not the light switch is functional? I don't; instead, I simply flip it. When I want to turn on the TV, how do I determine whether or not the remote control I have is the correct one? I don't; instead, I simply try to use it to turn on the TV.

The negation of this idea is also very common outside of programming. For example, when I want to determine whether or not a given liquid is drinkable, I do not simply drink it; instead, I first look at its packaging to see whether or not it's a beverage. When I want to determine whether or not an airplane is airworthy, I do not simply attempt to fly it; instead, I first check it for damage and proper functioning. When I want to cross the road, I do not simply cross it; instead, I first check whether or not any cars are approaching.

And, of course, the idea of "simply attempt to use it" is certainly common in scientific practice, too. If a scientist needs to heat something over a flame, they don't test the flame to determine whether or not it's hot; they simply use it. If an electrical engineer wants to connect two components together using a wire, they don't test the wire to determine whether or not it conducts electricity; they simply use it. You could probably think of a thousand examples.

Answer 6

Duck-typing reminds me the most of societal contracts, by which I mean behaviours expected of us from society through convention rather than law.

A lot of software development is creating contracts between actors. When we say a function's parameter is of a certain type, we are creating a contract between the function and its callers which is enforced by the compiler. Break the contract, and the code will fail to compile.^[1]

Unlike systems that use roles or interfaces, there is no enforcer when it comes to duck-typing. It is an unspecified convention to which the actors must adhere for the code to function.^[2]

This is akin to societal norms like not coughing in someone's face. There is no law that tells someone not to do this, yet there are consequences to someone doing it.

This doesn't really answer your question, but I hope you find this interesting. I'm a software developer that stumbled upon your question.

---

1. Compiling code is part of the process of creating an application, as opposed to executing it.
2. Unspecified in the code. The documentation may well specify, just like books on manners may prescribe socially acceptable behaviours.