One of the nice features of IHP is that, thanks to Haskell’s strict type checking, it does not just eliminate bugs, it also speeds up development. E.g. if you want to change or build a new feature, you don’t need to write tests for it since the compiler basically does that for you. Since you don’t need to write tests, your work is perhaps half of what it would be normally – and neither do you have to know how to write good tests, which is an entire skill in itself.
Not sure if you're being sarcastic, but Haskell developers should definitely write tests, and good ones know how to write good tests. The type system eliminates the need for some forms of testing, but not all.
Thanks for the feedback. I am definitely a beginner in Haskell, which would explain why I came to this conclusion. Could you recommend some good sources on testing in Haskell?
While of course Haskell has more normal testing infrastructure available (eg. https://hspec.github.io/), my favorite bit of Haskell testing is QuickCheck, which IIUC started life in Haskell and has been reimplemented in other languages with various degrees of effectiveness and various degrees of connection to the original project.
Actually it’s common for Haskell devs to write property-based tests that are far more complex than regular tests (identifying useful properties is a true artform). Source: I’ve been a test engineer on a large Haskell product!
Don't need to write _type_ tests (like you would in a dynamic language). Having strong typing doesn't magically do formal validation on your logic. Leaning heavily on types is good practice, but that doesn't eliminate most of the high value tests you'd have to write.
Haskell's QuickCheck, AFAIK the first prominent implementation of property-based testing, gained its popularity partly because it eliminated a good part of the tedium by inferring the sampling strategies from the types (which in idiomatic Haskell are, due to liberal use of opaque type synonyms, often quite a bit more specific than in any other non-dependently-typed language I've seen). Which does not free the programmer from writing down the properties themselves—in that respect your objection is valid—, but IME still makes it quite a bit more ergonomic than e.g. Python's otherwise functionally equivalent Hypothesis.
You'll find no argument from me there, property based testing has been a real game changer for me. I imagine it would have a fraction of the value without being able to leverage the type system to a great degree.
> Having strong typing doesn't magically do formal validation on your logic
There are plugins for Haskell and dependently typed languages that go much further in the ‘if it compiles, it is formally validated’, but that’s a lot more work; there is a trade-off for now or you will be stuck. Your ‘run of the mill’ tests also don’t formally validate your logic (not even close usually). Our types, even if static, are usually too loose and our type systems not powerful enough; writing tests helps to close the gap between practical and theoretical but a lot more can be done semi-automatically (and will be I hope).
> There are plugins for Haskell and dependently typed languages that go much further in the ‘if it compiles, it is formally validated’
Yes, Lean 4[1] is shaping up to be a Haskell-inspired dependently typed language with monadic IO etc. that can also prove theorems for you. Still a work in progress but looks very exciting.
