4 ms·

There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Static languages try

There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Static languages try to be as sound as possible, at the cost of some completeness. Dynamic languages are less concerned with soundness and can be more complete. As an example, duck typing is usually not possible to achieve in a static language - it's really hard to allow duck typing and remain sound (I don't actually know that it's possible, but I'm not sure either way). Having said that, I'm firmly of the opinion that static languages are much, much easier to write in and maintain once you get the hang of whatever type system they use, and the loss of completeness is acceptable for all the benefits they bring.

rwmj 11y ago
OCaml has duck typing for objects (strictly speaking it is "structural typing").
- nrinaudo 11y ago
  Oh, right, I never realised that structural typing was static duck typing! Scala has it too, even if it's frowned on. Thanks for enabling me to make the connection!
  - coldtea 11y ago
    Doesn't Go have the same thing?
    - nrinaudo 11y ago
      I know next to nothing about Go, but I think you're referring to the fact that it has some sort of implicit inheritance resolution - if there is a Reader interface with a read method, and a type A that has a read method with the same signature, then A will be considered to be a subtype of Reader, whether you marked it as such (or whether you want it or not). I see what you mean, this feels like a static version of duck typing. I'm not sure how I feel about loosing control over what supertypes my type extends, though - well, I lie. I don't like it. But I haven't given this enough thought for a constructive, well argumented discussion on the topic.
      - coldtea 11y ago
        >I'm not sure how I feel about loosing control over what supertypes my type extends, though - well, I lie. I don't like it. Well, don't you lose that by default (and even more) with dynamic typing?
        nrinaudo 11y ago
        You do, and I really, really dislike doing any serious work without a solid type system.
realharo 11y ago
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.
VanVincent 11y ago
There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Static languages try to be as sound as possible, at the cost of some completeness. Dynamic languages are less concerned with soundness and can be more complete. They are both "limited" to being Turing complete and therefore should be able to express the same things. Implementing the same algorithm can be cumbersome with types at times (No 1:1 representation of JSON Objects for example) but you can define types which wrap things like that to make it work anyway.
coldtea 11y ago
>There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Including a static one with a "dynamic" type like C# has? What would that be?

rwmj 11y ago

OCaml has duck typing for objects (strictly speaking it is "structural typing").

nrinaudo 11y ago
Oh, right, I never realised that structural typing was static duck typing! Scala has it too, even if it's frowned on. Thanks for enabling me to make the connection!
- coldtea 11y ago
  Doesn't Go have the same thing?
  - nrinaudo 11y ago
    I know next to nothing about Go, but I think you're referring to the fact that it has some sort of implicit inheritance resolution - if there is a Reader interface with a read method, and a type A that has a read method with the same signature, then A will be considered to be a subtype of Reader, whether you marked it as such (or whether you want it or not). I see what you mean, this feels like a static version of duck typing. I'm not sure how I feel about loosing control over what supertypes my type extends, though - well, I lie. I don't like it. But I haven't given this enough thought for a constructive, well argumented discussion on the topic.
    - coldtea 11y ago
      >I'm not sure how I feel about loosing control over what supertypes my type extends, though - well, I lie. I don't like it. Well, don't you lose that by default (and even more) with dynamic typing?
      - nrinaudo 11y ago
        You do, and I really, really dislike doing any serious work without a solid type system.

realharo 11y ago

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.

VanVincent 11y ago

There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Static languages try to be as sound as possible, at the cost of some completeness. Dynamic languages are less concerned with soundness and can be more complete. They are both "limited" to being Turing complete and therefore should be able to express the same things. Implementing the same algorithm can be cumbersome with types at times (No 1:1 representation of JSON Objects for example) but you can define types which wrap things like that to make it work anyway.

coldtea 11y ago

>There is one other undeniable advantage to dynamic languages: you can express things in a dynamic language that you can't in a static one. Including a static one with a "dynamic" type like C# has? What would that be?