Experiment: Unit testing isn't enough; You need static types, too • Hacker News Board

Re: Experiment: Unit testing isn't enough; You need static types, too

#51

Post by Goladus » Wed, Jun 20, 2012, 2:49 PM UTC

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

> 1. A common argument is that static-typed languages slow development. I'm not touching that land-mine.

If you claim type-checking is free, the counter-argument is not that it "slows development." The counter is that type-checking is not free because it incurs measurable costs. You may sacrifice dynamic features, you may have to add declarations and type casts-- these are all costs whether they "slow development" or not.

(Simple solution: don't waste time trying to claim type-checking is free and just focus on the benefits.)

Re: Experiment: Unit testing isn't enough; You need static types, too

#52

Post by gtani » Wed, Jun 20, 2012, 2:50 PM UTC

emillon wrote: post #24

pja wrote: post #20

Earlier quoted context omitted.

Hindley-Milner type systems to the rescue! (With a sprinkling of Haskell style type classes.) f :: Iterable a => a -> b f x = (do stuff with x...) f is defined to be constrained to accept only on types which implement the Iterable interface (however that's defined) as it's first argument and the compiler (or interpreter) will enforce that constraint.

> Hindley-Milner type systems to the rescue! You're implying that all type-systems derived from HM have a form of bounded polymorphism. They're not, for example OCaml does not have type classes (you could probably encode a lot into objects, though).

TYpe classes and the ML module system overlap in capabilities

http://www.cse.unsw.edu.au/~chak/papers/WC06.html

Re: Experiment: Unit testing isn't enough; You need static types, too

#53

Post by kingkilr » Wed, Jun 20, 2012, 2:50 PM UTC

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

a) If you aren't touching that land mine you're missing the point. You can't say that one is free (except maybe it has a cost), and the other has a cost. That's just nonsensical.

b) Second, I'm going to argue that tests are actually free. And I think this because I don't care how good static type proponents think they are, I know they don't wait until it compiles and SHIP SHIP SHIP, they actually run their damned program. The alternative to automated testing is manual testing, not no testing.

Re: Experiment: Unit testing isn't enough; You need static types, too

#54

Post by [deleted] » Wed, Jun 20, 2012, 2:50 PM UTC

michaels0620 wrote: post #44

cageface wrote: post #30

Earlier quoted context omitted.

The kinds of static type systems you find in C# & Java are too primitive. Something like Haskell with perhaps a little less religion about mutability is a whole different story.

Does Scala fit your idea of something in between? It has nice type inference features and does not require pure immutability.

[deleted]

Re: Experiment: Unit testing isn't enough; You need static types, too

#55

Post by dons » Wed, Jun 20, 2012, 2:53 PM UTC

kingkilr wrote: post #41

dons wrote: post #28

Earlier quoted context omitted.

If you're hoping to catch a specification error, don't use a type like `Integer -> Integer`, which doesn't capture the specification except in a most general sense. Just as you should write good tests, that actually test for useful properties, so you should write good types -- and get useful proofs back from the compiler as a result.

I wasn't trying to catch the error of "program author is a moron who doesn't know the difference between Fibonacci and factorial". Were I trying to catch that error I would have been aware of it, and then much less likely to write the bug in the first place. This is a truism that is well accepted by testing proponents: which tests you write are incredibly important, and you need to write your tests first in order to…

Numerical algorithms suffer from a paucity of types. So either you enrich your numerical type hierarchy, or you prove an implementation matches a model, e.g. for fibonacci http://stackoverflow.com/a/8434107/83805

Re: Experiment: Unit testing isn't enough; You need static types, too

#56

Post by cyrus_ » Wed, Jun 20, 2012, 2:53 PM UTC

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

Many of the unit tests would have to be written in a simply-typed language like Haskell too -- the author notes that only a handful of tests could be entirely eliminated due by the rewrite. Probably worth further study.

Re: Experiment: Unit testing isn't enough; You need static types, too

#57

Post by papsosouid » Wed, Jun 20, 2012, 2:53 PM UTC

johnkchow wrote: post #23

glenjamin wrote: post #8

