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

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

evanfarrer.blogspot.ca

Post reply on HN
Print view View original

191–200 of 276 posts

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

#191

Post by dllthomas »

debacle wrote: post #137
simias wrote: post #123

Earlier quoted context omitted.

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.

If you are a good programmer, you don't need typing, you don't need interfaces, you don't need many things that make bad programmers better programmers. You might still use them, and there's nothing entirely wrong with that, but you probably don't need them. This is why so many people have problems writing JavaScript.

Even if you're a good programmer, typing and interfaces make refactoring quicker and typos easier to find.

This is why so many people have problems writing in JavaScript.

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

#193

Post by anamax »

papsosouid wrote: post #114
davesims wrote: post #106

Earlier quoted context omitted.

> That assumption isn't hidden, it is made up. By you. Not at all. The assumption is clearly implied by the conclusion of the study, which makes an unwarranted equivalence of all languages that have 'static type checking': "The translation of these four software projects from Python to Haskell proved to be an effective way of measuring the effects of applying static type checking to unit tested software." > Just beca…

>which makes an unwarranted equivalence of all languages that have 'static type checking': No it doesn't. Read what you quoted, it says nothing even remotely resembling "this benefit applies to all languages with static typing". It is testing static typing, not a specific language. It uses the best static typing system to do so. You are entirely inventing the notion that this must then apply to java. > If the study w…

> It uses the best static typing system to do so.

It doesn't use the best dynamic language or best unit tests.

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

#194

Post by jerf »

fhars wrote: post #142
jerf wrote: post #98

Earlier quoted context omitted.

In my admittedly-limited personal experience doing something similar, it's really hard to characterize this in a sane way. What you end up with is a pile of unit tests which are "really testing something", yet, some non-trivial percentage of the tests are still redundant to the type system. You feel like you can't throw it away because of the percentage that is a real test of functionality, but if you'd been starting…

Using the type system to prevent the generation of malformed HTML (and most types of invalid HTML) at compile time is actually a standard example for a situation where unit tests become mostly superfluous in the presence of a static type system. Some unit tests for the escaping functions in the library can be useful, but code that uses the library can just trust the compiler.

That's probably why it came to mind. The real instance I encountered wasn't that, but requires so much other context to explain it wasn't a good HN comment.

Also, rereading my comment, something that may not be clear, when I said "some non-trivial percentage of the tests are still redundant to the type system", I mean per test. On each test, some non-trivial percentage is actually redundant, not that there is some percentage of tests that are totally redundant. You just remove those, of course.

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

#195

Post by anamax »

papsosouid wrote: post #154
davesims wrote: post #146

Earlier quoted context omitted.

Had the study qualified itself to merely "Haskell vs. Python" with deference given to the statistical significance of the sample size, you'd have a point. It wasn't me that brought all static typing , which of course includes Java, into the question at hand -- it was the study itself.

Yes, it was you. Why do you think the comparison should be "really bad static type system" vs "really good dynamic type system"? In what way does that make the test more useful? Allow me to say this again, as I do not know how to be any clearer: You do not test the potential of something by using the worst possible example of it. The only point of your desire is to reinforce the strawman that java = static typing. A…

> You do not test the potential of something by using the worst possible example of it.

So? Folks don't use the "potential", they use the real. They're asking questions like "should I use Java or Python".

> do airbags help prevent deaths" would be a very poor test if it used anything other than the best possible airbag technology.

That's not how things actually work. You decide between what's available. The performance of the best possible airbags is irrelevant. The real question is the cost and benefits of airbags that are likely to be deployed.

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

#196

Post by zopa »

x1 wrote: post #177
zopa wrote: post #144

Earlier quoted context omitted.

Yes, you can write a Query type that is vulnerable to SQL injection, if you want to. But if you write a secure version, you only have to write it once. You only have to maintain it in one place. You only need to test it in one place. And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. This is easier to see in a language with a rich,…

> But if you write a secure version, you only have to write it once. > You only have to maintain it in one place. > You only need to test it in one place. Again, so this cannot be done in a dynamic language? If it can be done, why bring them up? > And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. The only thing the compiler will y…

