On Thursday 12 March 2009 00:01:43 James Reeves wrote: > On Mar 11, 2:31 am, Jon Harrop <j...@ffconsultancy.com> wrote: > > > 2. The whole thing does not need to be complete or even functional for > > > you to start unit testing. > > > > Apples and oranges: unit tests are not the same between dynamic and > > static code bases because dynamic code bases rely upon a huge number of > > additional unit tests to serve as a poor man's substitute for static type > > checking. > > This doesn't have to be the case. There is nothing inherently magical > about a types that makes them more concise to define than a unit test.
Type inference: you don't write anything and the compiler infers your implicit constraints. For example, you know that your container: [1; 2; 3] always contains >0 elements so you rewrite it as: 1, [2; 3] Same amount of code but the compiler will now prove that the container can never be empty. With unit testing, you must create tests for every function that handles the container and try to find cases where it erroneously produces an empty result. > If you wished, you could create something like QuickCheck to > automatically generate a test based on a type definition: > > (data + Integer -> Integer) > (data count [a] -> Integer) > (data str a -> String) > > The only benefit of a static type system is that it gives you absolute > guarantees that a unit test cannot. I believe brevity is a major benefit. Clarity is another: hover the mouse over a definition in F# and you get a tool tip with the inferred type as well as any relevant documentation. > In Haskell, I can be certain that > a function will not return an incorrect type. In Clojure, I can merely > say that it is extremely unlikely the function will return the wrong > type. > > The question is whether the guarantees a good type systems offers > poses a significant advantage. I've done a fair amount of programming > in Haskell, but I don't believe the type system offers any real > advantage over unit tests. Guarantees sound good on paper, but the > guarantees even a language like Haskell offers are very basic, unless > you're willing to go to a great deal of trouble. IME, the trouble can be well worth it. I once wasted two weeks trying to track down bugs in a thousand lines of code using unit tests and never managed it. When I finally caved in and tried to leverage the static type system instead, I fixed all of the known bugs in 24 hours. I simply rearranged my data structures, exactly as I did in the above example, and the OCaml compiler would point at lines of code responsible for run-time errors and would tell me that they had now been proven redundant and could be removed safely. That was an enlightening 24 hours. > You can be certain > that a function will only return integers, for example, but can you be > certain a function will only return even numbers? Halve it. :-) > Obviously this test was extremely small, and bares little resemblance > to real programs, which are exponentially more complex. But it does > seem to tie into my experience, which is that unit tests are > surprisingly good at ensuring a program is correct, enough that they > seem comparable to the security of static types. I haven't noticed any > significant different in bug rates between Haskell and Clojure, so > static typing doesn't appear to have made a whole lot of difference. That will depend very strongly on your application. If you are using the applications I described before where static typing offers little advantage (essentially because the problem is inherently dynamic) then you would not expect to see a difference. > On the other hand, I do seem to get less bugs than with Ruby, so > perhaps immutability is a more significant factor than static typing > when it comes to creating robust applications. Interesting. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
