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 writ…
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!
I've been meaning to pick up either Haskell or OCaml for my next language. On the OCaml side, I see Cornell's free CS 3110 textbook recommended around here. Is there something similar on the Haskell side?
I learned by reading Haskell Programming from First Principles. Great book which covers most topics you'd need to know in order to write and read Haskell in the wild. Highly recommended
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 writ…
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.
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 writ…
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.
> 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).
I've been meaning to pick up either Haskell or OCaml for my next language. On the OCaml side, I see Cornell's free CS 3110 textbook recommended around here. Is there something similar on the Haskell side?
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 writ…
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?
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.
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.
> 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 usual…
> 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.
> 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 usual…
> 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. [1] https://leanprover.github.io/lean4/doc/
I've been meaning to pick up either Haskell or OCaml for my next language. On the OCaml side, I see Cornell's free CS 3110 textbook recommended around here. Is there something similar on the Haskell side?