3 ms·

By the same token, tests and the “heavy costs” of testing round trips should also be considered resources.

mlthoughts2018 7y ago
Yes, for sure. But unlike language features that enforce correctness, you can choose what and how to test to suit your use case. Haskell for example doesn’t support gradual typing. You must always pay the static typing cost regardless of whether you need it.
- solidsnack9000 7y ago
  Gradual typing does allow a more graded trade-off between types and tests. Weak typing doesn’t really allow you to make that trade-off, since testing is going to be directed by failures and you don’t have the option to use types instead. Although in theory you have discretion with regards to tests, in practice you have to write a lot of them. Kind of like how interfaces and `Object` let you write less specific types in theory but in practice you end up writing them anyways.
- whateveracct 7y ago
  https://typesandkinds.wordpress.com/2016/01/22/haskell-as-a-gradually-typed-dynamic-language https://typesandkinds.wordpress.com/2016/01/22/haskell-as-a-... I wonder if the extension proposed in this blog post would fit the bill and be attractive to certain non-Haskellers?
  - tome 7y ago
    It doesn't work. Tangentially, I had an interesting experience reading this blog post: * This is an amazing idea! Why did I never think of it? * Oh, it’s never actually going to work ... * ... and I said so much as a comment on the blog post three years ago
    - whateveracct 7y ago
      Well I suppose it's honestly not a huge value proposition anyways imo
- tome 7y ago
  > Haskell for example doesn’t support gradual typing Sure it does. It’s possible to gradually make the contracts of your Haskell functions more precise by more finely specifying the behaviour in their types. I think what you mean, though, is that the lower end of the well-typed spectrum is much higher than most dynamic language users would be comfortable with. This is true in practice, but in principle there’s no reason everyone couldn’t just use Dynamic everywhere. It just turns out that’s not particularly useful.

mlthoughts2018 7y ago

Yes, for sure. But unlike language features that enforce correctness, you can choose what and how to test to suit your use case. Haskell for example doesn’t support gradual typing. You must always pay the static typing cost regardless of whether you need it.

solidsnack9000 7y ago
Gradual typing does allow a more graded trade-off between types and tests. Weak typing doesn’t really allow you to make that trade-off, since testing is going to be directed by failures and you don’t have the option to use types instead. Although in theory you have discretion with regards to tests, in practice you have to write a lot of them. Kind of like how interfaces and `Object` let you write less specific types in theory but in practice you end up writing them anyways.
whateveracct 7y ago
https://typesandkinds.wordpress.com/2016/01/22/haskell-as-a-gradually-typed-dynamic-language https://typesandkinds.wordpress.com/2016/01/22/haskell-as-a-... I wonder if the extension proposed in this blog post would fit the bill and be attractive to certain non-Haskellers?
- tome 7y ago
  It doesn't work. Tangentially, I had an interesting experience reading this blog post: * This is an amazing idea! Why did I never think of it? * Oh, it’s never actually going to work ... * ... and I said so much as a comment on the blog post three years ago
  - whateveracct 7y ago
    Well I suppose it's honestly not a huge value proposition anyways imo
tome 7y ago
> Haskell for example doesn’t support gradual typing Sure it does. It’s possible to gradually make the contracts of your Haskell functions more precise by more finely specifying the behaviour in their types. I think what you mean, though, is that the lower end of the well-typed spectrum is much higher than most dynamic language users would be comfortable with. This is true in practice, but in principle there’s no reason everyone couldn’t just use Dynamic everywhere. It just turns out that’s not particularly useful.