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

#121

Post by Peaker » Wed, Jun 20, 2012, 4:11 PM UTC

Goladus wrote: post #51

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" o…

I am not claiming static typing is free.

But it is also untrue that you have to "add declarations and type casts". With type inference, you don't actually have to.

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

#122

Post by swah » Wed, Jun 20, 2012, 4:13 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…

Very elegant way to show a point...

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

#123

Post by simias » Wed, Jun 20, 2012, 4:13 PM UTC

debacle wrote: post #104

simias wrote: post #100

Earlier quoted context omitted.

No true scotsman much?

I don't know how you could contrive what I said to be cognitive dissonance. If you have a team of N good programmers, you can probably write without static typing. If you have a team of N-1 good programmers and 1 bad programmer, you should really use a language static typing.

I just read the first part of your comment as "no true programmer would need no filthy static type checking". Sorry if I misunderstood.

I find it hard to correlate use of static typing with development experience, that's all.

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

#124

Post by barrkel » Wed, Jun 20, 2012, 4:16 PM UTC

mike_ivanov wrote: post #113

barrkel wrote: post #7

Earlier quoted context omitted.

That statement, though, is almost content-free. It's a truism. If you don't have type checking, then every bug has gotten past your unit tests; but some proportion may have been prevented with type checking. And vice versa. The statement doesn't say anything about the value or non-value of unit tests or type checking.

No, it's not content-free, at least when put back into context. It's like coffee. If your coffee is shitty (complect), then no amount of sugar (unit tests) or cream (type checking) will make it any better.

Your coffee analogy also says nothing about whether sugar or cream are better than one another, or if either is necessary.

Though I can guarantee you that either sugar or cream with only 0.1% coffee content will still be usable as sugar or cream for other purposes, so I can't even agree with your analogy taken to its limit: that no amount will make the coffee better, because enough will make it usable for other things.

In fact, unit testing and static type checking are largely orthogonal to the complecting issue that Rich was getting act. Unit testing and static typing will both increase complexity; they are both ways of making assertions about the behaviour of the code, and for working code, they should both actually be redundant. But that doesn't mean, as a practical issue, that we should do away with either or both. We're fallible. Saying the same thing twice or three times increases the probability of finding something inconsistent if our statements are not representative of the Platonic ideal we're trying to express.

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

#125

Post by bad_user » Wed, Jun 20, 2012, 4:16 PM UTC

cageface wrote: post #85

soc88 wrote: post #63

Earlier quoted context omitted.

Interesting. I never perceived Scala to be in a functional niche. As far as I know most people consider it to be an object-oriented language first and foremost, with functional features. Removing inheritance would have made the language (and every other language, too) a lot easier, but seeing that people cope with C# or Java quite well I'm not sure about the merit of the "complex" claim. Comparing the C# and the Scal…

I don't think page counts of specs or feature lists really tell you that much. I didn't find it that hard too get up to speed in Scala but it seems to scare away too many Java people. My main criticism is that it allows too much syntactic flexibility.

I'm a programmer that in general prefers dynamic languages. Recently I've started writing production code in Scala for a couple of web services for which I really needed the performance and flexibility of the JVM.

Scala does have problems. But NOT the language. I find the language to be extremely elegant and well designed.

The problem lies with the community. I find Scala libraries to be an abomination of taste and common-sense. I don't know why that is, but in general I stay away from libraries commonly used by Scala developers.

For instance I prefer JUnit over ScalaTest, I prefer JAX-RS (DropWizard) over Scalatra or Play. I prefer Maven over SBT.

Of course, you could say that the language itself invites this nasty style of programming, because the syntax is too flexible and the features too powerful. However I strongly disagree.

For instance I've worked with a lot of Ruby and Python libraries over the years and most popular Ruby/Python libraries are extremely well designed, easy to use and easy to look under the hood. Ruby on Rails for instance was not pretty, however starting with version 3 it went through a major refactoring effort and now the codebase is clean and easy to follow; while being one of the easiest to use and full-featured web frameworks ever built.

Unfortunately when picking a language, you do have to rely on a community and an ecosystem of libraries. However in the case of Scala, if you don't like the style of the current community, you can just pick from the thousands of already available and mature Java libraries.

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

#126

Post by akkartik » Wed, Jun 20, 2012, 4:17 PM UTC

swannodette wrote: post #46

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…

Via Philip Wadler, http://wadler.blogspot.com/2011/09/experiment-about-static-a...

On HN: http://news.ycombinator.com/item?id=4082775

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

#127

Post by Goladus » Wed, Jun 20, 2012, 4:17 PM UTC

Peaker wrote: post #121

Goladus wrote: post #51

Earlier quoted context omitted.

> 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" o…

I am not claiming static typing is free. But it is also untrue that you have to "add declarations and type casts". With type inference, you don't actually have to.

But you have to use a language with type inference. That's still a cost. Maybe not a big one, but that was my point (and I'm definitely nitpicking a bit, I realize that.)

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

#128

Post by 6ren » Wed, Jun 20, 2012, 4:18 PM UTC

Regarding bugs, I think it's clear that static typing does detect more errors - the issue is whether it's worth the trouble.

I think a more significant difference is the inertia of the codebase, how difficult it is to change. Static types make it harder to evolve interfaces; but unit tests make it even harder.

But both the above are just fiddling: the real advantage of static typing is runtime speed; the advantage of dynamic types is development productivity. In the history of programming, the latter always wins.

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

#129

Post by dspeyer » Wed, Jun 20, 2012, 4:18 PM UTC

For the cases I was easily able to count, this is one bug per thousand lines of code. I realize that's a handwavy metric, but it's enough to say we're not talking about a ton of bugs.

On the other hand, successful conversion of these codebases is a very interesting result. Apparently static, at least static as sophisticated as Haskell, actually can express most of the idioms in standard python. This surprises me, as I've never seen a C++ program of significant complexity that didn't resort to void*s somewhere.

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

#130

Post by Peaker » Wed, Jun 20, 2012, 4:20 PM UTC

mikeryan wrote: post #99

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…

Also, type-checking is free[1], while unit tests have to be manually written. The use of type-checking doesn't negate the need for unit tests. It just adds another layer of validation. The Unit Test "cost" is still there.

You can write far fewer tests if you have good static validation.

For example, taken to the extreme, you can write 0 tests in Agda, and still have more assurances about correctness than if you had 100% coverage in a dynamically typed program.