5 ms·

Think of it this way. More compile time errors = fewer run-time errors. You can still have bugs of course. Most my Haskell run-time bugs are because I defined a

by T_S_ 15y ago

Think of it this way. More compile time errors = fewer run-time errors. You can still have bugs of course. Most my Haskell run-time bugs are because I defined a partial function. Many standard functions are partial too. I find that changing a working Haskell program to add new features is easier than other languages I have used. You pay a price (understanding your problem better) up front to get there, but the dev cycle is very fast after that.

davidhollander 15y ago
>More compile time errors = fewer run-time errors. But any possibility of 1 run time error means you'll still need to manually write a test asserting the correct runtime behavior anyway. So the typical argument is that typed languages don't actually save you any work, and might actually increase the likelihood of errors by discouraging unit testing. I'm not claiming this holds for Haskell, as my experience with the language is not great enough to pass any judgement yet.
- T_S_ 15y ago
  Ok. Fewer run time errors = fewer tests. Also check out QuickCheck for automatically generating tests. It's very handy.
- Peaker 15y ago
  1 test is not enough to cover the functionality of various functions. In Haskell, types are enough to prove some properties about functions, so you don't need to write any test for the proven part. For example, you can write a RedBlack/AVL tree implementation in Haskell where the types prove that the tree is balanced. Haskell's type system is not strong enough to prove the order invariants are correct, though, so you'll still need to test that, but that's easier. In a language with a weaker type system, you'd end up with more test code (for balance tests) and less guarantees (tests give no assurance). Also, many bugs slip through tests that are meant to cover these classes of bugs. You don't get any guarantee from tests. Types give you nice guarantees. They're not as comprehensive as very-expensive tests, but they're pretty cheap. You get far more reliability-bang-for-the-buck from types, and thus the baseline from which you start testing is much higher.

by T_S_ 15y ago

davidhollander 15y ago

>More compile time errors = fewer run-time errors. But any possibility of 1 run time error means you'll still need to manually write a test asserting the correct runtime behavior anyway. So the typical argument is that typed languages don't actually save you any work, and might actually increase the likelihood of errors by discouraging unit testing. I'm not claiming this holds for Haskell, as my experience with the language is not great enough to pass any judgement yet.

T_S_ 15y ago
Ok. Fewer run time errors = fewer tests. Also check out QuickCheck for automatically generating tests. It's very handy.
Peaker 15y ago
1 test is not enough to cover the functionality of various functions. In Haskell, types are enough to prove some properties about functions, so you don't need to write any test for the proven part. For example, you can write a RedBlack/AVL tree implementation in Haskell where the types prove that the tree is balanced. Haskell's type system is not strong enough to prove the order invariants are correct, though, so you'll still need to test that, but that's easier. In a language with a weaker type system, you'd end up with more test code (for balance tests) and less guarantees (tests give no assurance). Also, many bugs slip through tests that are meant to cover these classes of bugs. You don't get any guarantee from tests. Types give you nice guarantees. They're not as comprehensive as very-expensive tests, but they're pretty cheap. You get far more reliability-bang-for-the-buck from types, and thus the baseline from which you start testing is much higher.