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

#141

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

thebluesky wrote: post #83

eta_carinae wrote: post #77

The advantage of statically typed languages has a lot less to do with tests and everything to do with tools. IDE's can do very little when no type information is available, and most automatic refactorings require human supervision when performed on dynamically typed languages (read this for details: http://beust.com/weblog/2006/10/01/dynamic-language-refactor... ).

Tooling and performance are two largest advantages. Disadvantage is more verbosity, but it's a trade-off. With dynamically typed languages I find that you still need to worry about types, but you have to trace through the code to figure out what type a particular variable is (esp. if you're not the only one working on a project). In a statically typed language that information is readily available.

The claim static typing adds verbosity is a common fallacy.

Haskell code is more concise than most dynamically typed languages.

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

#142

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

jerf wrote: post #98

cyrus_ wrote: post #56

Earlier quoted context omitted.

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.

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.

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

#143

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

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 says nothing even remotely resembling "this benefit applies to all languages with static typing".

That is precisely what it says, and that is reiterated later:

"...the conclusion can be reached that...in practice [unit testing] is an inadequate replacement for static type checking."

I'm not sure what you're reading, but there's no qualifications in the language used here regarding the idea of 'static type checking,' nothing so modest about the scope of the conclusion as claiming it was merely a "useful test" as you put it. It was a sweeping generalization about two very broad and extremely complex categories of languages. Had the conclusions used more moderate language and qualified itself adequately, I wouldn't have a problem. But all that has been shown here, is that in some contexts more care needs to be taken writing unit tests in a dynamic environment to catch some errors that are automatically caught in static environments. That is all that the data warrants.

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

#144

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

x1 wrote: post #110

gaius wrote: post #81

Earlier quoted context omitted.

To have the compiler trap accidents for you? How would you do this if a query and a string were the same thing?

So when the Query is sent to the database MySQL actually receives a Query object and then parses that Query object? ...oh wait, right before it is sent to mysql it is turned back into a string again. My point is that static typing doesn't help you do anything other than verify that the objects being passed are of a particular type. I'm not saying static typing is bad or good I'm just saying that type checking itself…

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, flexible and expressive type system than it is in Java. The writer of the original article used Haskell for a reason.

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

#145

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

thebluesky wrote: post #83

eta_carinae wrote: post #77

The advantage of statically typed languages has a lot less to do with tests and everything to do with tools. IDE's can do very little when no type information is available, and most automatic refactorings require human supervision when performed on dynamically typed languages (read this for details: http://beust.com/weblog/2006/10/01/dynamic-language-refactor... ).

Tooling and performance are two largest advantages. Disadvantage is more verbosity, but it's a trade-off. With dynamically typed languages I find that you still need to worry about types, but you have to trace through the code to figure out what type a particular variable is (esp. if you're not the only one working on a project). In a statically typed language that information is readily available.

>Disadvantage is more verbosity

How so? Java is verbose, but that isn't due to being statically typed, it is just a verbose language. Statically typed languages with type inference are no more verbose than dynamically typed languages.

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

#146

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

cantankerous wrote: post #138

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…

This. Not all statically typed languages are created equal. Java's type system is old and is not state of the art. I wish people would stop using it as a straw man when anybody brings up static typing. Java was state of the art 20 years ago, but it's definitely not the case any more.

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.

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

#147

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

chc wrote: post #94

kingkilr wrote: post #84

Earlier quoted context omitted.

It's not unreasonable, it only seems unreasonable because of the context. I've seen several really good programmers (and overall bright people) mix the implementation of the two up.

If you have the two algorithms mixed up, unit tests aren't going to save you either. Nothing will ever save you from intending to do the wrong thing.

If you actually use the result of the function somewhere, some tests of that component should give wrong answers.

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

#148

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

davesims wrote: post #143

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 says nothing even remotely resembling "this benefit applies to all languages with static typing". That is precisely what it says, and that is reiterated later: "...the conclusion can be reached that...in practice [unit testing] is an inadequate replacement for static type checking." I'm not sure what you're reading, but there's no qualifications in the language used here regarding the idea of 'static type checkin…

>I'm not sure what you're reading, but there's no qualifications in the language used here

That is precisely my point. You are saying "this comparison of coke vs pepsi is no good because they used cold coke, and when I drink warm coke it isn't very good". Yeah, no shit. Stop drinking warm coke. Your decision to drink warm soda has no bearing on the test of cold soda vs cold soda.

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

#149

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

dons wrote: post #18

pimentel wrote: post #9

How can you translate from python to a static language, when the code is written for the interfaces, and not types? How willl you translate a function receiving a (possibly custom) iterable, when the function doesn't care about the type, but just whether it implements a next() method?

> the function doesn't care about the type, but just whether it implements a next() method? You're describing an "existential" type.

... or a typeclass.

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

#150

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

x1 wrote: post #119

papsosouid wrote: post #111

Earlier quoted context omitted.

No, I am saying your strawman is a strawman. You were claiming static typing doesn't help since a string can contain a bad query. Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? Then why did you offer it as an example of how static typing doesn't help. Of course you can make sure you never actually run the bad query with dynamic typing. I assumed it was obvious when t…

> Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? I never suggested that...? > With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs. > static typing enforces that you always use that function, and can't forget and accidently…

>I never suggested that

Yes, you did suggest that. I am not sure how this level of cognitive dissonance is possible. What possible purpose does your example serve then if it doesn't impart any sort of meaning at all?

>I'm not even sure what we are arguing about

Clearly. Please, take the time to think through the subject and present a clear point that you will not later pretend you didn't make.