For those who missed it, there's a newish project called the holy haskell project starter. It generates a skeleton project with cabal sandbox, tests and a Foo/Bar module example: http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter...

Why do you say that unit testing is pointless in Haskell?

Edit: My bad - I missed the 100% part.

He said that aiming for 100% code-coverage tests in Haskell is pointless, not that unit-testing itself is pointless. Which I think is a pretty reasonable given that a lot of bugs cannot exist by construction in a lot of Haskell code.

Personally I very much enjoy unit-testing in Haskell especially with the new tasty library which makes combining all the Unit/QuickCheck/SmallCheck tests very pleasant.

[1] http://hackage.haskell.org/package/tasty

Indeed. I'm not a fan of 100% code coverage tests in any language, but it's especially apparent in Haskell where, as you said, if code compiles (and you keep most of your functions pure), there are whole classes of bugs that simply cannot exist.

"100% code coverage unit tests is a pointless endeavor"

Thirsteh said 100% coverage of unit tests is pointless, not that unit testing itself is pointless. I'm not totally sure what thirsteh means by "100% is a pointless endeavor" though.

thirsteh said that 100% code coverage is pointless, not that unit testing is pointless.

> Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase.

How is this even possible? Haskell can't catch the logic errors done over time and space, and these errors are the majority of errors in all programming languages, Haskell included.

I'm not trying to say you can't make errors in Haskell, just that, if you know what you're doing, slip-ups are extremely rare in the language. (Hence "9 times out of 10.")

It's true, to some extent, with other statically checked languages, but they usually don't have separation effects, sum types, etc.

> if you know what you're doing

So it's 9 times of ten if you know what you are doing, which is hardly the most often case.

> So it's 9 times of ten if you know what you are doing, which is hardly the most often case.

If you don't at all know what you're doing, you're gonna fail every time, anywhere. It is obviously subjective, and I don't think I implied otherwise.

Do you know what sum types are? If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match?

Even more so with separation of effects, and other things that only really exist in Haskell.

> If you don't at all know what you're doing, you're gonna fail every time, anywhere.

Not really. In programming, most of the time you think you know what you are doing but you really don't remember all the states and all the details, which results in bugs.

> Do you know what sum types are?

I do.

> If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match?

In non object-oriented languages or in object-oriented languages without abstract methods, it's certainly possible.

In object-oriented languages with abstract methods, it's not possible: for each missing case the compiler will complain with an error.

> Even more so with separation of effects, and other things that only really exist in Haskell.

Separation of effects doesn't really improve the situation with bugs. A bug may have its cause inside a pure computation.

Okay, it appears we fundamentally disagree, so let's end the discussion here.