3 ms·

I think a lot of static-language people assume that dynamic-language people write a lot of type-assertion statements in their code and then write a lot of tests

I think a lot of static-language people assume that dynamic-language people write a lot of type-assertion statements in their code and then write a lot of tests to ensure those assertions hold. Turns out... we don't really do that so much.

eru 11y ago
> Turns out... we don't really do that so much. With a suitably enlarged definition of (static) type, a lot of tests become type-assertions. Eg red black trees have interesting balancing requirements: no t See eg Red Black Trees are another interesting example. A red black tree is a binary search tree, and all its nodes are coloured either red or black. You can not have two red nodes in a row on any path, but all paths from root to any leave have to have the same number of black nodes. Testing that these two properties hold after an arbitrary number of inserts sounds like a good candidate for a unit tests, and doesn't sound like a type assertion, does it? See https://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/ https://www.reddit.com/r/haskell/comments/ti5il/redblack_tre... for how to encode those properties into the types. In any case, Haskell has great support for unit tests, too. (Because in general you can't and at any rate don't want to encode everything you care about in the type system.) Have a look at QuickCheck. There are ports for various other languages, too. QuickCheck is a generalization of the table-driven approach to unit-testing: it's about generating those tables automatically, and automatically simplifying any inputs found that lead to buggy behaviour.
yummyfajitas 11y ago
I'm as much a dynamic language person as a static language person - I write as much python as I do Scala. The point is that the guarantees you can get go well beyond simply assert(type(x) == str). See the examples in my previous post - you can guarantee at the type level that a list isn't empty, or that a boolean formula only contains predicates that can be rendered to javascript. These are things I'd have lots of unit tests for. Here is another example of using static types to fix a problem I constantly run into in Python (adding vectors from the wrong vector spaces together): https://www.chrisstucchio.com/blog/2014/type_safe_vector_addition_with_dependent_types.html https://www.chrisstucchio.com/blog/2014/type_safe_vector_add...

eru 11y ago

> Turns out... we don't really do that so much. With a suitably enlarged definition of (static) type, a lot of tests become type-assertions. Eg red black trees have interesting balancing requirements: no t See eg Red Black Trees are another interesting example. A red black tree is a binary search tree, and all its nodes are coloured either red or black. You can not have two red nodes in a row on any path, but all paths from root to any leave have to have the same number of black nodes. Testing that these two properties hold after an arbitrary number of inserts sounds like a good candidate for a unit tests, and doesn't sound like a type assertion, does it? See https://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/ https://www.reddit.com/r/haskell/comments/ti5il/redblack_tre... for how to encode those properties into the types. In any case, Haskell has great support for unit tests, too. (Because in general you can't and at any rate don't want to encode everything you care about in the type system.) Have a look at QuickCheck. There are ports for various other languages, too. QuickCheck is a generalization of the table-driven approach to unit-testing: it's about generating those tables automatically, and automatically simplifying any inputs found that lead to buggy behaviour.

yummyfajitas 11y ago

I'm as much a dynamic language person as a static language person - I write as much python as I do Scala. The point is that the guarantees you can get go well beyond simply assert(type(x) == str). See the examples in my previous post - you can guarantee at the type level that a list isn't empty, or that a boolean formula only contains predicates that can be rendered to javascript. These are things I'd have lots of unit tests for. Here is another example of using static types to fix a problem I constantly run into in Python (adding vectors from the wrong vector spaces together): https://www.chrisstucchio.com/blog/2014/type_safe_vector_addition_with_dependent_types.html https://www.chrisstucchio.com/blog/2014/type_safe_vector_add...