I applaud the effort to try and dissect the problem scientifically. If a whole program has 1 bug due to being implemented with dynamic types over static types, and that bug has gone unnoticed, then it can't be particularly important. The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. If this is true then we need to compare the saving in development…

From my personal experience, the saving in development time is very much real. I used to work on .NET, and you'd have to program against crazy, non-intuitive patterns in order to have your code "clean" (I hated IoC containers as well as writing all that boilerplate code for Attributes. And for Java, remember that hilarious post about Factory-Factory-Factory patterns http://discuss.joelonsoftware.com/default.asp?joel.…

>From my personal experience, the saving in development time is very much real.

But your personal experience is comparing expressive languages to unexpressive languages, and then making the mistake of thinking you are comparing dynamically typed languages to statically typed languages. What does .net's ugly (in your opinion) API have to do with static typing? Factory-Factory-Factory patterns is a joke even in java, but it also has nothing to do with static typing at all.

>By the way, it sounds like I'm an ignorant dynamically-typed lover. I'm not

Well, you are repeating the most commonly used and easily debunked strawman, so it really does sound like ignorance. Have you used a modern statically typed language? If not, by definition you are in fact ignorant.

Re: Experiment: Unit testing isn't enough; You need static types, too

#58

Post by wtetzner » Wed, Jun 20, 2012, 2:55 PM UTC

kingkilr wrote: post #53

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

a) If you aren't touching that land mine you're missing the point. You can't say that one is free (except maybe it has a cost), and the other has a cost. That's just nonsensical. b) Second, I'm going to argue that tests are actually free. And I think this because I don't care how good static type proponents think they are, I know they don't wait until it compiles and SHIP SHIP SHIP, they actually run their damned pro…

> I'm going to argue that tests are actually free.

> The alternative to automated testing is manual testing, not no testing.

Actually, unit tests have different costs than manual testing. That doesn't make them free. For example, with unit tests, you now have more (possibly buggy) code to maintain.

Re: Experiment: Unit testing isn't enough; You need static types, too

#59

Post by lambda » Wed, Jun 20, 2012, 2:56 PM UTC

kingkilr wrote: post #33

scott_s wrote: post #26

Earlier quoted context omitted.

I have not looked at the programs, but programs don't have to be long to be interesting. There are many "interesting" programs under 100 lines of code - and they can be important if they form the kernel of a larger program. Also, the author responds to a similar point in his comments: http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-eno...

The author doesn't really respond to the point, he simply says they were non-trivial in complexity, which may be true, but that doesn't mean they're non-trivial in their dynamacism (is that a word?). Moreover it in no way responds to the claim that these codebases aren't very good.

Does it matter if "these codebases aren't very good"? Have you ever actually seen a good code base? Most code I've seen has some poorly written corners; something where someone was in a hurry, or didn't know what they were doing, or someone inexperienced with the project started working on it, or the like.

The point is, these were real-world codebases with substantial unit tests, and they had type errors that weren't caught by these unit tests.

Honestly, in several groups I've worked with, I've had trouble getting people to add unit tests even to code in dynamic languages. A codebase which already has substantial unit tests is likely to be better than average, on that basis alone.

This is about saying, in the messy real world, do unit tests actually make type safety obsolete. And the answer is, no, they don't, even code with fairly good test coverage can be improved by adding typechecking. Now, there is the question of whether writing in the dynamic language allowed people to write code faster (it's generally a lot easier to translate correct code once it's written than to write it in the first place); or whether some of the more highly dynamic features of dynamic languages benefit writing or deploying code.

Re: Experiment: Unit testing isn't enough; You need static types, too

#60

Post by cageface » Wed, Jun 20, 2012, 2:56 PM UTC

michaels0620 wrote: post #44

cageface wrote: post #30

Earlier quoted context omitted.

The kinds of static type systems you find in C# & Java are too primitive. Something like Haskell with perhaps a little less religion about mutability is a whole different story.

Does Scala fit your idea of something in between? It has nice type inference features and does not require pure immutability.

Personally I like Scala but I think it's too complex and a little too clever to escape the FP niche. I'd be happy to be wrong about this.