Live data from Hacker News

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

evanfarrer.blogspot.ca

151–160 of 276 posts

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

#151
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.

Except unlike sugar and cream, unit tests and type checking prevent the crappy coffee being served (well, unless you're from the PHP Coffee House where serving an unit test failing brew is perfectly acceptable (https://bugs.php.net/bug.php?id=55439)

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

#152

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.

Java wasn't even state of the art 20 years ago. ML dates back to the 70s.

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

#153
post #98
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…

In Haskell, you could define a type AttributeString that was a plain string internally, but encapsulated so it could only be instantiated (or only be serialized) through a function that did the relevant escaping; require attributes to have that type, then the type checker would enforce that property for you as well!

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

#154

Earlier quoted context omitted.

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.

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 test of "do airbags help prevent deaths" would be a very poor test if it used anything other than the best possible airbag technology.

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

#155

Earlier quoted context omitted.

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.

Java wasn't even state of the art 20 years ago. ML dates back to the 70s.

I agree with you, but I think we might be in the minority.

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

#156
post #15

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…

> The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. This part is also very tricky, as most of people's hard-earned experience with this is (almost by definition) old . In recent years, type inference has reduced the type-caused slowdown immensely. E.g. in Haskell you can (+) write large statically typed programs without specifying any types at all…

Recent years? 70s more like.

ML way is to not write type annotations unless they're needed, not that I agree with it, but it certainly works in some way.

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

#157

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…

Since this hasn't been already mentioned, and I run the risk of really flaming things up. Java has a very high propensity of generating runtime type errors. This is easily done by skirting the type checker with casting, which is commonplace. The upshot of me saying this is that I'm actually on the fence of even considering Java to be a statically-typed language for this reason...which is part of why I disagree with the parent even using it as an example of a statically typed language equivalent to the one from this post in a counterexample (also included in this is C, C++, and the rest of that family).

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

#158

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.…

Java, XML/XSL/XSD, and design patterns (gone wild) all hit about the same time.

Most (but not all) of my pain slinging Java come from misuse of XML and design patterns. Now we're on to services (SOA). Yippee. It's just a socket, marshaling, retry logic. Does it really need its own ecosystem of consultants, conferences, and books?

Java the language could be more terse with type inference, string literals, default visibility modifiers, and some other syntactic sugar. (I'm pretty optimistic about Ceylon as a successor.) But 18 years on, for the most part, I'm still very pleased with Java. Except autoboxing and annotations; garbage.

Java the platform (JDK, J2EE, java.util., collections, javax., misc APIs) should be burned to the ground, plowed under, and complete do over. And any one who says "factory method" gets keelhauled.

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

#159

Earlier quoted context omitted.

Are you having fun because you switched to a statically typed language or are you having fun because you switched to a functional language? Would you be having less fun had you chosen Clojure?

I started a parallel implementation of a bunch of machine learning algorithms in Clojure and Scala. I figured the Clojure version would pull out ahead thanks to my previous lisp experience and lisp's history in that domain. I was very surprised to discover that my Scala code was a lot easier to understand and maintain and had fewer bugs.

What do you attribute this to? The static typing of Scala or the libraries that you use?

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

#160

The sample size of this study is statistically too insignificant to draw the conclusions given. The counterfactuals to the claims of dynamic type advocates were already true and provable, so even if the sample size of the codebases studied were statistically significant (not to mention vetted for quality of unit test as well as coverage ) the conclusions are nevertheless trivial. In addition, the hidden assumption is…

You make a good point -- I don't think any statistical study will ever be able to show that static typing is better.

I do think that a rational argument can show it, but my argument is too long to fit into the margin.

Post reply on HN