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.
Experiment: Unit testing isn't enough; You need static types, too
151–160 of 276 posts
Re: Experiment: Unit testing isn't enough; You need static types, too
#152Earlier 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.
Re: Experiment: Unit testing isn't enough; You need static types, too
#153Earlier 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…
Re: Experiment: Unit testing isn't enough; You need static types, too
#154Earlier 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.
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
#155Earlier 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.
Re: Experiment: Unit testing isn't enough; You need static types, too
#156I 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…
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
#157Earlier 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…
Re: Experiment: Unit testing isn't enough; You need static types, too
#158I 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.…
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
#159Earlier 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.
Re: Experiment: Unit testing isn't enough; You need static types, too
#160The 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…
I do think that a rational argument can show it, but my argument is too long to fit into the margin.