4 ms·

Question is, how many real-world cases there are where duck typing is super beneficial. Usually if you need a bunch of differently-typed objects to fulfill the

Question is, how many real-world cases there are where duck typing is super beneficial. Usually if you need a bunch of differently-typed objects to fulfill the same contract, you can just make them implement an interface (said interface can also be documented, etc., it makes the intent very explicit). I do believe there are cases where dynamic typing is genuinely useful, but those make up a very small portion of real-world problems.

mikelevins 11y ago
It's not an either/or situation--or at least it shouldn't be. Static and dynamic type systems are not opposites. They're not sworn enemies. They don't necessarily have to be alternatives; it's reasonable to want both. A couple of years ago I worked for DARPA project that was building a system designed for greatly enhanced security and reliability. It had a novel programming language designed to be able to express a rich set of reliability and security constraints in the type system. It had a rich static type system, but it also had a dynamic type system. Why? Because some important constraints simply can't be analyzed statically. For example, a program could say that it was impossible for a given piece of information to be delivered to an unauthorized receiver. That constraint cannot be analyzed statically because the authorization status of a given agent can change at any time. The type system had to be able to check authorization, so it had to have a dynamic checker (in fact, the system was designed to be able to do dynamic checks in hardware). Maybe this sounds like an esoteric use-case, but is that because nobody wants to be able to express such constraints, or is it because we just don't expect to be able to do so because we haven't had the tools? The project in question is in part meant to make the case that such use-cases should not be esoteric--that one of the reasons that our reliability and security situations are so embarrassing is that we haven't so far taken those considerations seriously enough to develop the tools to deal with them. If we want to get better, maybe we should be thinking about how to integrate both static and dynamic type systems, rather than exalting one and denigrating the other.
nrinaudo 11y ago
I agree that duck typing is rarely critical, you can always work around it when you find you'd like to have it. On the other hand, I disagree with the scenario you describe: if you have multiple types that come from an external, closed-source library, you won't be able to have them extend a new interface. If you're lucky and they've not been marked final, you'll need to wrap them in another type that extends the right interface, then unwrap them... not at all impossible, but a lot of boilerplate. The best solution I know of is type classes, in languages that support them.
- sanderjd 11y ago
  Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.
  - nrinaudo 11y ago
    I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the concept. Is there an other option that I'm not seeing?
    - drewgross 11y ago
      In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.
      - deleted 11y ago
        [deleted]
    - drewgross 11y ago
      In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.
JunkDNA 11y ago
One place where I ran into this was when I was building an ETL framework in Scala. The scenario was that I wanted to be able to move data from one database system to another and not have the end user of the DSL have to care about the types. The use case was essentially that you should be able to show up to an arbitrary database, run a query, and then pump that output somewhere else (e.g. another DB, flat file, transformation function, etc...) I went around in circles and ultimately concluded no amount of type inference or other things in Scala's bag of tricks would let a user of the API avoid the dreaded type cast. I have often seen this situation whenever I have tried to write generic code in a static language that needs to interact with a database.
- nrinaudo 11y ago
  That sounds like a perfect use case for type classes, have you tried that? If so, I'd be interested to know why it failed, if you can find the time.

mikelevins 11y ago

It's not an either/or situation--or at least it shouldn't be. Static and dynamic type systems are not opposites. They're not sworn enemies. They don't necessarily have to be alternatives; it's reasonable to want both. A couple of years ago I worked for DARPA project that was building a system designed for greatly enhanced security and reliability. It had a novel programming language designed to be able to express a rich set of reliability and security constraints in the type system. It had a rich static type system, but it also had a dynamic type system. Why? Because some important constraints simply can't be analyzed statically. For example, a program could say that it was impossible for a given piece of information to be delivered to an unauthorized receiver. That constraint cannot be analyzed statically because the authorization status of a given agent can change at any time. The type system had to be able to check authorization, so it had to have a dynamic checker (in fact, the system was designed to be able to do dynamic checks in hardware). Maybe this sounds like an esoteric use-case, but is that because nobody wants to be able to express such constraints, or is it because we just don't expect to be able to do so because we haven't had the tools? The project in question is in part meant to make the case that such use-cases should not be esoteric--that one of the reasons that our reliability and security situations are so embarrassing is that we haven't so far taken those considerations seriously enough to develop the tools to deal with them. If we want to get better, maybe we should be thinking about how to integrate both static and dynamic type systems, rather than exalting one and denigrating the other.

nrinaudo 11y ago

I agree that duck typing is rarely critical, you can always work around it when you find you'd like to have it. On the other hand, I disagree with the scenario you describe: if you have multiple types that come from an external, closed-source library, you won't be able to have them extend a new interface. If you're lucky and they've not been marked final, you'll need to wrap them in another type that extends the right interface, then unwrap them... not at all impossible, but a lot of boilerplate. The best solution I know of is type classes, in languages that support them.

sanderjd 11y ago
Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.
- nrinaudo 11y ago
  I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the concept. Is there an other option that I'm not seeing?
  - drewgross 11y ago
    In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.
    - deleted 11y ago
      [deleted]
  - drewgross 11y ago
    In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.

JunkDNA 11y ago

One place where I ran into this was when I was building an ETL framework in Scala. The scenario was that I wanted to be able to move data from one database system to another and not have the end user of the DSL have to care about the types. The use case was essentially that you should be able to show up to an arbitrary database, run a query, and then pump that output somewhere else (e.g. another DB, flat file, transformation function, etc...) I went around in circles and ultimately concluded no amount of type inference or other things in Scala's bag of tricks would let a user of the API avoid the dreaded type cast. I have often seen this situation whenever I have tried to write generic code in a static language that needs to interact with a database.

nrinaudo 11y ago
That sounds like a perfect use case for type classes, have you tried that? If so, I'd be interested to know why it failed, if you can find the time.