7 ms·

>You can have statically compiled languages that use type inference to realize what is effectively dynamic typing. Just because you don't have to explicitly wr

>You can have statically compiled languages that use type inference to realize what is effectively dynamic typing. Just because you don't have to explicitly write out the type does not make it any less static. I believe that the usual arguments against languages with static typing such as verbosity and lack of flexibility are largely eliminated by the more modern languages such as Scala, Kotlin or Typescript (though typescript is more "optional typing" than static really).

coldtea 11y ago
>Just because you don't have to explicitly write out the type does not make it any less static. No, but not having to write the type was one of the biggest attractions of dynamic languages -- a lot of us didn't care that much for being fully dynamic, but just enjoyed the less ceremony of dynamic languages. As for not having to commit to types for some cases, STL languages can also have a "void *" or "variant" or "dynamic" type (a la C#).
- nrinaudo 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. 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?
- dllthomas 11y ago
  'As for not having to commit to types for some cases, STL languages can also have a "void " or "variant" or "dynamic" type (a la C#).'* Even Haskell has Data.Dynamic, though it's not often used.
tachyonbeam 11y ago
It's not just "not having to write out the type". It's that the compiler can automatically insert typed unions to make the typing dynamic where you need it. If a variable can have different types at different times, that's dynamic typing.
- dllthomas 11y ago
  One way of looking at a union type is "this variable can have different types at different times." Another is "this variable has a single type - the union type." Especially if actions are restricted to those valid on all parts of the union, I'd say it is correct to consider that to still be static typing.

coldtea 11y ago

>Just because you don't have to explicitly write out the type does not make it any less static. No, but not having to write the type was one of the biggest attractions of dynamic languages -- a lot of us didn't care that much for being fully dynamic, but just enjoyed the less ceremony of dynamic languages. As for not having to commit to types for some cases, STL languages can also have a "void *" or "variant" or "dynamic" type (a la C#).

nrinaudo 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. 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?
dllthomas 11y ago
'As for not having to commit to types for some cases, STL languages can also have a "void " or "variant" or "dynamic" type (a la C#).'* Even Haskell has Data.Dynamic, though it's not often used.

tachyonbeam 11y ago

It's not just "not having to write out the type". It's that the compiler can automatically insert typed unions to make the typing dynamic where you need it. If a variable can have different types at different times, that's dynamic typing.

dllthomas 11y ago
One way of looking at a union type is "this variable can have different types at different times." Another is "this variable has a single type - the union type." Especially if actions are restricted to those valid on all parts of the union, I'd say it is correct to consider that to still be static typing.