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

On Thu, Sep 20, 2012 at 8:24 AM, David Hinkes wrote:

I almost think of the unit tests as the compiler (does that make sense to anyone but me?).

Absolutely! There's also quickcheck, which is semi-automated fuzz testing. All this contributes to greater awesomeness in every line of code. -- Kim-Ee On Thu, Sep 20, 2012 at 8:24 AM, 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?).

On Wed, Sep 19, 2012 at 3:15 PM, Dennis Raddle wrote:

...

As a somewhat-newbie haskell user and longtime Python user, what I have observed is this.

Haskell creates compile-time error messages that are somewhat hard to understand for beginners.

Python (or any scripting language) creates run-time bugs that are hard to understand.

One reason for the weird (to a beginner) compile errors in Haskell is its expressivity -- almost any sequence of identifiers could potentially mean something, and if you make a mistake, the compiler is sure to find some "weird" way to interpret it.

But Python suffers from a similar problem -- it's not as expressive a language, but it is very permissive, not insisting on type correctness, order of arguments, or any of a number of things so that the programmer can write a program that compiles with no errors -- but has strange run-time bugs.

I'll take Haskell. I'm a bit OCD about getting the bugs out of my programs, and Python just opens up too many holes for me to relax with it.

Dennis

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- David Hinkes

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners