On Wed, Sep 19, 2012 at 06:24:35PM -0700, David Hinkes wrote:
With python (and any other non-compiled language for that matter) the unit testing is very important. I almost think of the unit tests as the compiler (does that make sense to anyone but me?).
IMO this doesn't make sense for several reasons: 1) Just because a Haskell program compiles it is not magically correct with respect to what it is _supposed_ to do. So you still need unit testing in Haskell [1,2,3,4] - but you can focus more on functionality rather than typos, lapses and structures. 2) Covering all "type errors" with Python unit testing is hard and cummbersome. In the OP's words this means that you write your dedicated "compiler" for every single project. 3) Concluding the "type error" from a failed Python unit test is not trivial, especially because the reported error points to the location of the failure as opposed to the location of the fault. 4) Setting up unit tests for non-pure functions is quite an effert because the environment has to be brought into the right state first. Also, the environment's state has to be checked afterwards (i.e. mocking, virtual environments, etc.) 5) Running all unit tests usually takes _much_ longer than running the type checker (especially due to 4) I did quite some Python hacking in the past and although I still like the language, I love Haskell's type inference. Feels almost like scripting but allows for even faster development in the end, because you save time writing unit tests (2,4), "type errors" are detected faster (5) and finding the fault is quicker (3). Not to mention refactoring. Greetings Alex PS: For this post, I am calling "type errors" the set of bugs that the Haskell type checker can detect. Not a very precise definition, but I hope you get the idea. [1] http://hackage.haskell.org/package/HUnit-1.2.5.1 [2] http://hackage.haskell.org/package/QuickCheck-2.5 [3] http://hackage.haskell.org/package/test-framework-0.6.1 [4] http://book.realworldhaskell.org/read/testing-and-quality-assurance.html