> "The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter."

In Haskell, I'd have a module, Database, that held all my db code. That module would export functions something like

query :: Query -> DBResult update :: Query -> DBAction -> DBResult

(read those as "query is a function that takes a Query and returns a DBResult.")

In the rest of my program, those functions would be the only way to talk to the database. There's your guarantee.

Could I, rather than using my nice database module, instead drop into IO and write code to do something vicious? Surely. But now we've moved beyond bugs and into active malice.

> "Again, so this cannot be done in a dynamic language? If it can be done, why bring them up?"

It's harder. With duck typing, if it looks like a Query it is a Query, no? Even if it drops your table. I'm no expert on dynamic languages, and I'd believe that there are sophisticated object hierarchies that can do these things (at runtime...), but the original article is empirical evidence that real projects get this wrong.

Really, though, try a language with a modern type system and see for yourself. I know we Haskell users sound like zealots, but the difference between the Java and Haskell type systems truly is night and day.

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

#198

Post by ansible »

gnuvince wrote: post #163
ansible wrote: post #96

Earlier quoted context omitted.

> Something like Haskell with perhaps a little less religion about mutability is a whole different story. I consider Ocaml [1] to fill that particular niche. When I was going through my FP phase, I tried that out a little before going full-on lazy evaluation with Haskell. From what I can recall, the type inference isn't as cool as what's in Haskell, but at least it's there. There are plenty of libraries, and packages…

What do you mean by "the type inference isn't as cool as what's in Haskell"?

IIRC, Ocaml does use Hindley-Miller, but Haskell has some tweaks that make it work better. I may be mistaken, someone who is more current on both please correct me.

In retrospect, I think I was also thinking about type-classes in Haskell, which Ocaml does not have. But from what I understand Ocaml has other means to achieve the same ends.

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

#199

Post by papsosouid »

anamax wrote: post #195
papsosouid wrote: post #154

Earlier quoted context omitted.

Yes, it was you. Why do you think the comparison should be "really bad static type system" vs "really good dynamic type system"? In what way does that make the test more useful? Allow me to say this again, as I do not know how to be any clearer: You do not test the potential of something by using the worst possible example of it. The only point of your desire is to reinforce the strawman that java = static typing. A…

> You do not test the potential of something by using the worst possible example of it. So? Folks don't use the "potential", they use the real. They're asking questions like "should I use Java or Python". > do airbags help prevent deaths" would be a very poor test if it used anything other than the best possible airbag technology. That's not how things actually work. You decide between what's available. The performan…

>So? Folks don't use the "potential", they use the real.

Haskell is real.

>They're asking questions like "should I use Java or Python".

That's wonderful, but it has nothing to do with the subject at hand, which was the question "can static typing reduce the number of bugs?". If you want an answer to a different question, don't complain about the answer given for this question, go find someone answering the question you want answered.

>That's not how things actually work. You decide between what's available. The performance of the best possible airbags is irrelevant. The real question is the cost and benefits of airbags that are likely to be deployed.

Why can't anyone follow a simple line of reasoning without resorting to fallacies? He tested the best airbags available. Not theoretical airbags that don't exist. He tested a car with the best airbags available to one without. The airbags were a benefit. You and the other guy making up fallacies insist that this isn't a fair comparison, because you want to drive a car where the airbags deploy 5 seconds after impact. Your crappy car isn't relevant to the question of "can airbags save lives".

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

#200

Post by papsosouid »

anamax wrote: post #193
papsosouid wrote: post #114

Earlier quoted context omitted.

>which makes an unwarranted equivalence of all languages that have 'static type checking': No it doesn't. Read what you quoted, it says nothing even remotely resembling "this benefit applies to all languages with static typing". It is testing static typing, not a specific language. It uses the best static typing system to do so. You are entirely inventing the notion that this must then apply to java. > If the study w…

> It uses the best static typing system to do so. It doesn't use the best dynamic language or best unit tests.

Then you should be proposing he use whatever language you feel is better than python at being the best dynamic type system. The best unit tests is entirely irrelevant.
Post reply on HN