Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type Wars

blog.cleancoder.com

Post reply on HN
Print view View original

61–62 of 62 posts

Re: Type Wars

#61

Post by mpweiher »

Silhouette wrote: post #59
mpweiher wrote: post #20

Earlier quoted context omitted.

Right. They are one class of tests that happens to be checked at compile time. But what about all the other tests that you still have to do? Which typically also coincidentally check the types (if I check that a value is > 2, I am also checking that its type is number (or int or whatever your particular numeric tower or non-tower says). And what is the value of "compile time", if the all this type checking makes the…

But what about all the other tests that you still have to do? Which typically also coincidentally check the types (if I check that a value is > 2, I am also checking that its type is number (or int or whatever your particular numeric tower or non-tower says). I see this argument from fans of dynamic typing quite a bit. Gary Bernhardt manages to defeat it better in 5 minutes than I could in a lifetime, so here you go:…

Really? OK, if you're going to base your arguments about dynamically typed languages on JavaScript, then I'm going to base my arguments about statically typed languages on C.

'asdas' > 2 -> Message not understood "SmallInteger>>isByteString"

Re: Type Wars

#62

Post by Silhouette »

mpweiher wrote: post #61
Silhouette wrote: post #59

Earlier quoted context omitted.

But what about all the other tests that you still have to do? Which typically also coincidentally check the types (if I check that a value is > 2, I am also checking that its type is number (or int or whatever your particular numeric tower or non-tower says). I see this argument from fans of dynamic typing quite a bit. Gary Bernhardt manages to defeat it better in 5 minutes than I could in a lifetime, so here you go:…

Really? OK, if you're going to base your arguments about dynamically typed languages on JavaScript, then I'm going to base my arguments about statically typed languages on C. 'asdas' > 2 -> Message not understood "SmallInteger>>isByteString"

So what languages would you like to compare on a like-for-like basis? There are plenty of useful invariants that would be verified by the static type systems of everyday languages, but not picked up implicitly in unit tests.

On further reflection, I'm not even sure how your argument about integers is supposed to work. Implicitly testing that an input is an integer by comparing it to another one in a single unit test case wouldn't guarantee that no other code could pass a non-integer input to the same function from somewhere else in the general case, which is what a static type system would do for you.

The context where your argument does seem to have some merit is in unit testing that the outputs from a function are of the expected type. But even then, there have been plenty of related gotchas in JavaScript, Ruby, Python, PHP, Perl... I'm sure you can pick an example where your particular case (the integer test) gets picked up, and I'm sure some popular dynamic languages are getting better in this area (Python 3 has significant advances over Python 2, for example).

Basically, this feels like you're choosing an invariant and a dynamic language that conveniently support your position, while ignoring numerous other useful invariants and languages that would not. If you get to do that, it seems only fair to judge the potential of strong, static type systems using languages like Haskell or Rust, and I can't think of many unit tests I've ever written in dynamic languages that would implicitly verify that the unit under test didn't have unexpected side effects or did not allow access to resources in ways that might not be thread-safe, even in the specific case being tested rather than the general one.

Post reply on HN